Как задавался шаблон? Легко. Да, выводил сервлет, у которого беда с 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 абстрактным?
А внутренний движок на что? Я сделал так:
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