Xpoint
   [напомнить пароль]

компонентный подход - ваше мнение

Метки: [без меток]
2009-06-26 13:17:30 [обр] triumvurat[досье]

http://dklab.ru/chicken/nablas/16.html, 4 параграф (если кто не знает, что это такое)

Интересуют мнения уважаемых участников. Опыт, идеи, мнения. Кто реализовывал полноценные приложения на таком подходе? Успешно или нет? В чем подводные камни?

спустя 3 часа 27 минут [обр] Thirteensmay(17/157)[досье]
Ну это просто один из вариантов. В случае необходимости разделения на программистов и верстальщиков может быть полезен. Фактически это простейший шаблонизатор, и как любому подходу с шаблонизатором ему присущи улучшение структуры, но и дополнительные затраты на поддержку. При определенных условиях может быть целесообразен для реально крупных проектов. Однако надо учитывать глобальную проблему принципа "разделяй и властвуй" - упрощение реальности и необходимость гибкого взаимодействия. Как бы изощренно вы не продумывали функциональность компонентов и интерфейс, достичь гибкости аналогичной непосредственному совоокуплению не удастся, если вы конечно не собираетесь повторить функциональность клея типа Perl, PHP или др. языка общего назначения, что глупо. Делать бледненькое подобие простенького конструктора для бедных мальчиков не вижу смысла, разве что на поиграться. Против компонентного подхода вообще, и модульности, естественно ничего не имею, рассматриваем именно то что предлагается по ссылке выше. В дополнение к минусам шаблонизатора надо учитывать что при таком подходе он получается неполноценным, т.е. имеем дополнительные минусы связанные с тем что язык верстальщик все же должен знать, хотя бы основы. Вообще вместо верстальщика лучше иметь соответствующего программиста. Единственные реальные полтора плюса вышеозначенного подхода заключаются в том что индивидов типа "верстальщик" мы все же можем задействовать, и то что улучшается структура, она улучшается "принудительно", хотя вообще никто нам не запрещает улучшать ее при использовании практически любого другого подхода. Вообще подход имеет право на жизнь и может с успехом применяться. Но лично я сейчас вообще отошел от генерации страниц на сервере, с него лишь однажды вначале грузится "каркас" приложения, дальше весь интерфейс пользователя и интерактивность обеспечиваются исключительно на клиенте с помощью JavaScript, сервер обрабатывает запросы связанные лишь с непосредственно данными (AJAX), т.е. пресловутый Web 2.0 ;) Конечно на нижнем уровне со всем связанным с этим хозяйством я не парюсь, использую библиотеку http://extjs.com/deploy/dev/examples/samples.html, подход получается очень похож на обычное локальное приложение, проблем типа рассматриваемых вами выше естественно нет, весьма функциональный интерфейс за счет богатых виджетов и т.п. прелести, есть конечно свои косячки, но мне кажется перспектива за таким подходом.
спустя 45 минут [обр] Алексей Севрюков(162/1280)[досье]

triumvurat[досье] сейчас 99% сайтов с которыми мне приходится сталкиваться использует подобные механизмы (имеется ввиду 4 и 5 способы). Сам я использую 5й способ.
Подводные камни могут быть только с 5ым вариантом и заключаются они в языке шаблонов, а именно в том, что невозможно предусмотреть сразу все варианты использования этого языка и его постоянно приходится дописывать и дорабатывать под новые растущие требования (прогресс ведь не стоит на месте).

А так, 5ый вариант - это удобно, быстро и относительно просто. Естественно, простота напрямую зависит от реализации языка шаблонов. Под простым я понимаю такой язык, понять смысл которого возможно без чтения документации по нему, имея начальные навыки программирования.

спустя 16 часов [обр] Филипп Ткачев(20/112)[досье]
Конечно у меня опыта меньше, чем у Thirteensmay[досье] и Алексей Севрюков[досье], но я тоже придерживаюсь 5 варианта. Разделение бизнес-логики и логики-представления весьма эффективно, особенно для развивающихся проектов.
Программист занимается своим делом, а верстальщик своим. Никто друг другу не мешает. При обновлении сайта, изменение бизнес-логики никак не отображается на внешнем виде сайта. Удобно такое и при подготовке редизайна сайта, т.к. переключение происходит мгновенно.
Еще один плюс в том, что работа над проектом ускоряется, т.к. программист и дизайнер(верстальщик) работают параллельно. Это экономия времени.
При использовании первых 3х вариантов связь между кодером и верстальщиком очень сильная. Изменения в макете тянут за собой изменения в коде. Из-за этого появляется куча проблем при групповой работе.
спустя 4 часа 34 минуты [обр] Thirteensmay(17/157)[досье]
Разделение бизнес-логики и логики-представления не является исключительной особенностью 4 и 5 вариантов, это разделение может быть применено при любом подходе. По поводу ускорения и экономии времени вопрос спорный, часто ансамбли достаточно уникальны и работа по их внутреннему разделению становится работой в пустоту, но сначала это не очевидно. К тому же как заметил Алексей Севрюков[досье] невозможно предусмотреть сразу все варианты использования языка шаблонов и его постоянно приходится дописывать и дорабатывать, т.е. по факту приближать к возможностям обычного языка программирования. Ну и каков тогда смысл, и где экономия ? почему бы сразу не взять нормальный язык ? Потому что у нас есть глупый верстальщик, нам надо разработать свой (простой как нам кажется) язык и обучить его ему. IMHO глупо и уж точно не экономно. Я уже говорил что лучше иметь 2 программиста, чем одного и верстальщика. Среди этих двух программистов один может выполнять роль верстальщика, а если нет то все равно они могут работать параллельно. Проблемы групповой разработки в первую очередь решаются распределением задач и модульностью а не специализацией. Кроме всего прочего как бы мы этого не хотели, но представление зависит об бизнес логики и никуда тут не денешся, опять таки глупо пытаться размазать эту зависимость за счет введения дополнительного среднего звена, потому что тогда появляется зависимость еще и от этого среднего звена. При разработке обычных локальных приложений верстальщики не используются, в используемом мной подходе (см. первый пост) Web 2.0 тоже, что получается что весь сыр-бор с шаблонизаторами из-за них чтоли ? Ну и накой тогда ? Не может балерина в шахте уголь добывать, не надо для нее изобретать специальный отбойный молоток. Это все в качестве критики 5 подхода, а то вы его тут уж больно приласкивать начали ;), про 4 я сразу сказал - всего лишь один из вариантов, без особых плюсов и минусов.
спустя 4 часа 30 минут [обр] Давид Мзареулян(536/1003)[досье]

«Ведущие шаблоны» с custom-тегами и прочим блэкджеком — это, например, Джанго.

Преимущество отдельного синтаксиса для шаблонов состоит в том, что мы, фактически, получаем отдельный язык, заточенный именно под вывод данных в HTML и больше ни подо что. Это плюс, потому что шаблонный движок, например, может сам заботиться об экранировании HTML-спецсимволов, знать, что такое списки и элементы форм, уметь подсталять множественные формы слов и прочая и прочая. Это удобно - и не для глупого верстальщика, а для умного программиста, у которого появляется специализированный язык/движок, экономящий время выполнения типовой задачи — вставки данных в HTML-вывод.

Что касается невозможности предусмотреть сразу все варианты, то это, конечно, верно для абстрактно-сферических задач, но в реальности 99.9% всех потребностей закрываются двумя-тремя управляющими структурами и десятком стандартных фильтров. Для 0.1% потребностей можно написать custom-теги.

спустя 16 часов [обр] Алексей Севрюков(162/1280)[досье]

Давид Мзареулян[досье]

Что касается невозможности предусмотреть сразу все варианты, то это, конечно, верно для абстрактно-сферических задач, но в реальности 99.9% всех потребностей закрываются двумя-тремя управляющими структурами и десятком стандартных фильтров. Для 0.1% потребностей можно написать custom-теги.

Собственно так я и поступил. Есть скелет, модули и custom-теги. Правда я пошел немного по другому пути - у меня все шаблоны компилируются в Perl-код и кэшируются. Так быстрее, чем парсить его каждый раз.

спустя 22 часа [обр] Thirteensmay(17/157)[досье]
Все тоже самое делается и обычным языком, отдельный "заточенный" это конечно плюс, как минимум с точки зрения красоты, но и удобства наверное слегка тоже, но оправдывает ли он себя ? время затрачиваемое на его проработку, зависимость от шаблонизатора, производительность ?
спустя 2 часа 39 минут [обр] Алексей Севрюков(162/1280)[досье]

Thirteensmay[досье] в моем случае оправдывает почти на все 100. Очень удобно и быстро. Производительность в принципе тоже неплохая, но, естественно, лишняя "обертка" тоже ест ресурсы.
Супер производительность она в нашем деле не особенно требуется, а если и требуется то и скриптовые языки не очень подходят. Шаблонизатор — компромисс между производительностью и скоростью разработки.
Да и язык я совершенно не дублирую, шаблонизатор у меня очень ограниченный и простой, заточенный исключительно на быстрый вывод данных.

P.S. Пример из жизни — мне часто приходится работать с чужим кодом, и шаблонизаторов я видел несколько десятков самых различных. Так вот — поправить что-то в шаблоне намного проще, нежели ковырять абсолютно не читаемый код и делать аналогичные правки в нем. Я имею ввиду шаблонизаторы, которые вообще вижу впервые.

спустя 1 час 4 минуты [обр] Thirteensmay(17/157)[досье]
Ну что'ж, раз красное значит красное. Тем не менее я не считаю что использование 4 существенно хуже 5, если писать нормальный читаемый код, и нормально структурировать, как минимум скажем разделять по слоям: бизнес логика, подготовка и работа с данными, контролы (виджеты), лэйауты, панели и пр., а наверху просто шаблон, то по большому счету разницы особой в удобстве не будет, и от шаблонизатора как от лишней сущности и зависимости можно отказаться. А можно и не отказываться, плюсы то у него как и у любого другого решения есть.
спустя 3 часа 26 минут [обр] Алексей Севрюков(162/1280)[досье]
Thirteensmay[досье] А я и не говорил что 4ый вариант плох, особенно если делать грамотно. Но 5ый вариант все равно проще для восприятия. ИМХО.
Powered by POEM™ Engine Copyright © 2002-2005