Предложения на счет Livestreet-шаблонов
Всем доброго времени суток!
Разрабатывая свой пакет, столкнулся вот с какой проблемой: в Livestreet-шаблонах файл header.tpl содержит все все, что только можно, и даже больше, чем надо. В частности помимо <head></head>, уже за его пределами содержится половина самой страницы, вместе с блоками #header, #content, сайдбаром и т.п. Но ведь это не круто. Ведь наверняка не только я сталкивался с задачей оформления пользовательских страниц, на которых шапка, вместе с пользовательским меню, формой авторизации и т.п. вообще могут отсутствовать. При этом мне с большой долей вероятности может понадобиться весь <head>
Я предлагаю в дальнейшем при разработке Livestreet-шаблонов <!doctype html> вместе с <head></head> вывести в отдельный файл head.tpl.
А head.tpl уже инклюдить в header.tpl
Таким образом кому понадобится шапка полностью, со всем плюшками, сделают {include=«header.tpl»}, а кому только <head>, со всеми его CSS-ами и т.п., сделают {include=«head.tpl»}
И форму авторизации с меню наверняка можно вывести отдельно в auth.tpl
Это наверняка многим облегчит жизнь.
Разрабатывая свой пакет, столкнулся вот с какой проблемой: в Livestreet-шаблонах файл header.tpl содержит все все, что только можно, и даже больше, чем надо. В частности помимо <head></head>, уже за его пределами содержится половина самой страницы, вместе с блоками #header, #content, сайдбаром и т.п. Но ведь это не круто. Ведь наверняка не только я сталкивался с задачей оформления пользовательских страниц, на которых шапка, вместе с пользовательским меню, формой авторизации и т.п. вообще могут отсутствовать. При этом мне с большой долей вероятности может понадобиться весь <head>
Я предлагаю в дальнейшем при разработке Livestreet-шаблонов <!doctype html> вместе с <head></head> вывести в отдельный файл head.tpl.
А head.tpl уже инклюдить в header.tpl
Таким образом кому понадобится шапка полностью, со всем плюшками, сделают {include=«header.tpl»}, а кому только <head>, со всеми его CSS-ами и т.п., сделают {include=«head.tpl»}
И форму авторизации с меню наверняка можно вывести отдельно в auth.tpl
{if $oUserCurrent}
<div class="dropdown-user" id="dropdown-user">
<a href="{$oUserCurrent->getUserWebPath()}"><img src="{$oUserCurrent->getProfileAvatarPath(48)}" alt="avatar" class="avatar" /></a>
<a href="{$oUserCurrent->getUserWebPath()}" class="username">{$oUserCurrent->getLogin()}</a>
<div class="dropdown-user-shadow"></div>
<div class="dropdown-user-trigger" id="dropdown-user-trigger"><i></i></div>
<ul class="dropdown-user-menu" id="dropdown-user-menu" style="display: none">
<li class="item-stat">
<span class="strength" title="{$aLang.user_skill}"><i class="icon-synio-star-green"></i> {$oUserCurrent->getSkill()}</span>
<span class="rating {if $oUserCurrent->getRating() < 0}negative{/if}" title="{$aLang.user_rating}"><i class="icon-synio-rating"></i> {$oUserCurrent->getRating()}</span>
{hook run='userbar_stat_item'}
</li>
{hook run='userbar_item_first'}
<li class="item-messages">
<a href="{router page='talk'}" id="new_messages">
<i class="item-icon"></i>
{$aLang.user_privat_messages}
{if $iUserCurrentCountTalkNew}<div class="new">+{$iUserCurrentCountTalkNew}</div>{/if}
</a>
</li>
<li class="item-favourite"><i class="item-icon"></i><a href="{$oUserCurrent->getUserWebPath()}favourites/topics/">{$aLang.user_menu_profile_favourites}</a></li>
<li class="item-profile"><i class="item-icon"></i><a href="{$oUserCurrent->getUserWebPath()}">{$aLang.footer_menu_user_profile}</a></li>
<li class="item-settings"><i class="item-icon"></i><a href="{router page='settings'}profile/">{$aLang.user_settings}</a></li>
<li class="item-create"><i class="item-icon"></i><a href="{router page='topic'}add/">{$aLang.block_create}</a></li>
{hook run='userbar_item_last'}
<li class="item-signout"><i class="item-icon"></i><a href="{router page='login'}exit/?security_ls_key={$LIVESTREET_SECURITY_KEY}">{$aLang.exit}</a></li>
</ul>
</div>
{else}
<ul class="auth">
{hook run='userbar_item'}
<li><a href="{router page='registration'}" class="js-registration-form-show">{$aLang.registration_submit}</a></li>
<li><a href="{router page='login'}" class="js-login-form-show sign-in">{$aLang.user_login_submit}</a></li>
</ul>
{/if}
{if $iUserCurrentCountTalkNew}<a href="{router page='talk'}" class="new-messages">+{$iUserCurrentCountTalkNew} <i class="icon-synio-new-message"></i></a>{/if}Это наверняка многим облегчит жизнь.
20 комментариев
ну вообще много штуки можно было вынести в отдельные tpl что уж говорить про comment_tree.tpl и comment_list.tpl и comment.tpl, там тоже безобразие твориться.
Ну а вообще то что вы пишите можно и так реализовать, только в рамках одно проекта :) или одного шаблона.
Но ведь лучше бы было, если бы это было уже нативно. Ведь тут даже ничего почти не поменяется, как подгружали все header.tpl, так и будут, то есть даже при смене шаблона на старых проектах ничего не поломается.
Многие поспорят, что это шаблоны по умолчанию, что мол свой шаблон лепи и будет тебе счастье.
На WordPress в день появляется 100 000 новых сайтов, и 99,9% из них, наверняка с нативными шаблонами. Потому считаю, что нативными шаблонами пренебрегать не стоит.
Я считаю, что плюс к его мощному API все-таки должны быть готовые решения.
Livestreet для меня в связке с MODX — не только готовое решение, но и стандарт в своем узком профиле. MODX позволит сделать все тоже самое, но тебе придется полностью продумывать все сущности и продумывать связь между ними, в том числе и стандарты оформления, чтобы легко было использовать на разных страницах.
А стандарты — залог того, что верстальщик сверстает тебе такой шаблон, который гладко ляжет на уже имеющийся сайт. При этом разработчик новый компонент напишет так, чтобы он не конфликтовал с имеющейся системой.
А с Джумлой пару раз сталкивался, и мне там все не нравится. Особенно на нее жалуются, что стоит обновить версию, и с большой долей вероятности сайт разваливается.
Но в любом случае, ИМХО — каждый выбирает для себя то, что ему нравится, и многое зависит от того, как он использует свой инструментарий. Тот, кто работает с Джумлой, если он ее очень хорошо знает, легко может напрограммировать более качественный сайт, чем средненький программист на MODX.
Но я могу сказать, что MODX выставляет очень серьезные требования к разработчикам, потому если программист слабоват, и плохо разбирается в MODX Revolution, то скорее всего можно будет долго плеваться от того, что он натворит с ним.
Я вот Bitrix в принципе неплохо знаю, и в нем единтсвенное что мне нравится — это как реализовано управление модулями через frontEnd, но все остальное в нем — просто жесть. Принципиально не принимаю заказов по Bitrix, так как считаю, что он держится только за счет отличных маркетологов 1С и популярности самой компании.
А если серьезно — что на выходе дает движок?