Шаблонизатор

[k0sh]

Предлагаю перейти на использование шаблонизатора!

[Eugeny]

Кастую команду разработчиков в этот тред и прошу проголосовать.

[Eugeny]

Голосую против, потому что такой подход
а) потребует от разработчтика плагина целиком верстать свой UI
б) на корню убивает консистентность дизайна UI между плагинами

[Eugeny]

Я сейчас делаю упрощенную шаблонизацию на UI "как есть" (см ветку newui)
Так вроде и шаблоны есть, и переверстывать не надо

[DmZ]

Ничего не убивает, я сейчас переписываю текущий UI с использованием валидного XML (зачем изобретать методы get_HTML() когда все было придумано до нас в XML)
Просто использовать шаблоны нужно с умом, т.е. некоторые задачи вынести в шаблоны - например верстку страницы, будет удобнее и дизайнерам и программистам, а некоторые (типа создания UI элементов) оставить на текущем модуле
Таким образом должны остаться сплошные удобства :)
Единственное что - мне по душе больше Genshi - как полностью XML-валидный шаблонизатор

[k0sh]

потребует от разработчика плагина целиком верстать свой UI

то как это сейчас сделано, требует от разработчика еще больше усилий чем просто сверстать панель плагина самому.

на корню убивает консистентность дизайна UI между плагинами

не убьет если предоставить автору плагина готовые теги шаблона.

XML-валидный шаблонизатор

зачем XML о.О? есть прекрасные python style шаблонизаторы Mako, Jinja2

[DmZ]

зачем XML о.О? есть прекрасные python style шаблонизаторы Mako, Jinja2

Я неправильно выразился - Genshi тоже python style, можно использовать питон как и в любом другом темплейтере. Его преимущество в том, что он не определяет новую разметку темплейтов (Мако использует % для своих тегов, а Jinja2 фигурные скобки), а использует свойства XML, что просто более читабельно для человека который просто будет редактировать шаблон.
Ну и одно из преимуществ с чем я столкнулся - так как там используется разметка внутри тегов HTML (XML), это не ломает подсветку редакторов HTML чем облегчает работу дизайнерам

то как это сейчас сделано, требует от разработчика еще больше усилий чем просто сверстать панель плагина самому.

Просто текущая реализация далека от юзабилити, хотя идея отличная

ИМХО конструктор UI идея гут и должна жить, темплейтер тоже имеет право на жизнь - текущая реалиазация dump_base_page или MainWindow просто просит темплейтера. В идеале темплейтер и UI конструктор должны быть тесно связаны. Например возможность загрузить темплейт в контрол (например сложный какой-то для редактирования кучи всего) или включить контрол в темплейт простым тегом

[Eugeny]

DmZ,

Возможно есть смысл сделать XML-based генератор UI (см. Glade)
Дабы не рожать тонны кода для построения интерфейса

[DmZ]

ЗЫ. немного кода из Mako и Genshi:
Mako:
% for name in row
${name}
% endfor

Genshi:
${name}

ИМХО последнее красивее :) Хотя с Мако не работал, может и там можно лаконично написать

[DmZ]

Возможно есть смысл сделать XML-based генератор UI (см. Glade)
Дабы не рожать тонны кода для построения интерфейса

Glade всего лишь инструмент, при загрузке интерфейса все равно вызывается тонна кода, которая правда спрятана от девелопера.
Да, это именно тот подход, о котором я говорю (наверно :)), когда есть некий шаблон index.html где прописан шаблон, а туда можно добавить что-нить типа
И этот же код (или взаимопреобразуемый) получать от ajenti.ui.Table, с возможностью сказать loadtemplate('index.html').getElementsByTag('body').appendChild(Table)
Тогда будет и единый UI и все прелести темплейтера

ЗЫ. с любым темплейтером можно сделать <% ui.Table(someparams) %> и теор. получить консистентный UI. А каким образом реализовать этот самый ui.Table - тонной прямого кода, тонной кода которая будет парсить файлик widgets/Table.xml и т.п...

[k0sh]

Согласен красивее :) но зато медленней (http://stackoverflow.com/questions/1324238/what-is-the-fastest-template-system-for-python). Хотя скорость в данном случае не особо важна. Отдаю свой голос за Genshi.

[DmZ]

Хорошая ссылочка :) правда нам 10х1000 таблиц не нужно (хотя кто знает)
В закладки, нужно поизучать темплейтеров :)

[AlexSnet]

Голосую против!
а) Не хочу писать шаблоны
б) Удобней пользоваться классами ui
в) Без этого в любой момент можно полностью переделать UI всего лишь переписав один-пару файлов

[DmZ]

б) Удобней пользоваться классами ui

Мне тоже "удобно" пользоваться ui (до полного удобства пилить и пилить)
Но если представить какой-то сложный интерфейс, то только его описание в питоне займет уйму места, и искать по этому коду, а где же тут собственно обработка данных будет проблематично.
Поэтому органичное взаимодействие шаблона и UI-классов есть ответ на такую проблему - хочешь делай классами, хочешь пиши шаблон - работать и выглядеть должно одинаково.

в) Без этого в любой момент можно полностью переделать UI всего лишь переписав один-пару файлов

В любом случае менятся будут css стили, которые ну никак на UI не завязаны :) и разница по времени изменения внешнего вида при UI и при шаблоне не существенна.

PS. Я за шаблоны если они органично впишутся в систему UI-классов

[vanmaxim]

Склонен к идеи использования шаблонизатора, и если понадобится при помощи его вызывать код ui. Только вопрос, неполучится ли у нас "спагетти-стайл" код если один будет юзать шаблоны, а другой ui

[AlexSnet]

DmZ убедил.
Если сделать возможность использовать и то и то, то...
Разумеется в таком случае надо описать типовые компоненты на том же шаблонизаторе и дать возможность создавать свои компоненты.

[Eugeny]

DmZ, я не совсем это в виду имел.

Допустим, плагин имеет layout.xml:
[layout]
[panel height="400" width="400"]
[label id="lblOne" text="asda" /]
[button id="btnTwo" text="qwerty" /]
[/panel]
[/layout](парсер съел угловые скобки)
и т.п.

Платформа имеет файлы panel.html, button.html, label.html, etc. (возможно, с питоновыми вставками для правильной генерации HTML основываясь на атрибутах в Layout XML) которые парсятся шаблонизатором.

Потом на ходу берется сий layout.xml и перегоняется в HTML, используя panel.html, button.html, label.html, etc.

[DmZ]

Попробую обьяснить на примере, ИМХО это тоже, что Евгений имел ввиду.
(примеры взяты из документации Genshi)
Для того чтобы UI и темплейтер работали вместе - процессинг кода нужно переносить на что-то одно. В данном случае примем за основу темплейтер.
Genshi позволяет определять собственные XML-теги (типа label/panel, то что нам нужно).
Итак, положим есть файл widgets.xml следующего содержания:
<py:match path="greeting">
Hello ${select('@name')}
/py:match
Ну, или просто содержит инклуды на кучу подобных конструкций.
В основной темплейт или темплейт видгета мы импортим данный файл, и дальше используем в виде:

В итоге получим:

Hello Dude

Функции UI выдают на-гора соответствующие теги XML:
>>> ui.Span("Dude").toxml()
''
И в коде таким образом можно использовать конструкции вида (псевдокод):
template = initTemplate()
window = ui.MainWindow()
template.appendElements(window)
return template.render()
или вида:
template = initTemplate()
template.appendFromFile('layout.xml')
return template.render()

Таким образом обеспечится консистентность вида между темплейтером и UI-виджетами.

ЗЫ. Если лень писать xml для сложных виджетов, то можно запрограмить это в питоне и на конечном виджете вызвать toxml() и задампить вывод в файл, для последующего юзания - вариантов использования просто масса.

[Eugeny]

Это божественно, я сжигаю рукописи своего UI (:

[DmZ]

Это божественно, я сжигаю рукописи своего UI (:

А сколько еще интересных идей/опыта есть ;)

ЗЫ. Попытаюсь завтра накидать пример рабочий на своих плагинах (а то сегодняшнее пиво все ушло на предыдущее описание :) )

[k0sh]

DmZ молодчина!

[Eugeny]

Перенесено:
http://groups.google.com/group/ajenti-dev/browse_thread/thread/f51899f2e69725e?hl=ru