Коля, я работал на админке Вульфа -- не писать код -- это здорово. Это правильно. То, что админка была не совершенна -- это другой вопрос, но она умела делать достаточно много, и сайт на ней развернуть можно было быстро -- основное время уходило на javascript и создание, меппинг и вывод сложных объектов. Вот что нужно оптимизировать. А подход там был исключительно правильный.
Я работал на Веб Билдер и я видел, что можно не писать код совсем, там где можно писать SQL-подобные админочные выражения, но код писался. Но даже то, что было автоматизировано -- было здорово.
Все админки не совершенны, тем заманчивей задача сделать совершенную. Кроме того, зная твою любовь к фрейморкам скажу: фреймворки враг хорошей админки. Суть фреймворка в том, что он что-то автоматизирует, но применяя его, ты становишься его заложником. Ты вынужден использовать парадигму фреймворка. Фреймворки направлены на широкий спектр задач, админки -- на узкий. Хорошая админка является инструментом для решения ограниченного перечня задач. Админка -- это как сборочный автомобильный конвеер. Аналогия 100%. Если ты будешь собирать тачки на конвеере их надежность будет высока, а себестоимость небольшая, а если вручную -- то все наоборот. Сайты -- вещь настолько формализуемая, что нет смысла использовать фреймворки или хард код, настоящее и будущее за движками как законченными инструментами.
Совершенную админку можно создать не используя фреймворков вообще.
Ненавижу с тобой спорить, т.к. разговориваешь сам с собой. Но повторю еще раз.
Это твои слова? "Сайты -- вещь настолько формализуемая, что нет смысла использовать фреймворки или хард код, настоящее и будущее за движками как законченными инструментами."
Какой именно сайт ты имеешь в виду? Каталог? Веб-страничку васи пупкина?
Я тебе говорю не про то, что данное решение является плохим, а про то, что существует круг задач которые оно решает прекрастно, но помимо них, существует бесконечное множество задач, которые ни какие фрейворки и уж совершенно точно ЭТОТ ПОДХОД не решит. Примеры я надеюсь тебе приводить не надо.
И еще раз, я не говорю что подход плохой, я лишь говорю что он не полный. А что ему не хватает, это уже совершенно другой вопрос.
И отстань ты от фрейворков, я уже понял, что ты не хочешь разбираться ни с одним. Велосипеды спасуд мир %) И кстати даже этот подход не является велосипедом, он давно уже разработан и является частным решением для EAV.
И еще раз, я не говорю что он плохой, я вообще всегда говорил что он великолепен. ООООО Великий (Шура) Вульф
Мне не впадлу разбираться с фреймворками, я просто говорю прямо: они не применимы для той CMF про которую мы говорим.
Пример. Хибер. Он мепит классы. Но у нас любой класс -- это один и тот же класс Java: CMFUserClass. Его экземпляры -- это описания пользовательских классов. Но хибер меппит не экземпляры класса, а классы. Вывод: он просто не подходит для решения задачи.
Можешь придумать самостоятельно примеры, почему для решения задачи нет смысла использовать Spring или Zend Framework или любой другой*
Проблем здесь не вижу, но только на уровне LAMP. В Джаве, к сожалению, при появлении класса нужно пересобирать проект.
Ну если мы говорим о веб-фрейворках (в частности о zf и не только), то
1) В фрейворках решон вопрос с фильтрацией и роутингом запросов 2) В фрейворках есть реализация MVC или MTC, что облегчает разработку приложений со сложными взаимодействиями 3) В фрейворках есть продуманная реализация механизма кеширования 4) В фрейворках есть продуманная реализация механизма квотироания 5) В фрейворках есть продуманная реализация механизма валидации 6) В фрейворках есть продуманная реализация механизма фильтрации 7) В фрейворках легко осущевлять перевод интерфейса приложения на другие языки
Все остальное можно отнести к рюшечкам и это зависит от каждого фрейворка в отдельности.
Но я не в коем случае не призываю тебя их использовать, каждый сам решает чем ему пользоваться при разработке.
Для админки MVC: модель -- User Class Access Language View = html Controller = UCAL interpreter + CMF back-end engine (собствена сама админка для редактирования сайта)
Хоть обосрись, но ни один фреймворк тебе не упростит жизнь, потому что проще HTML ничего нет. Все остальное -- усложнения.
Задача: Нужно сделать пошагувую форму с сохранением истории шагов (можно перемещаться назад например 4->1 4->2) и с сохранением введенных параметров. На первом шаге обязательно отволидировать каптчу. Переход на следующий шаг без серверной проверки результатов предыдущего не возможно. Перепрыгивать через шаги нельзя.
Как ты это решишь с помошью описаного тобой MVC? Только, пожалуйста, без абстракций и без "ЗАХАРДКОДИТЬ".
UCAL - это всего лишь связка модели и вида минуя контроллер.
Видимо разговор действительно бесполезны, т.к. вы уже серверные приложения сравниваете с HTML`ом.
Кстати, задачку можно усложнить, вместо простого пошагового пути можно поставить динамично изменяемый граф, задаваемый скажем через конфигурационный файл.
Я это уже делал для опросов в банке. Идея простая: форма --> мультиформа. Типы элементов формы: INPUT: text, submit. SELECT. capcha и др.
Делал на одних сервлетах ваще без использования библиотек даже. Причем дизайн можно было какой угодно насадить за 1 минуту. Ты видел вроде. И че, нахрен мне фреймворки? С ним разбираться часов 10, а всю эту бодягу писать часов 12. Нахуя козе боян?
Нет, я конечно не грю, что не надо их использовать, но делать из них культа тоже нихуя не надо.
о_0 Ктож из них культ то делает? Я этот тред начал говоря о том, что для каждого круга задач, существует свой набор инструментов. А в холиваре с тобой я всего лишь утверждаю, что использование фрейворков решает больший круг задач, чем UCAL.
Делать на сервлетах ^^ ну то есть захардкодить. Я бы с удовольствием посмотрел как ты насаживашь дизайн на одну минуту ^^.
Изучать, согласен, долго, зато какое удовольствие решать сложнейшие задачи простым наследованием и расширением функционала.
Кстати, J2EE тоже своебразный фреймворк, и в частности сервлеты и бинсы ;)
Саш и самая главная мысль - фреймворки тебе нахрен не нужны, так как ты их полюбому используешь (и зависишь от них), а во вторых, нахуяказебаян )
Как задавался шаблон? Легко. Да, выводил сервлет, у которого беда с MVC. А внутренний движок на что? Я сделал так: 1. Делаю HTML с нужным дизайном 2. Пишу в нем ключевые макрозамены: %question% %answers% %user_info% %title% %presentation% -- и вуаля! Скармливаю HTML сервлету, а сервлет возвращает мне формы опроса. (В данном случае имел место подход: хардкод функции под каждую макрозамену, но макрозамен ограниченное кол-во, по сути, UCAL -- тоже самое, только сложнее парадигма) Так вот, система была самодостаточной и не требовала написания программного кода, т.е. разработка опроса не требовала кодинга! Любой дуболом мог взять психоделичекую распечатку из отдела маркетинга и вбить вопросы варианты ответов и логику переходов и получить опрос. А прикрутив описанным выше способом дизайн опрос можно было использовать и любом автомате подключенном к инету. Вот тебе промышленное решение без использования фреймворков вообще. А до этого сидели любители "фреймворков" и кодили эти опросы -- долго, некачественно без возможности быстро и качественно обрабатывать результаты опроса.
Это может в убогом ПХП парадигма ООП революционна, а в яве она была с рождения. И не только наследование и расширение, а еще полиморфизм инкапсуляция и интерфейсы.
У UCAL круг решаемых задач уже чем у Zend FrameWork и это прекрасно. Заточенный под опеределенную работу иснструмент гораздо эффективней, чем универсальный гаечный ключ.
J2EE фреймворк? У тебя опят фрейморковская горячка. J2EE -- Это технология. Фреймворк это -- Хибер, Спринг, Струтс, JSF и т.д. Сервлеты -- это не фреймворк ни разу, а стандартное средство Java. Бины -- не фреймворк, а определенного вида класс.
Фреймворк переводится примерно как "набор инструментов". Причем законченный набор. Более того, фреймворки создают чтобы решать широкий круг задач и по монгу задач и только тогда они начинают приносить свою выгоду. А если нужно решать всего круг задач из одной задачи: разработка сайтов и прочих веб-приложений. Т.е. при создании движка, конечно, нет ничего плохого в том, чтобы заюзать тот же Зенд, но учитывая два момента: 1) не стать заложником фреймворка, так что окажется, что ты не можешь выйти за его рамки; 2) ни в коем случае не говорить, что подход -- кодить на фреймворках хорош для задачи разработки сайтов на потоке;
1) Заложником фреймвока стать нельзя, т.к. основная задача его применения - это расширение. 2) Естественно, что на потоке должна стоять CMS основанная на абстрактной CMF, которая в свою очередь должна быть основанна на каких то общих подходах к разработке, либо фреймворке.
2) Это перегиб. Самая мощная CMS которую я видел: Web Builder не была основана на общих подходах и фреймворках. Отсюда я методом индукции предполагаю, что он нахуй не нужен. У всех CMF в очень грубых чертах общий подход, а не в грубых -- разный.
Какие ты знаешь общие подходы к разработке и какой особый смысл в том, что их нужно использовать именно для разработки CMF? Абстрактной CMF? Вот это да! Я знаю, что класс может быть абстрактным, но как может быть абстрактным инструмент?
Система контроля версий да. Ну и что. Зачем вообще про это упоминать, если это не имеет специального отношения к CMF. Я говорю только про особенности, ктоторые отличают CMF от других типов ПО. Зачем говорить общие фразы? SVN -- применим для разработки любого ПО.
У тебя MVC -- это мантра что ли? MVC -- это парадигма. Ее можно увидеть везде, хоть в жопе: модель -- пищеварение, контролер -- кищечник с анусом, вид -- куча говна. Нельзя применить MVC. Даже у сервлета есть MVC -- т.е. неудобная MVC -- Это тоже MVC. Опятб общие слова не относящиеся к теме.
Я не придираюсь, просто не понял, что значит абстрактный Content Management Framework. Вот те пример: public class UserClass { // Уникальный идентификатор в пределах 1 домена: private static int id = 0; // Название отображаемое в CMF: private String cmfViewName = ""; // Название таблицы в БД: private String dbName = ""; // Поля: private ArrayList fields;
... }
А теперь я попытаюсь раскрутить твое нагромождение слов до реального смысла, и ради прикола, предлагаю сравнить с тем, что ты изначально сказал. Я не придираюсь, просто я могу понять только то, что называют своими именами. А что ты, что Легыч, грите одно, а подразумеваете другое, а потом жалуетесь, что к словам придираются.
Итак, назови мне хотя бы пару причин, почему я должен сделать класс UserClass абстрактным?
Я работал на Веб Билдер и я видел, что можно не писать код совсем, там где можно писать SQL-подобные админочные выражения, но код писался. Но даже то, что было автоматизировано -- было здорово.
Все админки не совершенны, тем заманчивей задача сделать совершенную. Кроме того, зная твою любовь к фрейморкам скажу: фреймворки враг хорошей админки. Суть фреймворка в том, что он что-то автоматизирует, но применяя его, ты становишься его заложником. Ты вынужден использовать парадигму фреймворка. Фреймворки направлены на широкий спектр задач, админки -- на узкий. Хорошая админка
является инструментом для решения ограниченного перечня задач. Админка -- это как сборочный автомобильный конвеер. Аналогия 100%. Если ты будешь собирать тачки на конвеере их надежность будет высока, а себестоимость небольшая, а если вручную -- то все наоборот.
Сайты -- вещь настолько формализуемая, что нет смысла использовать фреймворки или хард код, настоящее и будущее за движками как законченными инструментами.
Совершенную админку можно создать не используя фреймворков вообще.
Reply
Это твои слова?
"Сайты -- вещь настолько формализуемая, что нет смысла использовать фреймворки или хард код, настоящее и будущее за движками как законченными инструментами."
Какой именно сайт ты имеешь в виду? Каталог? Веб-страничку васи пупкина?
Я тебе говорю не про то, что данное решение является плохим, а про то, что существует круг задач которые оно решает прекрастно, но помимо них, существует бесконечное множество задач, которые ни какие фрейворки и уж совершенно точно ЭТОТ ПОДХОД не решит. Примеры я надеюсь тебе приводить не надо.
И еще раз, я не говорю что подход плохой, я лишь говорю что он не полный. А что ему не хватает, это уже совершенно другой вопрос.
И отстань ты от фрейворков, я уже понял, что ты не хочешь разбираться ни с одним. Велосипеды спасуд мир %) И кстати даже этот подход не является велосипедом, он давно уже разработан и является частным решением для EAV.
И еще раз, я не говорю что он плохой, я вообще всегда говорил что он великолепен. ООООО Великий (Шура) Вульф
Reply
Пример. Хибер. Он мепит классы. Но у нас любой класс -- это один и тот же класс Java: CMFUserClass. Его экземпляры -- это описания пользовательских классов. Но хибер меппит не экземпляры класса, а классы. Вывод: он просто не подходит для решения задачи.
Можешь придумать самостоятельно примеры, почему для решения задачи нет смысла использовать Spring или Zend Framework или любой другой*
* -- или есть смысл
Reply
Ну если мы говорим о веб-фрейворках (в частности о zf и не только), то
1) В фрейворках решон вопрос с фильтрацией и роутингом запросов
2) В фрейворках есть реализация MVC или MTC, что облегчает разработку приложений со сложными взаимодействиями
3) В фрейворках есть продуманная реализация механизма кеширования
4) В фрейворках есть продуманная реализация механизма квотироания
5) В фрейворках есть продуманная реализация механизма валидации
6) В фрейворках есть продуманная реализация механизма фильтрации
7) В фрейворках легко осущевлять перевод интерфейса приложения на другие языки
Все остальное можно отнести к рюшечкам и это зависит от каждого фрейворка в отдельности.
Но я не в коем случае не призываю тебя их использовать, каждый сам решает чем ему пользоваться при разработке.
Reply
Для админки MVC: модель -- User Class Access Language
View = html
Controller = UCAL interpreter + CMF back-end engine (собствена сама админка для редактирования сайта)
Хоть обосрись, но ни один фреймворк тебе не упростит жизнь, потому что проще HTML ничего нет. Все остальное -- усложнения.
Reply
Задача: Нужно сделать пошагувую форму с сохранением истории шагов (можно перемещаться назад например 4->1 4->2) и с сохранением введенных параметров. На первом шаге обязательно отволидировать каптчу. Переход на следующий шаг без серверной проверки результатов предыдущего не возможно. Перепрыгивать через шаги нельзя.
Как ты это решишь с помошью описаного тобой MVC? Только, пожалуйста, без абстракций и без "ЗАХАРДКОДИТЬ".
UCAL - это всего лишь связка модели и вида минуя контроллер.
Видимо разговор действительно бесполезны, т.к. вы уже серверные приложения сравниваете с HTML`ом.
Reply
Reply
Идея простая: форма --> мультиформа.
Типы элементов формы: INPUT: text, submit. SELECT. capcha и др.
Делал на одних сервлетах ваще без использования библиотек даже. Причем дизайн можно было какой угодно насадить за 1 минуту. Ты видел вроде.
И че, нахрен мне фреймворки? С ним разбираться часов 10, а всю эту бодягу писать часов 12. Нахуя козе боян?
Нет, я конечно не грю, что не надо их использовать, но делать из них культа тоже нихуя не надо.
Reply
Делать на сервлетах ^^ ну то есть захардкодить. Я бы с удовольствием посмотрел как ты насаживашь дизайн на одну минуту ^^.
Изучать, согласен, долго, зато какое удовольствие решать сложнейшие задачи простым наследованием и расширением функционала.
Кстати, J2EE тоже своебразный фреймворк, и в частности сервлеты и бинсы ;)
Саш и самая главная мысль - фреймворки тебе нахрен не нужны, так как ты их полюбому используешь (и зависишь от них), а во вторых, нахуяказебаян )
Reply
А внутренний движок на что? Я сделал так:
1. Делаю HTML с нужным дизайном
2. Пишу в нем ключевые макрозамены: %question% %answers% %user_info% %title% %presentation% -- и вуаля! Скармливаю HTML сервлету, а сервлет возвращает мне формы опроса. (В данном случае имел место подход: хардкод функции под каждую макрозамену, но макрозамен ограниченное кол-во, по сути, UCAL -- тоже самое, только сложнее парадигма)
Так вот, система была самодостаточной и не требовала написания программного кода, т.е. разработка опроса не требовала кодинга! Любой дуболом мог взять психоделичекую распечатку из отдела маркетинга и вбить вопросы варианты ответов и логику переходов и получить опрос. А прикрутив описанным выше способом дизайн опрос можно было использовать и любом автомате подключенном к инету. Вот тебе промышленное решение без использования фреймворков вообще. А до этого сидели любители "фреймворков" и кодили эти опросы -- долго, некачественно без возможности быстро и качественно обрабатывать результаты опроса.
Это может в убогом ПХП парадигма ООП революционна, а в яве она была с рождения. И не только наследование и расширение, а еще полиморфизм инкапсуляция и интерфейсы.
У UCAL круг решаемых задач уже чем у Zend FrameWork и это прекрасно. Заточенный под опеределенную работу иснструмент гораздо эффективней, чем универсальный гаечный ключ.
J2EE фреймворк? У тебя опят фрейморковская горячка. J2EE -- Это технология.
Фреймворк это -- Хибер, Спринг, Струтс, JSF и т.д.
Сервлеты -- это не фреймворк ни разу, а стандартное средство Java.
Бины -- не фреймворк, а определенного вида класс.
Фреймворк переводится примерно как "набор инструментов". Причем законченный набор. Более того, фреймворки создают чтобы решать широкий круг задач и по монгу задач и только тогда они начинают приносить свою выгоду. А если нужно решать всего круг задач из одной задачи: разработка сайтов и прочих веб-приложений. Т.е. при создании движка, конечно, нет ничего плохого в том, чтобы заюзать тот же Зенд, но учитывая два момента:
1) не стать заложником фреймворка, так что окажется, что ты не можешь выйти за его рамки;
2) ни в коем случае не говорить, что подход -- кодить на фреймворках хорош для задачи разработки сайтов на потоке;
Reply
2) Естественно, что на потоке должна стоять CMS основанная на абстрактной CMF, которая в свою очередь должна быть основанна на каких то общих подходах к разработке, либо фреймворке.
Reply
Отсюда я методом индукции предполагаю, что он нахуй не нужен.
У всех CMF в очень грубых чертах общий подход, а не в грубых -- разный.
Какие ты знаешь общие подходы к разработке и какой особый смысл в том, что их нужно использовать именно для разработки CMF?
Абстрактной CMF? Вот это да! Я знаю, что класс может быть абстрактным, но как может быть абстрактным инструмент?
Reply
Ну, например, тот же многострадальный MVC или твой любимый MVP.
Абстрактность CMF предполагает абстрактность классов для объектов с которыми она работает. Не предирайся к словам.
Reply
SVN -- применим для разработки любого ПО.
У тебя MVC -- это мантра что ли? MVC -- это парадигма. Ее можно увидеть везде, хоть в жопе: модель -- пищеварение, контролер -- кищечник с анусом, вид -- куча говна. Нельзя применить MVC. Даже у сервлета есть MVC -- т.е. неудобная MVC -- Это тоже MVC. Опятб общие слова не относящиеся к теме.
Я не придираюсь, просто не понял, что значит абстрактный Content Management Framework.
Вот те пример:
public class UserClass {
// Уникальный идентификатор в пределах 1 домена:
private static int id = 0;
// Название отображаемое в CMF:
private String cmfViewName = "";
// Название таблицы в БД:
private String dbName = "";
// Поля:
private ArrayList fields;
...
}
А теперь я попытаюсь раскрутить твое нагромождение слов до реального смысла, и ради прикола, предлагаю сравнить с тем, что ты изначально сказал. Я не придираюсь, просто я могу понять только то, что называют своими именами. А что ты, что Легыч, грите одно, а подразумеваете другое, а потом жалуетесь, что к словам придираются.
Итак, назови мне хотя бы пару причин, почему я должен сделать класс UserClass абстрактным?
Reply
Reply
Да, пользовательские классы -- как идеология.
Reply
Leave a comment