Yahoo! User Interface блог (YUIBlog)

2 Комментариев »

RSS лента комментариев к этой записи. TrackBack URI

1. Поэтому, когда в 3,4 релиз выходит?

   Комментарий ПКС - 26 июля 2011 #

2. Я уверен, что было много активности в канале # юй после этой сессии, но, к сожалению, что активная фаза канал IRC, как правило, от моих регулярных часов, так что я скучаю по большей части хорошие вещи.

   Так вот мой офф-лайн, на (мой) часов комментарии о календаре:

   Шаблоны статические члены класса, который предотвращает наличие двух календарей с разными шаблонами на той же странице. Название CONTENT_TEMPLATE также плохой выбор, так как виджет собственность тем же именем и это сбивает с толку знать, какие из них вы говорите. Если этот шаблон меняется на свойства экземпляра, его имя будет конфликтовать с собственностью Widget с вполне предсказуемо (фатальный) результат.

   Наличие двух отдельно и отключены шаблонов для заголовков и календаря позволяет себе иметь их соответствие друг с другом в нескольких календарей месяц. Если вы собираетесь отобразить весь год, вы хотите каждый месяц четко определены, а не просто знать диапазон месяцев показали и есть количество пользователей которой есть что. Другими словами, к тому же возможно иметь всеобъемлющий заголовок для всего этого, каждый «панели» должен иметь свой собственный заголовок, и месяц / год должны идти туда. Это, конечно, не небольшие изменения в базовую структуру разметки, извините.

   Шаблонов вещи могут быть улучшены с помощью часто забывают, третий аргумент Y.substitute, замена функций. Это позволит подключить вызова методов, в основной календарь, чтобы заполнить в любом заполнителей разработчиков было подумать, сколько старых YUI2 Paginator делает. Плагины хотел сделать шаблон заполнения может зарегистрироваться на инициализацию с {метка} они предназначены для обработки и способ сделать замены. Замена функции не получит "предложил" замены, таким образом они могли бы принять предлагаемые по умолчанию или изменить его, как они хотят. Аргумент paneNumber или эквивалентную информацию контексте также должны быть предусмотрены эти функции замены, чтобы они знали которых панели (или любой другой), они заполняют дюйма Излишне говорить, что это должно быть доступно всем пути от заголовка шаблоны все, вплоть до каждого шаблона ячеек, каждая снабжена свой специфический информационный контекст.

   Я за предложение Луки о том, что сахар метод, показывающее, сколько панелей Вы хотите за один раз и пусть Календарь справиться с этим. Интересно, о расположении этих календарей. Разве они, естественно, ломать и поступать в следующей строке по правому краю? При нынешних шаблонов, вы должны определить, но как насчет сахара собственности с указанием количества панелей вы хотите? Затем вы должны указать, хотите ли вы, скажем, целый год в два ряда по 6, 3 ряда по 4 или любой комбинации. Предоставление каждой панели ClassName с порядковым номером позволит дизайнерам справиться с этим через CSS, хотя было бы хорошо иметь один атрибут, как сахар "panesPerRow" или что-то подобное.

   Правила должны распространяться на дней до или после текущего месяца. Если вы не хотите, чтобы правило было применено к конкретному месяцу, вы должны установить правило не делать этого, не имеет календаря просто игнорировать все правила. Все, что отображается должны следовать тем же правилам. Как я уже говорил, если вы путешественник делает бронирование гостиничного номера или билет на самолет в последнюю неделю месяца, и вы ищете наличие или предложения, это не приемлемо, что дополнительные дни не показывают наличие мест / номеров / или предложения, которые вы должны на самом деле переходить назад и вперед между месяцами, а если 1-й, не примыкающие к в последний день предыдущего месяца. Если они не следуют правилам, что вы показать им, для? И если вы не покажете им, вы хотите, чтобы заставить пользователя перейти.

   В связи с этим, календарь должен предложить пару вспомогательных методов для разработчиков, чтобы получить диапазон дат месяца (специально для мульти-панели календари) и диапазон дат, показал (в том числе дополнительные до и после). Это было бы удобно, чтобы собрать запрос ввода-вывода для данных, связанных с каждого календарного ячейки (количество мест, стоимость билетов, праздники, любой другой) в рамках одной транзакции. Эти методы должны быть в состоянии представить эту информацию до календаря фактически оказанные, чтобы избежать мерцания.

   Комментарий Satyam - 29 июля 2011 #

Оставить комментарий