JLayer

L!MP, ну в каше я тоже возиться бы не захотел Вобщем всё, закрыли тему. Уже который час собираюсь продолжить сесть писать и всё время что-то отвлекает.

L!MP (08.07.2013 / 15:09)
МVС там, разве что, только в извращённом понятии.
Контроллеры/Модули - не обьекты, а такая же лапша как и сейчас.
Модели - ну, их нет.. вобще нет. Вся бизнес логика, как и раньше, прямо в коде.
За

Ооо, это батл? гг
Ну что же, давай поупражняемся в словестности.
---
Итак, летит первая какаха:
Покажи мне, где в интернет скриптах правильно реализовано MVC?
Да и вообще, а как правильно?

З.Ы.
Немного отклонимся от батла и вспомоим, откуда вообще взялось MVC?
А взялось оно от языка Smarttalk и потом перекочевало в другие языки программирования.
Причем, в РНР оно было притянуто "за уши", то есть поидее, в классическом виде (как рисуют на диаграммах) оно вообще в РНР не нужно.
Почему?
А давайте вспомним разницу между компьютерной программой, которая висит в памяти компьютера (будучи запущенной), взаимодействуя с пользователем посредством какого-либо интерфейса и сравним это с РНР, который является скриптовым языком, то есть код выполняется последовательно и о каком-либо взаимодействии представления с моделью говорить не приходится.

Посему, еще раз спрашиваю: а какой MVC правильный?

AlkatraZ, я вспоминать ничего не буду, ибо я вобще не имею представления как пишется современное прикладное ПО и игры.

Я об обычном МVС, который применяется в веб приложениях.
Об МVС, как способе логического разделения и стуктуризации кода приложения.
Об МVС как архитектуре и методике разработки, которая, с минимальными поправками, одинакова хоть в ROR (ruby), хоть в YII (php), хоть в PlayFramework(java), что обеспечивает "лёгкий старт" разработчику.

L!MP (08.07.2013 / 17:53)
что обеспечивает "лёгкий старт" разработчику.

Ну это не скажи гг...
Ты еще вспомни Symphony, это кстати наглядный пример, они первые осознали, что классическая MVC по диаграмме - это не для интернет-скриптов.
---
А в остальном - важна свобода творчества, а не то, как нам предписывает Yii, Kohana и иже с ними. Если можно сделать в несколько раз короче и быстрее, почему бы не делать?

Да и в реализации...
MVC - это не обязательно ООП, я уже в другой теме про это писал.
Контроллер вовсе не обязательно должен быть классом. Да, если ты уже начал реализовывать классическую ООП модель с патернами то разумеется будут классы. Но это всего лишь один из путей реализации (которых может быть множество).

Это всё конечно интересно, но не могли бы вы продолжить холивар в другой теме и НЕ СРАТЬ В МОЁМ УЮТНОМ БЛОЖЕКЕ?

Хотя сам холивар обещает быть интересным и я бы с удовольсивием поучаствовал в нём.

Основную часть запилил. Немного даже отладил. Там останется только c InvalidArgumentException разобраться.
Из плагинов пока только отображение пагинации добавил.
Сейчас еще запилю zip из CI и останется следующее:
Мультиязычность для плагинов.
Доработать загрузку языков, а именно обернуть stdClass в класс-контейнер для отлавливания несуществующих полей.
BB-коды.
Класс комментариев.
Обработка файлов.

Затем отладить и протестировать всё это и можно будет приступать к генератору кода.

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

Вооот. Дела идут в гору. Уже найдены и успешно пофикшены первые баги.
На данный момент пилю класс комментов.

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

Алсо, в будущем для генератора запилить генерацию контроллера для плагина комментов, чтобы вообще к классу притрагиваться не пришлось.
Захотел комменты в модуле? Забил конфиг, сгенерировал контроллер, закинул в папку. Готово. Только вот удаление комментов, при удалении родительских элементов прикрутить ручками всё равно придётся. Но там всего-лишь надо будет загрузить плагин, инициализировать его и вызвать соответствующий метод.

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

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

Ну незнаю пока, посмотрим. Да и с репозиториями я толком не работал. Знаю только как через TortoiseSVN совершить коммит и обновить у себя локальный репозиторий. Ну еще там скопировать в tags при релизе могу
Код пока показывать я стесняюсь
Чуть позже выложу сюда на форум, посмотрите, а там уже решим стоит ли развивать или нет. Если нет, то я в одну будку буду им пользоваться