Создание папок из фронтенда - страница 5 - Разработка расширений для Joomla

да делайте как хотите...

Решать конечно вам. Но на мой лично взгляд, именно KKAAZZOO  было подсказано правильное направление. Однако я не согласен с тем, что с помощью поля Select Dynamic нельзя отобрать категории созданные пользователем (ведь Динамик это по сути запрос к БД, а запросом можно получить ЛЮБЫЕ данные из базы, с ЛЮБЫМИ условиями; у нас есть id автора создавшего категорию в ячейке created_user_id таблицы _categories).

Вы неправильно меня поняли, конечно можно Select Dynamic выбрать материалы, но нельзя в форме иметь два поля которые сохраняют одновременно сохраняют в одну ячейку базы данных! Я именно это имел ввиду

Человек помощи попросил, а тут битва титанов развернулась. mila_serdnaya, определитесь уже, как вы делаете, и чтоб уже этот базар прекратился и разговор пошел по вашей конкретной теме.
SEBLOD не имеет мультикатегорий, это верно, ибо их не имеет Joomla, а себлод работает по законам Joomla, в чем его несомненный плюс - это не сторонний компонент, он просто расширяет возможности самой CMS. Грубо говоря, пофиг ему - материал это или категория, мы можем назначить один материал парентом к другим и станет он категорией, хотя и будет в админке находиться в списке материалов. Также я могу сказать, что у конкретного материала будет 5 парентов, и это тоже возможно. Если интересно сделать сайт с возможностью расширения и обновления, милости просим как на офф сайт SEBLOD, так и к нам, в русскоязычное сообщество. Чтоб не выглядело рекламой не буду ссылки публиковать, я думаю, Яндекс подскажет.   AlekVolsk, как профи, я думаю, давно уже заинтересовался - вряд ли интересно каждый раз компоненты отдельные писать.
Если же вы делаете свой компонент, вы можете в него заложить все, что вам нужно, это несомненно. Составьте план, что и как должно работать, какие могут быть и понадобятся Вам возможности расширения функционала, чтоб заложить эти возможности в коде, определитесь со взаимодействием Вашего компонента с Joomla, не забудьте решить вопросы безопасности и реализуйте это все в коде. В принципе, нет проблем, тем более, я так понял, что тут есть знающие товарищи, которые вам подскажут, как это все реализовать.
Дело за Вами, определяйтесь, а то некрасивый торг уже пошел, а тут, на самом деле, меряться особо нечем.

Согласен с KKAAZZOO и greenmar - на Seblod решить указанную топикстартером задачу намного проще, чем писать что-то с нуля.
Я использую связку Joomla + Seblod для всех своих сайтов, которые чуть сложнее, чем одностраничники. И пусть сколь угодно в меня кидают помидорами (мол, монстры получаются в техническом плане), но зато я чётко знаю, что по мере развития сайта (постановки дополнительных требований и задач со стороны заказчика), 90% из них решаются вообще без каких-то проблем, штатными средствами такого сайта. Любые (ну, или почти любые) фильтры, формы, структуры, профили... Практически что угодно делай с контентом...

По сабжу, услышав термины "категории", "папки" - мы начинаем думать в сторону стандартных категорий Joomla. А это не совсем верно, в данном случае, ИМХО. Как справедливо заметил ComeOn, "парентом" материала в случае Seblod может быть что угодно. ))) Соответственно, и фильтровать (выводить) списки материалов автора можно по куче любых параметров (в т.ч. нескольких одновременно в различных комбинациях), которые мы сами придумаем. Без формирования дополнительных "классических" категорий (хотя можно и с ними, но зачем?).

Да и вообще, коллеги, человек, насколько я понял, не то чтобы слишком искушён даже в работе с CMS, которой посвящён данный форум, а вы ему: "напишите свой компонент"... Это юмор такой? Всё-таки, мне кажется, с Seblod разобраться будет проще... Его "высокий порог вхождения" несколько преувеличен, на мой взгляд, во всяком случае, для решения многих задач вовсе не обязательно сразу "лезть в дебри". Это можно оставить на потом, когда всяких "финтифлюшечек" захочется.  

AlekVolsk, вчера вечером мы начали создавать каркас нашего компонента. Параллельно изучили информацию о том, что такое база данных, система управления базами данных, реляционная модель, первичный ключ, индексирование, система управления базами данных MySQL (глубоко в это не влезали, получили первичное представление об этих вещах).

На данный момент каркас компонента мы создали и установили его на сайт. Сегодня ночью продолжим над ним работать. Руководствуемся сейчас в первую очередь вот этими уроками по созданию компонентов на Joomla (которые Вы нам рекомендовали): http://ссылка вырезана, так как домен распространяет вирусы/blog/joomla/uroki-po-sozdaniyu-komponentov-dlya-joomla-chast-1-sozdaem-karkas-komponenta.html
-----------------
Там всего 5 частей. Первую часть мы выполнили. Сегодня ночью перейдём ко второй части.
Ниже приводим наш отчёт по выполнению первого урока.
 
Вот он:
1. Мы заполнили основные данные компонента.
Название компонента – «Сборники»
Системное имя - chmos
------------------------------------------
2. Перешли на вкладку "Таблицы". Добавили 3 таблицы:
chmos_users – для  пользователей, в ней создали дополнительное поле userid
chmos_categories - для категорий, в ней создали дополнительное поле userid
chmos_articles - для произведений, в ней создали дополнительные поля userid и catid

------------------------------
3. Перешли на вкладку "Пользовательская часть".

Создали виды (мы не очень хорошо понимаем, что это за виды)
form1 - как мы предполагаем, это вид, в котором будет отображаться наша форма, в которую пользователь будет вводить названия для сборников («тип вида» – вид формы, «связать с таблицей» - chmos_users, «название на русском» - Название сборника, «название на английском» - view form1)
form2  - как мы предполагаем, это вид, в котором будет отображаться наша форма, содержащая список названий сборников, созданных пользователем («тип вида» – вид списка, «связать с таблицей» - chmos_users, «название на русском» - Список сборников, «название на английском» - View form2 )
result1 – «тип вида» – пустой вид
result2  – «тип вида» – пустой вид
-------------------

4. Перешли на вкладку «Админка» (здесь мы тоже не уверены в том, все ли нужные виды мы прописали)
Создали вид «archive1» (как мы поняли, для названий сборников) и «archive2» (как мы поняли, для создания связи между произведениями и сборниками).

Настройки вида «archive1»:
- тип вида  - мы выбрали – «Вид с функциями редактирования»
- «связать с таблицей» – chmos_users
- «Связать с категорией»: «НЕТ»
- название на русском: мы написали: «Архив1»
- название на английском – мы написали: «View archive1»

Настройки вида «archive2»:
- тип вида  - «Вид с функциями редактирования»
- «связать с таблицей» – chmos_users
 «Связать с категорией»: «НЕТ»
- название на русском: «Архив2»
- название на английском – «View archive2»

5. Нажали на кнопку «сформировать компонент» - и получили заархивированный каркас нашего компонента, который успешно установили на сайт.
----------------------------------------------------
- Подозреваем, что в пунктах "связать с таблицей" мы совершили ряд ошибок... Мы не уверены в том, что сами формы у нас правильные, отсюда и дальнейшее непонимание того, с какими таблицами эти формы связывать.
На самом деле, я бы связала "Form1" c таблицей "chmos_categories", а Form2... тоже с этой же таблицей, наверное... Запутались мы совсем в этом месте.
- И нужно ли нам создавать вид, который показывает форму добавления материала на сайт? Или мы это будем реализовывать стандартным редактором Joomla?
- Также мы не поняли, сколько же таблиц мы создаём в самом начале: три (chmos_users, chmos_categories, chmos_articles) или пять (chmos_users, chmos_categories, chmos_articles, chmos__compilations, chmos__compilations_articles)?

---------------------------------------------------
Каркас нашего компонента прикрепляем - мало ли, кому-то будет интересно.

К сожалению, у нас сейчас нет возможности отписаться по каждому комментарию, оставленному участниками данной темы. Спасибо Вам всем большое за такое живое участие и отдельное спасибо, конечно, автору KKAAZZOO за оказанную помощь. Вы не оставляете нас один на один с проблемой, а реально помогаете. Мы это ценим.
--------
Seblod мы отложили в сторону и идём по пути написания собственного компонента.

Зачем Вам таблица _users? Вы же используете пользователей Joomla.
Зачем Вам таблица _articles? Вы же используете материалы Joomla - это произведения.

Вам нужно всего две таблицы:
- chmos_compilations (для списка сборников). Должна содержать такие колонки как: id, title (название), alias (если надо), state (состояние: опубликовано/неопубликовано/удалено и т.п.), created_date (дата создания), created_user_id (ID пользователя-создателя сборника - это связь с таблицой _users Joomla)
- chmos_compilations_articles (для создания связи между произведениями и сборниками). Должна содержать две колонки: compilation_id (ID сборника - связь с таблицой chmos_compilations) и content_id (ID материала - связь с таблицой _content Joomla, в которой хранятся материалы)

@bz2:
_users - будет расширятся стандартный функционал com_users (аватарки и все прочее), причем расширение будет не настолько большим. чтобы использовать для этого CB или аналоги
_articles - потому что нужна своя система категорий, т.к. штатные категории не имеют привязки к конкретному пользователю, а материалы J нельзя просто так привязать к внештатным категориям

как вариант, можно попробовать minicck от Аркадия, но он вроде не расширяет возможностей категорий, да и вопрос расширения профиля пользователя с ним остается открытым

@ComeOn:
как профессионал (хотя таковым себя не считаю) предпочитаю юзать zoo, куда гораздо удобнее, но для небольших задач использовать сторонние громоздкие cck не вижу смысла - зачем ставить монстра, чьи возможности будут использованы не более чем на 5%, свой компонент в таких случаях производительнее и эффективнее

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

Мила, более - сори - ничего советовать не буду, принимайте решение сами, всеми необходимыми ресурсами обладаете, дело за наживным опытом. Удачи.

@bz2:
_users - будет расширятся стандартный функционал com_users (аватарки и все прочее), причем расширение будет не настолько большим. чтобы использовать для этого CB или аналоги

Зачем? Расширить стандартный компонент пользователей можно легко с помощью плагина профиля.

_articles - потому что нужна своя система категорий, т.к. штатные категории не имеют привязки к конкретному пользователю, а материалы J нельзя просто так привязать к внештатным категориям

Материалы - это просто записи в таблице. Их можно связать с чем угодно и как угодно.

В общем сделал с помощью Component Creator базу. Чуток подрихтовал. Название компонента "Сборники". Заняло 2 часа работы.

Компонент создает две таблицы:
- chmos_compilations (для списка сборников)
- chmos_compilations_articles (для создания связи между произведениями и сборниками)

Компонент может создавать/редактировать/удалять сборники как с фронта, так и с админки.

Доступно три пункта меню:
- представление для добавления/редактирования сборника
- представление списка сборников
- представление сборника

То есть на данном этапе компонент работает только с таблицей chmos_compilations. Теперь Вам нужно подумать, как связывать произведения со сборниками.

P.S.
Стиль кода конечно далек от идеала, но так уж его создал Component Creator. Я уже не хотел все править, только основные моменты.

Так, тяжелая артиллерия подтянулась.

b2z, а как с мультикатегориями решение вопроса видите? Если планируется 10 базовых категорий, плюс неограниченное количество "сборников" у пользователей? Сайт ляжет если будет дикое количество штатных категорий Joomla

Похоже это был крик в пустоту... А зря )))

Так, тяжелая артиллерия подтянулась.

b2z, а как с мультикатегориями решение вопроса видите? Если планируется 10 базовых категорий, плюс неограниченное количество "сборников" у пользователей? Сайт ляжет если будет дикое количество штатных категорий Joomla

А с чего вдруг решили, что я использую категории Joomla? Сборники хранятся в отдельной таблице chmos_compilations. А категории Joomla будут жить своей жизнью.

Вопрос только в том, нужна ли для сборников вложенность? Как я понял - нет.

b2z, вот это подарок! =)
Закачали мы компонент, который Вы сделали, протестировали его. Сборники создаются быстро и приятно.  =)
Прикрепляем картинки того, как компонент выглядит на сайте.

b2z, Вы пишите, что "на данном этапе компонент работает только с таблицей chmos_compilations". И теперь нам "нужно подумать, как связывать произведения со сборниками".

Рассуждаем вслух:
У нас в базе данных уже есть таблица chmos_compilations_articles, которая связывает между собой таблицу _content (материалы) с таблицей chmos_compilations (сборники).
У этой таблицы всего два поля: content_id и compilation_id

Нам нужно id добавляемого материала связать со сборниками.

В меню для зарегистрированных пользователей мы вывели пункт "опубликовать" (тип пункта меню: материалы - создать материал). Скажите, пожалуйста, можем ли мы в редакторе Joomla (мы установили редактор Jce) как-то добавить вкладку с названием "Сборники", при переходе на которую пользователь видел бы выпадающий список с названиями созданных сборников и мог выбирать нужный ему сборник?.
Картинку для наглядности прикрепляем.

Вот на что это ещё может быть похоже: на то, как отображаются категории на вкладке "Публикация" в этой же форме добавления материала на сайт.

b2z, а насчёт вложенности - мы хотели, чтобы список сборников выводится вместе с материалами, которые в них (в сборниках) сидят... Вы об этой вложенности спрашивали?

Вкладка про которую вы спрашиваете не относится к Редактору JCE. Поле по типу категорий можно добавить в форму подачи материала

b2z, а насчёт вложенности - мы хотели, чтобы список сборников выводится вместе с материалами, которые в них (в сборниках) сидят... Вы об этой вложенности спрашивали?

Нет, имелась ввиду, древовидная структура, как у категорий: есть главный сборник, внутри еще и внутри еще. Если такое не нужно, то все отлично.

А то, что вы хотите - это надо менять запрос в модели Compilations. Сейчас он делает просто выборку сборников из таблицы compilations. А надо делать выборку из таблицы content + из таблицы compilations присоединять сборники по content_id (делать JOIN). Далее красиво выводить на фронте в представлении Compilations.

Вот на что это ещё может быть похоже: на то, как отображаются категории на вкладке "Публикация" в этой же форме добавления материала на сайт.

KKAAZZOO прав, нужно добавить поле сборников в форму подачи материала. Придется написать плагин типа 'content' на событие onContentPrepareData + onContentPrepareForm для вставки поля сборников и на событие onContentBeforeSave для сохранения связи между материалом и сборником.

Скоро Вы станете спецами в разработке. Еще не передумали все делать на Seblod?

mila_serdnaya, вот, посмотрите пример, мои некоторые эксперименты, в принципе реализованы схожие с вашими возможности, зарегистрируйтесь для доступа в личный кабинет http://kkaazzoo.myjino.ru/

b2z, насчёт древовидной структуры сборников - такое не нужно.

KKAAZZOO, по ссылке прошли, зарегистрировались, ознакомились с сайтом. В первую очередь обратили внимание на адаптивный дизайн - считаем, что это очень важный момент, на который нужно обращать внимание при создании сайта.
Понравилось, как выглядит Ваш профиль пользователя. Мы, например, серьёзно намучались, когда искали информацию о том, как добавить фотографию в профиль пользователя. Чего мы только не делали: и сами код пытались править (в итоге научились добавлять в стандартный джумловский профиль новые поля для текста), и расширения громоздкие устанавливали (К2, Community Builder). Вопрос так и остался открытым.
А Вы просто взяли и сконструировали тот профиль, который нужен именно Вам и заточен под Ваши задачи.

Насчёт связи материала и сборников - спасибо большое за такое подробное объяснение со ссылками на примеры. Суть наших дальнейших действий мы поняли. Уходим разбираться с информацией о написании плагина на событие.

--------
"Скоро Вы станете спецами в разработке. Еще не передумали все делать на Seblod?" - хорошая шутка. =)

Всем здравствуйте!
Изучили мы информацию по созданию плагинов, основы, кажется, усвоили, - выныриваем.
Прикрепляем установочный файл (файл манифеста) нашего плагина:



У нас возникли сомнения в блоке <config> , а именно в поле field name="check_compilations".
Мы создаём поле - выпадающий список из названий сборников, которые создал пользователь. Всё ли мы правильно указали?
Нас также смущают строки <option value="1">YES</option> и <option value="0">NO</option>, - мы не очень понимаем, какое действие они обозначают....
---------------
Xml-файл прикрепляем, на всякий случай.

в этом поле type="list" означает, что это будет раскрывающийся список значений, каждый option - это значение в этом списке, параметр value содержит то значение, которое будет использоваться системой, YES и NO - это отображаемые названия значений, не участвующие во внутренней работе расширения, поменяйте их на свои собственные. подробнее, там же найдете описания практически всех полей J

А зачем Вам в файле манифеста поле сборников? Его нужно в самом коде плагина подгружать. Посмотрите плагин Профиля - plugins/user/profile/profile.php, в нем все очень похоже на то, что Вам надо.

b2z, мы правильно поняли, что в нашем манифесте блок <config> вообще не нужен?

И ещё, подскажите, пожалуйста, мы правильно понимаем, что наш плагин будет состоять из только из двух следующих файлов:
1. Установочный файл (файл манифеста) - plugchmos.xml
2. Собственно код плагина - plugchmos.php

b2z, мы правильно поняли, что в нашем манифесте блок <config> вообще не нужен?

Правильно.

И ещё, подскажите, пожалуйста, мы правильно понимаем, что наш плагин будет состоять из только из двух следующих файлов:
1. Установочный файл (файл манифеста) - plugchmos.xml
2. Собственно код плагина - plugchmos.php

Ну возможно еще придется создать .xml файл с типом поля. Тут все зависит от того, как Вы это поле будете добавлять в форму.

b2z, спасибо, теперь с манифестом всё понятно.

Разбираемся с собственно кодом плагина. Перечитали очень много информации за всё это время.
Пишем сейчас функцию на событие onContentPrepareData. Взяли за основу плагин Профиля пользователя.

Столкнулись с тем, что не знаем, какой параметр нам нужно брать для объекта object($data). Вот кусок кода плагина plugchmos.php с непонятным для нас местом:

public function onContentPrepareData($context, $data)
   {
      
      if (is_object($data))
      {
         $userId = isset($data->id)? $data->id : 0;    - вот это место непонятно. В плагине профиль пользователя стоит userId, а нам что нужно брать? Просто Id?

      

AlekVolsk, спасибо за ссылку и пояснение.

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

Тема кстати - идеальный кейс как выпросить бесплатное написание компонента.