Доработка шаблона виджета
12.03.2010Можно сказать, что релиз стабильной версии почти состоялся. После тестов и валидации нашлись недостатки, которые с ходу так просто не решаются и требуется некое переосмысление.
Во первых, оказалось, что аяксовые виджеты без элементов li, то есть только теги ul, по мнению html валидатора не являются валидным кодом. Как же это исправить? Ну да, конечно, не вставлять теги ul. А как это сделать? сейчас шаблон виджета состоит из двух частей - обертки над элементами и шаблон элемента. Сами эти два шаблона не обязаны быть тегами ul и li. Например шаблон может быть параграфом с переводами строк или небольшой таблицей или ячейкой таблицы. Да все что угодно - блоголёт не ограничивает верстальщика в своих предпочтениях. Модель из двух шаблонов отлично работает при наличии элементов - никаких вопросов. Проблема возникает при отсутствии элементов, а именно при аяксовом режиме виджета, когда элементы (контент виджета) подгружается по клику. Также частично проблема возникает при отсутствии элементов и показе виджета. Пример такого - виджет друзей, при отсутствии друзей. Необходимо либо не показывать виджет совсем, либо показывать, но правильно. Как же быть? Вводить новую сущность? не хочется, так как чем больше сущностей, тем однозначно хуже. Пытаться анализировать html виджета? Еще более тупиковый путь, так как движок не является лингвистическим анализатором и не обязан понимать мысли верстальщика, если они отличаются от стандартных.
С другой стороны, новая сущность введена без деклараций, а именно - аяксовая ссылка в названии виджета. Эта сущность никак не отражается в шаблоне. Так что думаю, что можно в виджете выделить новую сущность - заголовок виджета. Эта сущность будет понятна, поскольку в неформализованном виде уже присутствует в шаблоне виджета. С другой стороны нет технической необходимости отделять название от всего шаблона, так по техническим причинам требуется отделить контейнер для элементов. Следовательно, скрепя сердце, придется экстрагировать секцию и по аналогии с секцией item назвать ее items. таким образом получится вот такой абстрактный шаблон виджета
<!--widget-->
<div class="widget">
<h2>%s</h2>
<!--items-->
<ul>
<!--item-->$title<!--/item-->
</ul>
<!--/items-->
</div>
<!--/widget-->
И соответствующим образом, обновить для поддержки этой новой сущности, код движка. Далее есть проблема с виджетом мета. Сейчас я сделал виджет мета в виде текста ссылок, генерирующихся во время инсталляции движка на основе шаблона, то есть темы по умолчанию. При смене темы эти ссылки не адаптируются так, как это происходит со всеми остальными виджетами, а остается старым. Почему я сделал виджет мета в виде текста? Потому, что мне неоднократно жаловались в старой версии на невозможность удаления некоторых ссылок, например фоаф и профиль. Ну вот и сделал редактируемым текстом - не нравится удаляй, добавляй. И оказывается, что такой вариант редактируемого виджета не способен адаптироваться к новой теме, в основном это касается ссылок на рссы, а в новой версии еще добавился рсс мултимедийных файлов (надо будет не забыть еще добавить рсс по типам файлов - картинки, звук, видео).
Как же быть? Отказаться от редактируемого текста в пользу чекбоксов - а ля вариант стандартных линков? Тогда для линков придется отдельно хранить инфу (участвует ли линк в виджете) и хранить все это. Также генерировать список ссылок на основе текущего шаблона. Вроде как мелочь и в совокупности недолжно сказаться на производительности, но все же скажется тысячными долями секунды. А я надо признаться, крайне скуп на ресурсы - движок сделан таким образом, что потребляет минимум памяти. деваться некуда - придется переделать виджет мета.
← Ранее Урлкодированные адреса и тестирование
Позже Icon set в виде плагина →
Комментарии (11) на запись “Доработка шаблона виджета”
Оставить комментарий
Выглядит достойно.
А можете сделать древовидные комментарии как на хабре или в лайв джоурнал. Естественно с почтовым оповещением ответа на коммент. Это мега фича, но что то никто ее не реализовывает :(((
Ой не скажи не скажи. Когда идет бурное обсуждение (под сотни комментариев) то для того чтобы дать что то понять оппоненту приходится делать цитирование. Иначе получается информационная каша. А на нормальном блоге в комментах 50% полезной инфы от статьи обычно раскрывается. А где цитирование там и оверквотинг и прочие гадости.
Опять же древовидные комменты побуждают к комментированию. Т.к. люди любят отвечать на комменты. Но без подписки ходить проверять лень.
Подписываться же вообще на все комментарии к записи тоже плохо -- получаешь себе на почту адский поток спама чужих комментов, особенно когда обсуждение бурное (а у меня бывает в блоге и по под 900 комментов к записи.
Вот и выходит, что единственным адекватным решением является древовидка с подпиской на ответ лично тебе, а не подпиской на все комменты вообще.
"Лично я эту фичу никогда реализоывать не буду - пусть это делают те, кому это интересно и нужно, свое отношение к древовидным комментам я ввысказал: лично мне они крайне неудобно, онилишь загромждают лишним мусором"
В общем, понятно. Проект сделан для себя.
Удачного продвижения
Ладно, не кипятись :) Я же не со зла. И все прекрасно понимаю. Сам кручусь в разработке (правда радиоэлектронной)
А вопрос тут скорей маркетинговый.
Я как потенциальный клиент поинтересовался "можно?", а мне "нет и не буду делать" Ну на нет и суда нет :) Развернулся и ушел.
А правильней было бы "теоретически возможно, но потребует времени, а время-деньги" и дальше был бы сплошной конструктив к взаимовыгодным результатам :) Лояльней надо быть к потенциальным заказчикам =)
З.Ы.
интересно, а как этот движок себя поведет при загрузке в 50-60к хитов в сутки.
В самом первом моем ответе я однозначно написал, что требуеттся для реализации. Этот вопрос (про древовидные) уже обсуждался, но увы пока не запущена тикет система, эту инфу сложно найти на сайте.
Однажды мой движок один перец решил протестировать на нагрузку - 100 конкурентных запросов в секунду, ну мой вдс с 256Мб и полусотней других сайтов не выдержал, так что тответа у меня про нагрузку нет