Привет Всем, отдельно Александру.

Знаю этот движок уже давно (года 2), но решился недавно перейти на него и начать изучать. Я сам разработчик и для меня не составит труда написать CMS с использованием MVC и ООП, поэтому решил поковырять движок, к тому же отзывы одни положительные. Имея опыт в разработке движков, изучал другие CMS и написанил под них несколько модулей, решил взяться за Eleanor, и написать главный для меня необходимый модуль Интернет магазина. К тому же на офф сайте разработчика сказано, что весь код понятно и "бережно" задокументирован.
За один вечер мне не было проблем создать модуль Интернет магазина на основе модуля новостей. Подключил в админке, вывел настройки (понравилась идея создания настроек модулей), настроил языки, всё хорошо, всё подключил и работает как отдельный автономный от новостей модуль Интернет магазина, с товарами и категориями. Вот только когда я полез в файлы шаблонов и стал разбираться детально что к чему, это был ахтунг. Первое впечатление что я увидел, это паутину. Всё настолько запутано в ООП (конечно если разобраться в методах и свойствах становится понятно что к чему), но то что я увидел это было - набор символов. Модули не прокомментированы совершенно, переменные (в том числе массивы) имеют непонятные названия вообще в виде отдельных букв типа $k, $v, $lang['n'], $t, $ml (да блин их уйма). Конечно можно разобраться что значит каждая переменная и всё встаёт на свои места. Но! Сколько времени на это надо это просто ппц, учитывая что через 5 минут уже забываешь что эта одна буква значит, это тяжело для освоения. Методы и классы, тут вроде получше, комментарии наблюдаются, но хочу отметить, что перековырять кучу файлов чтобы понять что значит тот или иной класс это тяжко. Если была бы структурированная мини документация по всем классам и методам то я был бы только благодарен как разработчик. Сейчас по сути тяжело разбираться во всём что написано, когда легче и быстрее написать самому.

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

Спасибо за внимание,
С Уважением, Влад.


PS Троллей прошу не беспокоить!

Неплохо бы примеры привести.


Я не совсем понимаю, что нужно комментировать. К примеру, назаничение переменных $k и $v, которые вытекают из цикла foreach не совсем понятно, зачем комментировать. $lang['n'] - тут, по-моему, имя переменной говорит все само за себя (как его комментировать). $t и $ml - тут, пожалуй, соглашусь, но покажите пример, где они используются.
Шаблонизатор прокомментирован так, чтобы было понятно, какие переменные идут на вход, что содержат и за что каждый метод отвечает. Поскольку в самом шаблонизаторе нет каких-то сверхсложных алгоритмов - я не комментирую ничего внутри методов. Но если какие-то участки вызывают недоумение / удивление / ахтунг - я всегда на форуме могу объяснить что к чему.


Согласен, если кто-нибудь мне поможет, а именно сделает структуру такой документации, чтобы мы осталось её только заполнить. Или, еще лучше, сделает её сам - на основе моих письменных объяснений что к чему (с меня - бонус). Я ведь достаточно занятой человек и времени на все эти мелочи просто не хватает.

Я уже ругался на это, и по этой причине до сих пор остаюсь на RC5 и не жалею об этом.

Loader, все же я не вижу большой проблемы с короткими названиями переменных. Приведите примеры, чтобы было что обсудить.

Дело в том, что у них "неговорящие" имена. Если в RC5 посмотреть на переменную $content то сразу ясно что это. А вот $c это менее информативно и понятно. Я бы даже назвал их "машинными" переменными.

Loader, а по содержимому что в нее пишется - нельзя догадаться? Тем более число переменных $c в актуальной версии много меньше числа $content в RC5.

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

Мое мнение такое, что почти все однобуквенные переменные понятны. Их смысл вытекает из контекста. Просто ТС стартер хочет документированность. Да и удобнее написать переменную в один-два символа.

Да, понятно что lang это языковой массив. Но непонятно что значит буква "n" внутри него. Какой перевод она содержит. Конечно можно открывать файл и посмотреть, или установить навороченную IDE типа phpstorm, которая тут же подскажет. Но не все знают и не все пользуются такими IDE. У меня, например, обычный такой себе редактор, к которому я очень привык и мне с ним удобно.

Суть во всём этом сделать понятные для чтения переменные. Да, можно посмотреть и разобраться что они значат. Но зачем? Зачем если достаточно посмотреть только на его имя, чтобы узнать что оно значит.

Вот пример вашего цикла foreach

Вот мой пример:
foreach($errors as $key=>&$value)

Всё. Рядовому разработчику уже будет легче. Или вот еще пример:

Вот мой вариант:
$time = time();

Можно. Но зачем тратить на это время. При чём везде по чуть чуть потерянного времени = получается уйма. Я думаю тут обсуждать особо нечего.
Суть в том, что в этой теме я прошу Вас писать код понятным для Всех. Я конечно понимаю, что для Вас исходный код понятен и не вызывает недоумений. Но это ведь потому что Вы разработчик. Вы писали и вы знаете что значит любой объект, массив или класс. К тому же у каждого свой стиль программирования, свой "подчерк". И ему сложно разобраться в чужом если он использует понятия return $result; а вы используете return $c;

Еще самое главное чуть не забыл, было бы неплохо прокомментировать один из модулей (например, новости) детально. Чтобы можно было изучить логику работы приложения и начать им пользоваться.

Да и еще, попрошу во всех файлах писать его назначение. Видел в некоторых есть, в некоторых нет. В итоге я открываю файл, там нету разъяснения для чего он нужен и где применяется.

Насчёт составления нами документации. Я может не против был бы её сам составить и написать, но я не уверен буду ли я пользоваться этой системой (CMS) в дальнейшем. Эта неуверенность как раз появляется от того, что я не уверен насколько Ваша CMS удобна и на сколько она соответствует моим ожиданиям. Насколько она гибкая, широкая и модульная. Для этого мне надо сначало её изучить, а изучение занимает много времени особенно в Вашем случае. Тем не менее, от использования CMS осталось много положительных эмоций, но есть к чему стремится. Пока архитектура нравится.. попробую покопаться глубже.

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

Согласен. Но как в таком случае поступать с предложениями? Приведите пример.

В остальном мне даже сказать нечего. Очень дельные советы. Модуль новости скорее всего будет прокомментирован в зависимости от наличия свободного времени. Если же будут возникать проблемы с пониманием отдельных участков кода - пишите здесь, буду объяснять.


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

Добавлено через 0 минут, 41 секунд:


Например?

Оперативно.

P.S. сколько у вас местное время?
P.P.S. Пока вы читали мой комментарий, я его немного изменил и дописал. Не думал что так быстро вы сюда заглянете

Одно из предложений для универсальности читабельности исходного кода = результату выполнения функции или метода класса давать имена $result (что значит как результат выполнения функции, метода). На выходе получаем

/**
* return array $result возвращает массив настроек из таблицы settings
*/
function () {
/*ля ля ля*/
return $result;
}

Не совсем понял вопроса. Дать советы, где нужно изменить переменные? Или что?

Хорошо! Учту!

Например, время. Если изучение Вашей CMS займёт у меня продолжительное время, то проще уже новую написать под свои нужды. Пусть и не с таким функционалом, но с необходимым мне.

Вообще мне нравится Ваш настрой и поддержку. Не везде такое встретишь. Поковыряюсь с месяцок когда будет свободное время появляться. Посмотрим.

Ну вот смотрите. Иногда заменяется не слово, а целое длинное предложение языковой константой. Тоесть:

$lang['...']='Длинное-длинное предложение';

Что лучше поставить вместо трех точек?


5:30 . Но, поскольку, за сайтом я слежу - отвечать стараюсь оперативно.


Если не сидеть в одиночку за компом, а задавать вопросы здесь - дело пойдет и быстрее и веселее.


Идея ясна. Правда, она чуть расходится с моим представлением о компактности... Может обойтись просто маленькой буквой $r, а в начале каждой функции / метода написать:

/**
 * @return $r
 */

?

В таких случаях, когда неясно что писать в имени переменной, используются такие же понятия как и в css. Например указывается место расположения, блок, свойство, действие. Остальное дело вкуса. Но не такие извращения lang['nc'];

Мне нравится Ваш настрой и поддержка! Думаю, это уже стоит того, чтобы работать с Вами

Мне с Вами будет понятно например. Но новые разработчики сразу не разберутся в этой букве $r. В этом и есть препятствие. Уменьшить время на изучение. Конечно после внимательного изучения становится всё понятно. Но зачем тратить на это время, особенно новичкам. Я понимаю здесь Вашу озабоченность. И по поводу представления о компактном коде тоже. Но, тут надо выбирать. Либо привлекать аудиторию разработчиков, либо выбирать компактность..
В принципе, именно с вариантом $result особо больше ничего не придумаешь. Я бы сделал всё равно $result нежели чем $r. При чём сделал бы её во всех функциях и методах как стандарт. Хотя, как вариант можно указать $r и пояснить в документации к разработчикам что это значит. Хотя тоже не всегда прокатит. Некоторые читают между строк, либо забывают сразу что прочтут (Бывает такое и у меня особенно в час ночи).