Joomla com_user расширяется аналогично com_categories и com_content

Хорошо, это просто то, что я чувствую, что должен спросить, поскольку я не мог найти никаких ссылок на это в какой-либо документации, и чтение фактического кода, чтобы выяснить, как лучше всего это сделать, займет гораздо больше времени, чем надеюсь потратить.

Когда вы входите в менеджер статей, у вас есть навигационная ссылка на менеджер категорий и наоборот. Я хотел бы сделать что-то подобное с моим компонентом и менеджером пользователей по умолчанию.

У меня уже есть плагин профиля для расширения пользователей в соответствии с моими потребностями, но я хотел бы, чтобы его конфигурация была бесшовной, поэтому настройка компонента com_user для лучшей интеграции с моим компонентом — это то, что я ищу.

Итак, мой вопрос заключается в том, что com_content и com_categories используют параметр «расширение». Можно ли добавить аналогичную функциональность без полного переопределения ядра com_users? Если я сделаю полное переопределение, есть вероятность, что некоторые расширения не будут работать из-за зависимости от пользователей.

Я готов уточнить, если что-то не имеет смысла, этот вопрос больше для того, чтобы увидеть, насколько вы можете «расширить» Joomla без переопределений.

ОБНОВИТЬ:

Я нашел классную технику, но не совсем ответ. Вы можете переопределить только контроллер/модель/представление списка в своем компоненте, и если вы основываете его на текущем компоненте com_users, вы можете сделать его похожим на прямую интеграцию. Единственные изменения, которые вам нужно сделать, это убедиться, что любые маршруты к просмотру пользователей вместо этого передаются вашему компоненту.

Однако с этим есть одна проблема: когда вы добавляете нового пользователя или редактируете его, как только вы закончите, он направит вас к главному менеджеру пользователей. Системный плагин может помочь в этом, но только если есть надежный способ определить, когда пользователь был отредактирован через ваш компонент, а не через менеджер пользователей.

Примечание. Проблема с добавлением переопределения в пользовательское представление заключается в том, что оно имеет 5-6 других компонентов MVC, на которые оно опирается, поэтому в интересах упрощения обновления с помощью основных обновлений com_users лучше избегать этого, если это вообще возможно. .

Еще одна необходимая вещь — убедиться, что вы нашли языковой файл для com_users и добавили все записи в свой компонент.

Я чувствую, что все еще может быть лучший ответ, но такой способ не сильно повлияет на ядро, и его будет легко обновить с помощью обновлений com_users.

Я открываю награду за это, я чувствую, что каждый вопрос, который я когда-либо задавал, принесет наибольшую пользу сообществу. Итак, вот сжатая версия вопроса.

Что может быть простым способом интегрировать основной компонент в пользовательский компонент и сделать так, чтобы он беспрепятственно проходил через этот компонент с минимальными изменениями в основном компоненте?


person Jordan Ramstad    schedule 09.08.2013    source источник


Ответы (1)


Я не совсем понимаю, что вы хотите, но если вы говорите о подменю панели инструментов, как это в com_content:

подменю com_content

Пример, который вы приводите для категорий (т.е. com_categories), представляет собой добавленную специальную поддержку, где вы можете передать ссылку на com_catgories с вашим идентификатором расширения (extension=com_mycomponent), и он загрузит меню боковой панели для вашего расширения. Это делается для того, чтобы основные категории могли совместно использоваться различными компонентами [см. Добавить категории].

Возможно, вам уже известно следующее, но если вы хотите узнать, как добавить меню боковой панели в представление диспетчера компонентов, вы можете вызвать JHtmlSidebar::addEntry($title, $link, $active);

Обычно это помещается в ваш основной вспомогательный файл расширений в функцию с именем addSubmenu($vName) (это то, что и где com_categories будет искать для отображения подменю панели инструментов). Он называется addSubmenu(), потому что sidebar трансформировалось из подменю панели инструментов в предыдущих версиях Joomla.

например это метод addSubmenu() в классе ContentHelper, определенном в administrator/com_content/helpers/content.php

/**
 * Configure the Linkbar.
 *
 * @param   string  $vName  The name of the active view.
 *
 * @return  void
 * @since   1.6
 */
public static function addSubmenu($vName)
{
    JHtmlSidebar::addEntry(
        JText::_('JGLOBAL_ARTICLES'),
        'index.php?option=com_content&view=articles',
        $vName == 'articles'
    );
    JHtmlSidebar::addEntry(
        JText::_('COM_CONTENT_SUBMENU_CATEGORIES'),
        'index.php?option=com_categories&extension=com_content',
        $vName == 'categories');
    JHtmlSidebar::addEntry(
        JText::_('COM_CONTENT_SUBMENU_FEATURED'),
        'index.php?option=com_content&view=featured',
        $vName == 'featured'
    );
}

Для сравнения, вспомогательный класс com_categories CategoriesHelper имеет совсем другой метод addSubmenu(), который ищет основной вспомогательный класс вызывающих расширений (если он не найден, по умолчанию используется com_content).

В com_users нет такой поддержки, поэтому вам, вероятно, придется создать системный плагин, который запускает onAfterRoute и добавляет ваш элемент подменю в зависимости от того, предоставил ли ваш компонент подходящий параметр, например extension=com_myextension. Это будет немного сложно, но это должно сработать — единственная вещь заключается в том, что вы добавляете элемент подменю до того, как компонент будет отправлен, ваш новый элемент подменю всегда должен быть первым элементом в подменю com_users. Это не будет полной заменой, как com_categories поддерживает.

К сожалению, я не могу найти никаких триггеров в com_users, которые могли бы помочь в просмотре всего меню боковой панели.

Следующий вариант — использовать что-то вроде сущности Дональда Гилберта для создания системного плагина, который позволит вам переопределить любой базовый класс. путем создания собственной заменяющей версии – очевидно, что это приведет к проблемам с любыми значительными обновлениями, но если вы будете осторожны, вы можете ограничить переопределение своей конкретной ситуацией.

Если этого недостаточно/излишне, вы можете попробовать системный плагин, который реагирует на onAfterDispatch, и в этот момент у вас будет страница до того, как она вернется в браузер, и вы сможете взломать HTML, но это очень уродливо и может сломаться, если пользователи изменят их шаблон администратора.

Конечно, я могу ошибаться, и есть лучший способ сделать это в 3.x. Может еще кто отзовется.

person Craig    schedule 11.08.2013
comment
Да, причина этой проблемы в том, что мой компонент напрямую интегрируется с пользователями, поэтому ключевым моментом является возможность переключаться между компонентом и пользователями. Это, вероятно, не поможет в моей ситуации, но это очень четкое объяснение функциональности расширений, так что палец вверх! - person Jordan Ramstad; 12.08.2013
comment
Вы говорите, что просто хотите добавить вкладку с представлением из другого расширения или хотите, чтобы пользователи отображали его как вкладку в вашем расширении? Я немного смущен тем, что вы хотите сделать, - person Elin; 14.08.2013
comment
Если вы перейдете к диспетчеру пользователей и щелкнете по пользователям, представление которых я хочу использовать в своем расширении, поскольку компонент обрабатывает множество пользовательских надстроек, было бы чрезвычайно удобно упростить его. Я уже сделал своего рода переопределение, и оно работает, но у меня проблема с маршрутизацией обратно к моему компоненту при его сохранении (поскольку я не маршрутизирую представление пользователя, а только представление списка пользователей). - person Jordan Ramstad; 14.08.2013