Если не нравиться сама "концепция" это одно, а если не нравится цвета и картинка с маяком - то тут можно посоветовать такой выход.
По коду видно что верстка блочная, соотвественно цветовую гамму можно переключать посредством css.
Не знаю позволяет ли данная система но картинку можно запихнуть в какую либо переменную или поле в систему - и пускай меняют ее сколько хотят.
ИМХО: после таких заявлений заказчика "Он же сказал что заплатит 7000 при условии что я еще натяну чужой дизайн на сайт" отправил бы его в эротический пеший тур.
И попробуй в следующий раз идти по совету пользователя "ktotoff"
Glook, maddog
Ребята - я тоже долго думаю над названиями и очень долго смеюсь (хотя если надо переделывать то плачу), когда вижу вот такой код http://www.stagi.ru/
Смотри у тебя есть 3 колоночная верстка.
Заказчик хочет чтобы справа были новости слева меню по середине контент.
Ты пихаешь все это добро в табличку, запрогорамливаешь шаблон все работает и все шикарно :)
Но заказчика осенеяет - меню слева - это не то, давайте сделаем его справа и а новости как раз слева.
И ты лезещь в уже запрограмленный шаблон - начинаешь что там перетаскивать, трогаешь програмные функции и т.д и т.п
А если ты сделал изначально на div, ты открываешь файл стилей - и правишь его как хочешь, меняешь расположение блоков и т.д -> не трогая свой шаблон где у тебя все запрограмированно :)
Это так на в скиду - есть много и других преимуществ :)
Так давайте расставим точки над "i" и отойдем от UMI.CMS
я создаю шаблон сайта.
Я хочу чтобы именно в правой части у меня выводилось меню - это требование дизайна.
как система поймет что мне выводить его надо именно там?
Я должен в шаблоне указать что именно в этом месте у меня будет выводиться меню сайта.
В вашем случае это вызов идет через конструкцию
Результатом данного запроса будет выданное с учетом прав пользователя xml дерево сайта.
>>при помощи него шаблон указывает приложению, что оно должно делать.
не указывает - а просит систему дать меню если оно есть и пользователя есть на это право :)
А если мне по дизайну не нужно меню?
Зачем мне автоматический лишний запрос в базу?
Если меню нужно по дизайну - оно запрашивается, если нет - то нет:)
С помощью таких запросов я запрашиваю только те данные которые мне нужны, а не то что мне предлагает система.
Если идти по Вашему варианту, где система решает по какому-то там "default" какие данные мне нужны, то большая вероятность их избыточности - мне придется отсекать лишенее.
>>Ну блин, не должен шаблон решать, показывать ли меню на странице. Шаблон должен содержать средства для отображения меню, если приложение решило, что нужно его отобразить.
Может быть я что не понимаю, или мы говорим о разных "шаблонах"?
Шаблон ничего не должен решать :)
Я ему говорю выведи мне здесь меню - и он выводит :)
А система как раз уже решает какое меню ему вывести, как для зарегистрированного пользователя или как для гостя. И вот этот результат который мне отдает система и проходит через XSLT.
<xsl:variable name="имя_переменой" select="какое-то XML дерево" />
<xsl:template match="/">
<xsl:apply-templates select="$имя_переменой" /> <- и делай там что хочешь
</xsl:template>
<xsl:template match="что-то">
<xsl:apply-templates select="$имя_переменой" /> <- и опять же делай там что хочешь
</xsl:template>
</xsl:stylesheet>
я могу не использовать рекурсию, а использовть xsl:for-each да еще и вложить и вдруг друга, а также паруз раз сделать match на корень документа для вытягивания каки-либо праметров - И У МЕНЯ ВСЕ ТОЖЕ БУДЕТ ТОРМОЗИТЬ.
Но это показатель того, что круворукий разработчик, а не XSLT плохой. :)
Примеры чего вы хотите тут увидеть сравнительные тесты обработки вывода как шаблонизатором так и XSLT? Это приведет к тому, что будут рассматривать уже шаблонизаторы и говорить, что у вас там шаболнизатор плохой а вот у нас он делает это быстрей. И в итоге отдалимся от тему статьи.
Как уже упоминалось что на западе XML/XSLT становиться уже де-фактом разработки CMS - это по вашему голословные утверждения?
То что все больше и больше крупных российских сервисов созданы на этой технологии - тоже голословные утверждения?
Для меня как для разработчика голословным утверждением является, то что XSLT тормозит и никуда не годнен.
В том то и дело, что производительность XSLT намного выше (это факт), но только при правильной логике.
Поэтому и "повторение избитых фактов о разделении логики", что бы люди понимали что дело не в XLST - а в не правильном его использовании.
На мой взгляд забыли упомянуть, что XSLT давольно расширяемый язык, и тем кого не устраивают стандартные возможности - могут подключить дополнительные расширения для языка, написанные сторонними разработчиками (яркий пример расширения проекта http://exslt.org/).
В свое время были в дефиците верстальщики на CSS. Но когда требования верстка на div является обязательным - люди начинают учится данной технологии - пускай даже и принудительно.
Лидеры рынка должны задавать правильный вектор развития технологий, что бы молодые специалисты понимали куда стремится - а не делать на том что проще изучить.
вот это чистый пример "дивомании"
По коду видно что верстка блочная, соотвественно цветовую гамму можно переключать посредством css.
Не знаю позволяет ли данная система но картинку можно запихнуть в какую либо переменную или поле в систему - и пускай меняют ее сколько хотят.
ИМХО: после таких заявлений заказчика "Он же сказал что заплатит 7000 при условии что я еще натяну чужой дизайн на сайт" отправил бы его в эротический пеший тур.
И попробуй в следующий раз идти по совету пользователя "ktotoff"
15 000 кончено очень мало за сайт, но заплатив их человек и получает:
3 минутный обзор сайта:
1)Ошибки JS сыпящиеся на главной странице
2) Кнопку "Search" - на русскоязычном сайте.
(http://www.ecoinstroy.ru/appartments/sal…)
3) $tvTprice->caption}
(http://www.ecoinstroy.ru/real_estate/out…)
4) В вашей форме обнаружены следующие ошибки:
Необходимо заполнить следующие поля: Your Email Address, Comments
5) Поиск: There were no search results. Please try using more general terms to get more results.
И просто интересно для себя.
Как я понимаю сайт сделан на какой-то CMS? Хотелось бы узнать какой?
Ребята - я тоже долго думаю над названиями и очень долго смеюсь (хотя если надо переделывать то плачу), когда вижу вот такой код http://www.stagi.ru/
Заказчик хочет чтобы справа были новости слева меню по середине контент.
Ты пихаешь все это добро в табличку, запрогорамливаешь шаблон все работает и все шикарно :)
Но заказчика осенеяет - меню слева - это не то, давайте сделаем его справа и а новости как раз слева.
И ты лезещь в уже запрограмленный шаблон - начинаешь что там перетаскивать, трогаешь програмные функции и т.д и т.п
А если ты сделал изначально на div, ты открываешь файл стилей - и правишь его как хочешь, меняешь расположение блоков и т.д -> не трогая свой шаблон где у тебя все запрограмированно :)
Это так на в скиду - есть много и других преимуществ :)
я создаю шаблон сайта.
Я хочу чтобы именно в правой части у меня выводилось меню - это требование дизайна.
как система поймет что мне выводить его надо именно там?
Я должен в шаблоне указать что именно в этом месте у меня будет выводиться меню сайта.
В вашем случае это вызов идет через конструкцию
<xsl:apply-templates select="document('udata://content/menu')//item" />
Результатом данного запроса будет выданное с учетом прав пользователя xml дерево сайта.
>>при помощи него шаблон указывает приложению, что оно должно делать.
не указывает - а просит систему дать меню если оно есть и пользователя есть на это право :)
А если мне по дизайну не нужно меню?
Зачем мне автоматический лишний запрос в базу?
Если меню нужно по дизайну - оно запрашивается, если нет - то нет:)
С помощью таких запросов я запрашиваю только те данные которые мне нужны, а не то что мне предлагает система.
Если идти по Вашему варианту, где система решает по какому-то там "default" какие данные мне нужны, то большая вероятность их избыточности - мне придется отсекать лишенее.
Может быть я что не понимаю, или мы говорим о разных "шаблонах"?
Шаблон ничего не должен решать :)
Я ему говорю выведи мне здесь меню - и он выводит :)
А система как раз уже решает какое меню ему вывести, как для зарегистрированного пользователя или как для гостя. И вот этот результат который мне отдает система и проходит через XSLT.
делать трансформацию на клиенте - это преступление :)
А если у меня машинка слабенькая то что?
А если у меня Опера 8.0 то что?
А если у меня текстовый браузер то что?
Ничего личного :)
<xsl:stylesheet version="1.0">
<xsl:variable name="имя_переменой" select="какое-то XML дерево" />
<xsl:template match="/">
<xsl:apply-templates select="$имя_переменой" /> <- и делай там что хочешь
</xsl:template>
<xsl:template match="что-то">
<xsl:apply-templates select="$имя_переменой" /> <- и опять же делай там что хочешь
</xsl:template>
</xsl:stylesheet>
я могу не использовать рекурсию, а использовть xsl:for-each да еще и вложить и вдруг друга, а также паруз раз сделать match на корень документа для вытягивания каки-либо праметров - И У МЕНЯ ВСЕ ТОЖЕ БУДЕТ ТОРМОЗИТЬ.
Но это показатель того, что круворукий разработчик, а не XSLT плохой. :)
Ничего личного :)
Как прасер XML - XSLT самый производительный :)
Как уже упоминалось что на западе XML/XSLT становиться уже де-фактом разработки CMS - это по вашему голословные утверждения?
То что все больше и больше крупных российских сервисов созданы на этой технологии - тоже голословные утверждения?
Для меня как для разработчика голословным утверждением является, то что XSLT тормозит и никуда не годнен.
Поэтому и "повторение избитых фактов о разделении логики", что бы люди понимали что дело не в XLST - а в не правильном его использовании.
Лидеры рынка должны задавать правильный вектор развития технологий, что бы молодые специалисты понимали куда стремится - а не делать на том что проще изучить.