1. Чем мне нравится админка Вульфа. Как-то раз, Шура (Вульф) показал мне свой сайт, без единой строки кода. Хм. Сайт был поднят на одной админке, используя лишь формализованное описание его объектов. Мне понравилось. Понравилась сама идея. Не писать код. Коля, не писать код - это здорово. Мы на работе с ребятами пишем код только для того, что не писать его совсем. Понимаешь? Ссылки на разные технологии с примерами кода - не рулят. Ядро - это пространство формализованных объектов. Ядро - это правила их взаимодейстия. Не вижу ничего плохого в том, чтобы наработать свои инструменты, удобные для себя инструменты для того, чтобы купить потом пивка и поднять сайт + научить клиентов НЕ ПИСАТЬ на Spring, а сделать решение на готовых шаблонах. Собственно...ТЫК туда - новости, ТЫК туда - каталог товаров. Все нормально. 2. Шура, мое мнение, одобряю наработку удобных инструментов. Если они помогу тебе развиться и (или) съэкономить время на рутине. Почему бы и нет?! 3. Итак, 1 мая, берем ноуты, идем в кафе, берем темный эль и делимся)))
^_^ вообще то я на ней года 1,5 работал и прекрастно знаю как "здорово" не писать код.
Есть определенный круг задач, которые решает данный подход. Но это отдельная тема.
А здесь речь даже не об этом. Spring приводился в пример как источник мана по передачи запроса от пользователя к серверу на другой ресурс. Банальная задача, которая к ядру не имеет никакого отношения.
Коля, я работал на админке Вульфа -- не писать код -- это здорово. Это правильно. То, что админка была не совершенна -- это другой вопрос, но она умела делать достаточно много, и сайт на ней развернуть можно было быстро -- основное время уходило на javascript и создание, меппинг и вывод сложных объектов. Вот что нужно оптимизировать. А подход там был исключительно правильный
( ... )
Мне не впадлу разбираться с фреймворками, я просто говорю прямо: они не применимы для той 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 тоже своебразный фреймворк, и в частности сервлеты и бинсы ;)
Саш и самая главная мысль - фреймворки тебе нахрен не нужны, так как ты их полюбому используешь (и зависишь от них), а во вторых, нахуяказебаян )
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
( ... )
2. Шура, мое мнение, одобряю наработку удобных инструментов. Если они помогу тебе развиться и (или) съэкономить время на рутине. Почему бы и нет?!
3. Итак, 1 мая, берем ноуты, идем в кафе, берем темный эль и делимся)))
Reply
Есть определенный круг задач, которые решает данный подход. Но это отдельная тема.
А здесь речь даже не об этом. Spring приводился в пример как источник мана по передачи запроса от пользователя к серверу на другой ресурс. Банальная задача, которая к ядру не имеет никакого отношения.
Reply
Reply
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
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 ( ... )
Reply
Leave a comment