Самопис для форума

А зачем столько статики? В чем ты видишь плюс такого подхода?


И это плохо. Есть куча зависимостей. Я не смогу скопировать к себе в проект этот класс не изменив его код. Связи должны быть как можно слабыми. В идеале должна быть возможность скопипастить твой реквест в другой проект и чтоб совсем без правок.


А чего сразу класс если нужно по простому - опиши в базовом контроллере метод редирект и все дела


А можно подумать на форум через CLI будут ходить


Ключевое слово "внутренние". Опять же зависимости что не есть гуд.


Думаю это должен решать роутер.

1) Без создания экземпляра не выделяется дополнительная память.
2) Для получения ссылки на экземпляр где-то в другом месте нужен какой-нибудь getInstance(), а это? еще одна сущность которая скушает памяти еще?
3) Скажем "нет" рекурсивным ссылкам в разных сущностях. А GC ох как не любит такие рекурсивные ссылки. Сколько его не оптимизировали, всеравно не любит, и течет.
Это к фреймворкам, которые по 20 метров на хеллоуворлд кушают. А тут, к сожалению (или счастью?), связь компонентов не слабая.
Почему редиректить должен контроллер? По мне так он должен отработать свою логику, и если ему надо, позвать Request::redirect()
Крон будет ходить. Не вгетом или курлом, а в CLI.
Да, многие компоненты работают так же - складывают в нутри себя какие-то кучки данных и отдают их через геттеры.
Это должен решать роутер?

-----
Шта? Репозиторий?

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

-----
Just do it

Хм тогда проще писать в процедурном стиле )) Как по мне - то лучше в целом пусть отожрется на 2 метра больше за то в угоду удобства и гибкости


Так реквест же это не редиректор какой нить. Реквест, запрос. Завтра тебе понадобится сделать редирект по имени роута его тоже в реквест оформишь или пойдешь переписывать все двигло где ты вызывал Request::redirect() ? Или нет, дай угадаю, редирект оставишь в реквесте а для роут-редиректа придумаешь что то ещё))


А у тебя есть такой роут? Думаю нет... там же пользователь и получит заветный Not found

Порой экономия на спичках дорого обходится поверь

В точку! Записал в TODO с пометкой "подумать кому рассовать ф-ционал".
(Добавление)
Ой не сравнивай, процедурка в пыхе это адъ. Если в сях хотябы глобальные переменные можно без костылей, то в пыхе будешь везде писать global внутри ф-ций ))
У нас там автороут, без описания маршрутов. Положил контроллер в папочку - получи точку доступа. Именно поэтому нет смысла вообще этот автороут запускать если запрос невалид.

Помечу оффтопом. Многие в курсе моего отношения к "спичкам".

-----
Шта? Репозиторий?

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

-----
self-banned

Нарыл вот такое
Как оно? Будет съедобно?
(Добавление)
Еще один путь
(Добавление)
Засим, я пока пропущу момент с пинанием конекшнов, на сейчас закостылю сингловый.
А когда устаканим что и как именно будет использоваться - при необходимости поправлю.
Сейчас же двинусь дальше, тут вон, две страницы критики, есть чем заняться.

-----
Шта? Репозиторий?

Почему бы не внедрить Service Locator?

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

Редирект по сути всего лишь заголовок, так что в респонсе ему есть место быть.
Если понадобится редирект на роут, то у роутера запрашиваем URL по роуту и передаём его в метод редиректа респонса.

а сколько то физических серверов есть чтобы думать о кластере. возможно их два или вообще один. тогда какой может быть кластер.

1. автолоадер лучше подключать извне а не в индексе
2. все о том же автолоадере. я предпочитаю абсолютные пути и поетому добавил бы ROOT директорию пред подключением. но это ИМХО
3. App::run($useMemory, $startTime, $isCLI); - логичней если дебаг, то внутри метода запоминать и визивать функции memory_get_usage, microtime. это ж глобальные переменные . причем функции всегда визиваються. а по сути перед этим практически никакой логики кроме инициализации констант и автолоадера нету.
4. в App::run куча статикы инициализаций нагло вшитий. ИМХО лучше сервис локатор или фабрику дергать
5. ДБ - я уже говорил что тут лугче использовать Lazy Load. зачем дергать базу, если она может и не нужна будет.
6. реквест я все же бі сделал не статичным. там можно было даже использовать два наследника один для веба ($_GET, $_POST, $_SERVER) другой для CLI (argc, argv)
7. на счет View. мне больше нравиться return в action-е. например return $this->rendrer('view_path', array($params));

это я так бегло глянул в код. все написаное ИМХО

(Отредактировано автором: 18 Декабря, 2014 - 14:48:55)

Еще 1 важнейшиейший вопрос. Почему то никто даже не упомянул его. Может я что то пропустил?
Как планируется управлять зависимостями? Только не говорите что через pear
(Добавление)
И как обстоят дела с ресурсами типо цсс картинок итд? Будут они храниться в куче или предусмотрен (планируется) компонент управления ресурсами и их зависимостями?

Это же закладка на будущее.
Я оформил в индексе, т.к. сразу же вызываю App уже без "позорных" инклюд.
А оно там есть - константа APPLICATION. Единственное - все ядерные компоненты лежат в глобальном неймспейсе.
Так эту логику счетчик тоже считает, потому и объявлено в самом-самом начале.
init() === статический __construct(). Подробности в самом низу.
Суть уловил, разберемся с местер-слейв, заодно и с ленью базы. Я кстати Мелкому задавал вопрос делать ли ленивые коннекты. Он пока не ответил.
"Ну вот опять" - подумал горшок с петуньей.
А мне нравится возможность набросать данных и затем одной командой переопределить (указать) формат фозвращаемых данных - html, xml, json, txt.
Какими?
Сейчас просто лежат в отдельном месте, разложены аккуратными кучками.
Если придет Дельфин - то точно будет LESS/SASS. Он это дело любит.

Про статику:

Объясните в чем профит создавать экземпляры когда заранее известно, что это синглтоны? И в чем профит для
AnotherWrapper::getSomeClassInstance('Blah')->method();
или
$AnotherWrapper->Blah->method();
или
$AnotherWrapper->getBlah()->method();
или
function ($Blah) { $this->Blah = $Blah;
относительно к

\Blah::method();

Вам же самим придется думать как передать желаемую сущность куда-то, через аргумент или дергать еще одну вспомогательну сущность, чтобы получить ссылку на нужную.
Вот оно - классы ради классов, ООП ради ООП.
Посмотрите как начинаются статьи в интернете - почти все, со слов "Проблемы создания, хранения и получения экземпляра." и даются паттерны для решения.
Ага, написать и оттестировать еще 1-3 вспомогательных класса просто для того, чтобы обеспечить доступность сущностей в других местах.
И это только потому, что эти сущности изначально где-то объявлены через new Entity();
К чему создавать лишние экземпляры? Ты сам же будешь потом еще думать кого позвать для той или иной цели.
Это я вам как горшок с петуньей говорю, кашалоты вы мои ))
(Добавление)
Шило на мыло?
Да, я уже ответил паноптику, что вынесу редирект и хедеры в респонз.

-----
Шта? Репозиторий?

Пропустил, значит. Да, конечно, делать.

-----
PostgreSQL DBA

DeepVarvar не злись я сказал что это мое мнение. лично я считаю все же создание обьекта лучеш статики, потому что потом можно легко его подменить, а такие случаи я встречал за свою практику. Вот и моенно поетому взял для себя за правило минимум статики. если мне нужен синглтон, то например сервис-локатор умеет делать синглтон (да знаю там все равно будет инстанс внутри). Но здесь идеть речь не ООП ради ООП, а ООП ради удобства не более. С таким подходом зачем тогда на будущее делать класеризацию, если нельзя на будущее нельзя делать подмену обьектов. вот к чему я веду.

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

Да не злюсь я, просто юмор такой с кашалотом.
А если надо будет подменить локатор? ))
Шашечки или ехать?
В частности - напомню, что моя защита статики касается только глобально используемых сингтонов-инстансов, остальные то у нас лениво лежат в App ну и коннекты в отдельном месте.
(Добавление)
А что насчет вариантов на стороне мускуля?

И еще - ты писал что не любишь актив-рекорд модели, я скажу что я их вообще не люблю.
Но это не дело будет - обделить остальных хоть какими-то моделями.
Так вот, какими ты видишь модели?

-----
Шта? Репозиторий?

я пропоную сделать небольшой хедпер аля DBL для быстрого INSERT, UPDATE, DELETE
например