Зря вы так, фреймворк отличный, я, кстати и поддержку XSLT (серверную, конечно) к нему прикрутил через переопределение класса представления.
В общем, его надо уметь готовить :-)
Не могли бы вы пояснить почему?
Условия это прерогатива только бизнес-слоя?
А если мне надо присвоить класс для элемента, в зависимости от входящих данных?
А если мне нужно поменять название класса, мне нужно будет лезть в бизнес-логику где и менять название?
Хотелось бы оправдаться за фразу «иногда для одного HTML тега столько наворотишь».
Я имел ввиду ситуации, когда, например, тег или атрибуты зависят от параметров, тогда приходится применять xsl:if или xsl:choose, что увеличивает размер кода. В итоге для одного элемента можно получить десяток строчек кода.
В других шаблонизаторах будет также, но в XSLT каждое такое условие или решение — это тег, что увеличивает размер кода и визуально это выглядит довольно громоздко.
У нас была программная обработка и формирование главных шаблонов на уровне серверного языка (PHP), поэтому сами такое не писали. «Рядовые» программисты писали XSL (и частично XML) для отдельных модулей/действий.
А вообще, связка XML/XSLT и так довольно муторна — иногда для одного HTML тега столько наворотишь.
Но гибкая и требует грамотного подхода, абы как не сделаешь.
За что до сих пор и люблю. :-)
Насчёт непрактичного синтаксиса спорить не буду, как говорится, suum cuique, а вот поддержки браузеров нет, это правда.
В своё время выбрали серверную обработку XSLT и сопутствующие вкусности, добавили кеширование и вуаля…
Опять же, каждому своё.
А мне показалось, что писал менеджер :-)
Виноват-то оказался программист, которые обещал выполнить задачу за 20 минут, а выполнил за 5 часов.
Хотя вина обоюдная.
Если проблема ставиться так, то да, аналогия понятна. Но тогда возникают сомнения в компетентности работника или в его коммуникативных навыках.
Как говориться «Назвался груздем? Полезай в кузов!».
В таком аспекте виноват работник, но зачастую бывает так, что вина лежит и на менеджере и на работнике.
Менеджера должен насторожить фраза про 20 минут, а если он ещё знает, что система незнакомая для этого работника, то точно должен переспросить.
Слава богу, когда я начинал, мои руководители говорили: «20 минут? Значит час-два.» То есть они понимали мой энтузиазм, да и были тертыми калачами, которые не раз обожглись на таких оценках.
Да, проблема сложная и острая. Честно говоря, оценивать задачи в 20 минут по незнакомой системе я перестал уже давно. Другое дело, если система знакомая, и ты знаешь, что и как нужно сделать, но даже тогда нужно в оценку вкладывать риски. Поэтому аналогия с квантовой механикой не вполне удачна — объяснить, чем и как вы занимаетесь можно, а вот оценить задачу сложнее.
Скажите, что выполните задачу за два часа. Выполните за час — вы молодец. Как только понимаете, что задача займет больше времени, сразу же докладывайте менеджеру, и дальше решайте, что делать.
Стоит понимать, что ни один продукт не выходи в срок с запланированным набором свойств. При реализации возникают моменты, которые изменяют планы разработчиков, и один набор функций может исчезнуть или уступить место другому.
Вообще говоря, нет. Но можно поправить пару ключиков в реестре и Home превращается… превращается… в элегантный Proffesional. Сам так делал, когда нужно было заставить работать Home в домене.
В общем, его надо уметь готовить :-)
Условия это прерогатива только бизнес-слоя?
А если мне надо присвоить класс для элемента, в зависимости от входящих данных?
А если мне нужно поменять название класса, мне нужно будет лезть в бизнес-логику где и менять название?
Я имел ввиду ситуации, когда, например, тег или атрибуты зависят от параметров, тогда приходится применять xsl:if или xsl:choose, что увеличивает размер кода. В итоге для одного элемента можно получить десяток строчек кода.
В других шаблонизаторах будет также, но в XSLT каждое такое условие или решение — это тег, что увеличивает размер кода и визуально это выглядит довольно громоздко.
Я думаю, для некоторых это отталкивающий фактор.
А вообще, связка XML/XSLT и так довольно муторна — иногда для одного HTML тега столько наворотишь.
Но гибкая и требует грамотного подхода, абы как не сделаешь.
За что до сих пор и люблю. :-)
В своё время выбрали серверную обработку XSLT и сопутствующие вкусности, добавили кеширование и вуаля…
Опять же, каждому своё.
Просто и как Ленин завещал :-)
Виноват-то оказался программист, которые обещал выполнить задачу за 20 минут, а выполнил за 5 часов.
Хотя вина обоюдная.
Как говориться «Назвался груздем? Полезай в кузов!».
В таком аспекте виноват работник, но зачастую бывает так, что вина лежит и на менеджере и на работнике.
Менеджера должен насторожить фраза про 20 минут, а если он ещё знает, что система незнакомая для этого работника, то точно должен переспросить.
Слава богу, когда я начинал, мои руководители говорили: «20 минут? Значит час-два.» То есть они понимали мой энтузиазм, да и были тертыми калачами, которые не раз обожглись на таких оценках.
Скажите, что выполните задачу за два часа. Выполните за час — вы молодец. Как только понимаете, что задача займет больше времени, сразу же докладывайте менеджеру, и дальше решайте, что делать.
Стоит понимать, что ни один продукт не выходи в срок с запланированным набором свойств. При реализации возникают моменты, которые изменяют планы разработчиков, и один набор функций может исчезнуть или уступить место другому.
ппципотека. Но всё равно чуточку обидно.Обидно :-\