обплюйте фреймворк

[fixxxer]

о, у нас тут специальная олимпиада.

давайте еще обсудим переносить ли { на новую строку =)

 

[HraKK]

Следуйщий вопрос будет - а почему пробелы после скобок стоят!!1111адын-адын!

 

[Ирокез]

Вообще как можно "обплювать" фреймворк если он только реализуется и что будет в предфинальной версии неизвестно.

загадка со структрой
Модули\
Приложение
и др. папочки, а так-же внутренная их коррелация интуитивно непонятна
к чему столько папочек? всмысле логика понятно что происходит, непонятно зачем количественно столько папочек особенно в которых содержится один файл entity.

и уж совсем непонятно что надо для "hello world"

 

[craz]

не после скобок пойдет)

ваще главное единство кода, если уж пишешь везде проблемы то надо писать пробелы

 

[Zh0rzh]

Пробелы - это стандарт дефакто. Его придерживаются и PEAR, ZF и Symfony и др.

Вся проблема в том, что табы везде по разному отображаются. И зачастую под них отводят гораздо больше места (8 символов к примеру). И не везде можно настроить правильное их отображение.

А я вот хочу, что бы всегда и везде и у всех величина отступа была в 2 символа. С помощью табов такое вообще не сделать.

 

[HraKK]

Ирокез
А что именно не понятно со структурой?
Папочки с 1 файлом - и что? Это namespace

Zh0rzh
+

 

[Ирокез]

>>А что именно не понятно со структурой?
Что надо для написания минимального модуля?
Я вижу что программистам которые будут использовать фреймворк, надо будет практически выучить его, хорошо если они понимают шаблоны проектирования. Даже опытному программисту придется почесать репку (ну я покрайней мере почисал, хотя может я и не опытный ) ), чтобы понять что как соотносится.

>>Папочки с 1 файлом - и что? Это namespace
Это понятно, но предствь как в IDE будет отображаться такая структура при достаточно большом кол-ве модулей
entity.php
--
entity.php
--
--
entity.php
помойму это взрыв мозга.

Что касается субъективно взгляда на организацию (не путать с кодом, стилем и идеологией) фреймворка, мне он по вышеперечисленным причинам не нравится и для работы над крупным проектом (биллингом) он будет не удобен (имхо)

 

[craz]

Автор оригинала: Zh0rzh
Пробелы - это стандарт дефакто. Его придерживаются и PEAR, ZF и Symfony и др.

Вся проблема в том, что табы везде по разному отображаются. И зачастую под них отводят гораздо больше места (8 символов к примеру). И не везде можно настроить правильное их отображение.

А я вот хочу, что бы всегда и везде и у всех величина отступа была в 2 символа. С помощью табов такое вообще не сделать.

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

 

[Gas]

... тут был оффтоп относительно пробелов ) ...

 

[HraKK]

Ирокез

Что надо для написания минимального модуля?

2 файла - Application.php и его bootstrap.

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

хорошо если они понимают шаблоны проектирования

Это да, фреймворк не рассчитан на людей которые не спецы в ООП.

entity.php
--
entity.php
--
--
entity.php

Не пойму, причем тут Entity? Это вообще только для Guestbook
И выглядеть она будет так

Modules/
    /Guestbook/
         /Controller/
              -Some.php
              -Another.php
         /Router/
               -Default.php
    /SomeModule/
            /Controller/
               -Some.php
               -YetOne.php
            /Router/
               -Default.php

Что тут плохого/неясного? Идентичная помоему используется уже везде и давно, даже в ZF.

 

[Ирокез]

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

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

>>И выглядеть она будет так

Modules/
    /Guestbook/
         /Controller/

Дублирование названий файлов\папок для меня тяжело воспринимается и часто приводит магической комбинации ctrl+z или откату до ревизии.

Вообще понятно дело, я сравниваю со своим подходом:

Modules/
    /Guestbook/
         i18n/
         tpls/
         Guestbook.module.php
         Guestbook.controller.php

так у меня выглядит. от лоадера пока отказался, плохо это или хорошо хз. Для создания простого модуля, достаточно создать папку, если контроллер не надо, то не создаем .controller.php. гибкости вполне хватает для ERP.

 

[HraKK]

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

Стандарт дефакто есть, ты его видешь у меня. А Loader в основном нужен для подключения виджетов в шаблонах или работе с внешними приложениями. например dompdf. Регистрируем контекст думпдф свободно подключаем, делаем нужные действия и завершаем контекст, вуаля.

так у меня выглядит.

А у тебя дублирующий код в файлов Но это опять холи вар на заданные незначительные темы. Мой формат - позволяет детерминировать сущности по неймспейсам. Этот спор мне напоминает спор об надобности или ненадобности неймспейсов.

Для создания простого модуля, достаточно создать папку, если контроллер не надо, то не создаем .controller.php

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

 

[Ирокез]

Реально в большом проекте, мне кажется, адекватное ядро фремворка лишь малая часть, основное это гибкие и удобные хелперы (виджеты о чем я раньше говорил, формы, валидаторы, шаблоны).

Что касаемо неймспейсов, ты прав, холиварить нет смысла. Мне хватает одной степени вложенности, а еще с приходом __callStatic, вообще песня

Module::GusetBook()->method.

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

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

Все это я говорю применительно в контексте биллинга. Конечно если ты не один его реализовываешь

 

[AmdY]

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

но вот это полный пипец

class Modules_Guestbook_Entity implements Core_Db_Mapper_Interface
{
	public function __get( $key )
	{
                          // WTF 
               return htmlspecialchars( $this->getMapper()->$key );
	}
}

Кстати да - эскейпить задача View, ну лично у меня так)
http://phpclub.ru/talk/showthread.php?postid=889906#post889906

 

[HraKK]

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

public function __get( $key )
{
// WTF
return htmlspecialchars( $this->getMapper()->$key );
}

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

А вью эскейпит все что в него всунули.

 

[Single]

Пока, грубых ошибок мне не сказали.

Я не выкладываю его как рабочий

может в этом все дело.
На сколько этот FW "правильно" написан мне кажется может судить только автор сего творения зная исходную задачу под которую он собсно и писался.
Вот если ваш фреймворк планируется дорабатывать до обще доступного тут уже думаю будут другие отзывы.

 

[HraKK]

дык, а я что я делаю как не спрашиваю Ваше мнение стоит ли его дорабатывать под всех или ну его?)

 

[Ирокез]

Автор оригинала: HraKK
дык, а я что я делаю как не спрашиваю Ваше мнение стоит ли его дорабатывать под всех или ну его?)

Ну его...
Посмотрел повнимательней...
есть сказочные моменты ->getResource()->getResource('...')

то-же интересный момент
$r = ...->getRequest();
$v = $r->getPost('');
глубже не копал, просто уже "непонятно" зачем такое словоблудие request, а из него post

$this->getView()->setTemplate('../.../......'); очень нечитабельно

опять-же прицепить интерфейс Serializable типам данных в кеше.

 

[HraKK]

есть сказочные моменты ->getResource()->getResource('...')

А чем не нравиться?

зачем такое словоблудие request, а из него post

потому что post это часть реквеста.

$this->getView()->setTemplate('../.../......'); очень нечитабельно

Та, это затычка сделанная наспех для guestbook
Там будет для аппликейшена устанавливаться путь к шаблонам.

опять-же прицепить интерфейс Serializable типам данных в кеше.

м?

 

[Single]

>>> /billing/Application/Bootstrap.php

$Application->getAdapter()->setDatabase( $Application->getParam( 'dbName' , 'sample' ) );

это нечто. может стоить вернуться к привычным массивам хранящим какие то настройки?