Это зомби-монстр из начала 2000-х, когда мы говорим enterprise и подразумеваем developers, developers, developers десятки тысяч строк кода что бы сделать базовые вещи. Все уже давно переболели этой болезнью (весь ентерпрайз с java и стеком мс), когда один продукт должен был уметь делать все и сразу, а количество конфигурационных файлов на xml по объему было близко к количеству всего кода в продукте.
Вы когда-нибудь работали с большим количеством форм, в котором куча полей. Вот к примеру наши геймдизайнеры работали. И многие поля связанные со времеем у нас были либо в секундах по дефолту, либо в форматах: h m s | m s | s либо в 10w 3h 1d 6s — потому что это быстрее. быстрее написать 600 для 10 минут, быстрее написать 12 01 44 для 12 часов 1 минуты и 44 секунд. быстрее написать +1w для одной недели. нежели выбирать две даты из календаря.
Повторяю вопрос: сколько строк кода мне придется написать для того, что бы перекинуть один объект моей модели в объект ZF? 50? 150? 250 для большей модели? В остальных фреймворках порядка 4-5.
Потому что они понимают, что если написано int — то надо хотя бы проверить на то, что это интовое значение, а не «Привет я Вася».
Да это понятно что там Zend_Config везде, так что можно хоть в бинарном формате ему скормить описание (я и такое делал), но по дефолту они везде в описаниях пихают ini. Что собственно распростанило это более чем прекрасный формат для простых конфигов (простых, а не иерархичных!) на множество проектов.
Вы когда-нибудь пробовали изменить рендеринг форм? У нас вот форма должна была рендериться в представление extjs (почему было именно так — долгая история), а вот красивняшка ZF жестко завязана на htmlююю
Что это за болезнь, для каждого пакета делать свои исключения. Люди, которые так делают, разве ниразу не работали с исключениями что бы понять, что в 97.22% случаев в кэтче будет либо Throwable, либо Exception, еще в 1.93% там будет попытка обработать какое-нибудь не самое приятное исключение, а в остальном — какой-нибудь треш жуниора
Если в IDE в которой вы пишите нет автоимпорта… то я бы вам советовал выбрать другую IDE. Скорость написания кода на PHP и так гораздо меньше нежели на другом нормальном языке (из за многих факторов), а если меня еще и самого заставят импорты прописывать…
Как показала практика (да и требования ui дизайнеров) — люди не всегда быстро замечают где ошибка, если допустим мы подсвечиваем три поля, а не именно то в котором ошибка.
Потому что Errors — не самое лучшее название для класса. В нормальных языках работа с неймспейсами прозрачна. В яве вообще пишут com.companyname.productname.someshitname.forms.BlablaForm, но кого волнует в каком пакете это все лежит если нормальная иде номально все импортит
Реальный пример — дата и время, на клиенте поле в котором можно написать 150 или 2:20 или 2:20:34 или это несколько полей: календарь + две крутилки времени. В модели — таймстемп, в реальности надо сказать человеку где он ошибся. Как тут быть?
Это ужасно. Во первых это ужасно потому, что не факт что все что у меня есть в форме у меня есть в модели, к примеру у меня некоторые поля в модели могут быть разделены на 2-3 поля в форме. Да и это не главное, как мне юзеру выдать то, что у него во втором поле ошибка а не просто «форма неправильная, давай заново».
С того, что я с ними долгое время работал. С того, что мне приходилось доделывать некоторые кастомные компоненты. Как думаете, сколько строк кода и времени у вас займет создать в зендовых формах форму которая отличается всего лишь одним полем от модели. А теперь ошибки перевести на 2 языка, да понятные пользователям системы.
Да взгляните на одно только описание формы в ini от которого блевать тянет (а они же до сих пор, в отличие от всех остальных, кто давно уже на ямле) все либо в xml либо в ini делают
Мне кажется я знаю о чем говорю потому как у меня есть с чем сравнивать: с симфонией работал, пришлось (потому как остальные варианты были еще хуже). Хотя хочу сказать, что если бы была возможность переписать все на спринг — сделал бы не задумываясь, но увы, пришлось возиться с этой жалкой копией (и плюс такой же жалкой копией хибернейта).
Жалкой потому что возможности языка позволяют многие вещи сделать красиво, а разработчики просто скопипастили с топорной явы. Жалкий потому что скорость написания одних и тех же действий на яве быстрее в разы, потому как иде не путается в комментах и выдает правильный ассист. Жалкий потому что ServiceLocator выдают за DI.
К сожалению с yii знаком давно и был не лучшего мнения о нем, поэтому даже не смотрел на него, но если вы сейчас кинете сюда кусок кода работы с формами и бд буду благодарен (хотя бы увижу во что он превратился). Собственно к нам прилетает форма, мы ее валидируем и если все хорошо — пишем все поля из нее в базу, если нет — говорим в каком поле ошибка и возвращаем обратно
Пустую нишу. На данный момент это единственный более-мение годный фрейворк на данном языке. ZF сильно хуже, остальные либо достаточно слабые, либо никакие полностью. А для быстрого разворачивания — рельсы, как ни крути.
Я сейчас не могу найти ни одного случая, когда бы мне пришлось бы расширять возможности фреймворка, без осознания того, что такой фреймворк мне уже не нужен. Когда после пары недель с момента «ну сейчас, тут допилим… и вот тут» — фреймворк выкидывался и брался другой — знаю с десяток. Два из которых ну просто клинические, к сожалению, в одном из них я был ключевой фигурой (увы, на тот момент я не мог повлиять на ситуацию): и напихав десяток кослытей все таки смог соединить две вещи, реализаця которых бы, даже самописная была гораздо быстрее и проще.
Так что то, что они там накидали пару лишних слоев абстрации для того, что бы кому то пришло в голову что-то там дополнить, допилить и заменить говорит только о двух вещах: первое они все еще не уверены в своих силах и не могут написать действительно удобную вещь. Второе — они создали себе лишние проблемы как с кодом, так и с пользователями фреймворка
Это зомби-монстр из начала 2000-х, когда мы говорим enterprise и подразумеваем
developers, developers, developersдесятки тысяч строк кода что бы сделать базовые вещи. Все уже давно переболели этой болезнью (весь ентерпрайз с java и стеком мс), когда один продукт должен был уметь делать все и сразу, а количество конфигурационных файлов на xml по объему было близко к количеству всего кода в продукте.Потому что они понимают, что если написано int — то надо хотя бы проверить на то, что это интовое значение, а не «Привет я Вася».
Да это понятно что там Zend_Config везде, так что можно хоть в бинарном формате ему скормить описание (я и такое делал), но по дефолту они везде в описаниях пихают ini. Что собственно распростанило это более чем прекрасный формат для простых конфигов (простых, а не иерархичных!) на множество проектов.
Вы когда-нибудь пробовали изменить рендеринг форм? У нас вот форма должна была рендериться в представление extjs (почему было именно так — долгая история), а вот красивняшка ZF жестко завязана на htmlююю
Да взгляните на одно только описание формы в ini от которого блевать тянет (а они же до сих пор, в отличие от всех остальных, кто давно уже на ямле) все либо в xml либо в ini делают
Жалкой потому что возможности языка позволяют многие вещи сделать красиво, а разработчики просто скопипастили с топорной явы. Жалкий потому что скорость написания одних и тех же действий на яве быстрее в разы, потому как иде не путается в комментах и выдает правильный ассист. Жалкий потому что ServiceLocator выдают за DI.
Так что то, что они там накидали пару лишних слоев абстрации для того, что бы кому то пришло в голову что-то там дополнить, допилить и заменить говорит только о двух вещах: первое они все еще не уверены в своих силах и не могут написать действительно удобную вещь. Второе — они создали себе лишние проблемы как с кодом, так и с пользователями фреймворка