Комментарии 32
Мне кажется, топик лучше перенести в блог Zend Framework
чето подглючивает.
codeutopia.net/pack/index/dependencies/class/Zend_Cache
codeutopia.net/pack/index/dependencies/class/Zend_Cache
мне кажется что это вообще нонсенс. я понимаю что иногда не нужен целый фреймворк. но тут ошибка проектирования.
если в вашем фрейморке нет функционала который есть в зф, значит вы либо должны портировать сами. либо вы плохо выбрали фреймворк для проекта. и имхо вырезать несколько классов из каждого фрейморка и держать их в куче даже более худшее решение чем использование целого фреймворка.
если в вашем фрейморке нет функционала который есть в зф, значит вы либо должны портировать сами. либо вы плохо выбрали фреймворк для проекта. и имхо вырезать несколько классов из каждого фрейморка и держать их в куче даже более худшее решение чем использование целого фреймворка.
странная точка зрения. Любите делать велосипеды, а PEAR по вашему глупая идея?
Вам нравится качество кода из PEAR?
я недостаточно работал с ним чтоб ответить, но это никак не относится к тому вопросу, который я задал
Нет. К примеру — если в ЗФ совсем не будет нужного мне решения, но оно будет в какой нибудь pear либе, я ее синтегрирую в проект, но так чтобы другой девелопер понял откуда она взялась и почему лежит там где лежит.
это прямо противоречит тому что Вы сказали ранее «если в вашем фрейморке нет функционала который есть в зф, значит вы либо должны портировать сами. либо вы плохо выбрали фреймворк для проекта»
да, неясно выразился, правда. Портирую == синтегрирую. Пример: Нужен был простейший пейджер из CI (когда в зф его еще не было) — посмотрел как он реализован в CI и сделал такой же в рамках своей библиотеки для зф (практически копипаст с некоторыми поправками) но заметте, я не взял целый кусок CI с зависимостями пейджера. И как результат стиль кода остался одинаковым, а он в ЗФ и CI отличается.
значит Вы все таки любите изобретать велосипед. Большинство же разработчиков считают вполне нормальным использовать библиотеки сторонних разработчиков в чистом виде. А для того чтобы было легко читать код достаточно сложить их в одном месте и пометить из каких фреймворков и библиотек они взяты
У меня стойкая нелюбовь (обоснованная) к такому подходу :) я уже занимался крупными проектами «после» таких девелоперов.
ну если Вам попадались плохие девелоперы — подход не виноват :). К примеру извесный и признанный фреймворк симфони в версии 1.0 использовал 10 сторонних компонент (что можно увидеть по папке licenses и lib/vendor).
Кстати предложенный Вами подход категорически не верен. Как вы будете обновлять свой «синтегрированный» код, если будет обновлятся исходный? А если это будут критические изменения? Будете делать это вручную? Намного проще и разумнее написать враппер — это решит все проблемы
Кстати предложенный Вами подход категорически не верен. Как вы будете обновлять свой «синтегрированный» код, если будет обновлятся исходный? А если это будут критические изменения? Будете делать это вручную? Намного проще и разумнее написать враппер — это решит все проблемы
мне, например, от зенда нужны только классы для работы с БД и кешированием. Остальные задачи выполняются другими средствами. Так зачем таскать весь зенд?
Тот же апдейт проще будет сделать. Хотя я все равно не юзал бы например 2 фреймворка в одном приложении.
я юзаю пять: zend framework, doctrine, prototype и css-фреймворк, и мой код, который реализует недостающий и заменяет некоторый ненравящийся функционал. если нужно юзаю класс из pear, потому что там готовый и отлаженый код.
да и в состав zend framework входит javascript фреймворк :)
да и в состав zend framework входит javascript фреймворк :)
Шикарно!
Бывают совсем небольшие проекты, в которые весь ZF класть смысла мало, но некоторый функционал был бы очень полезен.
Спасибо всем, приложившим к этому руку :)
Бывают совсем небольшие проекты, в которые весь ZF класть смысла мало, но некоторый функционал был бы очень полезен.
Спасибо всем, приложившим к этому руку :)
На самом деле польза от всего этого — лишь экономия дискового пространства. Ведь используя какой-нибудь класс ZF вы не тащите за собой весь его функционал, а только зависимые от него, что и предлагается в решении…
ради экономии места/времени мы сделали кеширование скомпиленной библиотечки:
— удалили лишние компоненты фреймворка
— написали парсер, который проходит по всем файлам фреймворка, чистит коменты и инклады, строит дерево зависимостей и по нему выстраивает очередность, следуя которой нужно объявлять все классы и интерфейсы, чтоб перент был объявлен раньше чилда и тд.
— ну и компилятор, который, следуя цепочке, клеит всё в один файл.
— задействовали механизм кеширования, чтоб этот большой скомпиленный файл всегда висел в памяти и не инкладился каждый раз снова.
в результате — большой прирост производительности.
может кому-то идея будет полезной...)
— удалили лишние компоненты фреймворка
— написали парсер, который проходит по всем файлам фреймворка, чистит коменты и инклады, строит дерево зависимостей и по нему выстраивает очередность, следуя которой нужно объявлять все классы и интерфейсы, чтоб перент был объявлен раньше чилда и тд.
— ну и компилятор, который, следуя цепочке, клеит всё в один файл.
— задействовали механизм кеширования, чтоб этот большой скомпиленный файл всегда висел в памяти и не инкладился каждый раз снова.
в результате — большой прирост производительности.
может кому-то идея будет полезной...)
Есть еще один плюс. В IDE в подсказках меньше хлама ненужного появляется.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Компоненты Zend Framework отдельно