Python-сообщество

Предлагаю начать обсуждать сабж.

У меня есть опыт работы с Zope2+Plone, недавно ознакомился с Zope3 по книге “Web Component Development with Zope 3”.

Сказать чтоб сильно удивило, нельзя. Вау-эффект на меня не подействовал. Зато нашел вещи, которые меня очень расстроили:

* zcml. Ужасная громоздкая вещь. Напоминает то, над чем Sean Kelly насмехался в своем скринкасте http://oodt.jpl.nasa.gov/better-web-app.mov. Только насмехался он над явой, показывая что явовские фреймворки совершенно непригодны для создания веб-приложений. Необходимость писать кучу xml-ного кода убивает “rapid turn-around”, то есть возможность вносить мелкие изменения.

* дурацкие значки в урлах. Не понимаю, зачем пользователю видеть в адресной строке браузера двойные плюсы и @. Мне думается, что это глупо.

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

nss
* zcml. Ужасная громоздкая вещь. Напоминает то, над чем Sean Kelly насмехался в своем скринкасте http://oodt.jpl.nasa.gov/better-web-app.mov. Только насмехался он над явой, показывая что явовские фреймворки совершенно непригодны для создания веб-приложений. Необходимость писать кучу xml-ного кода убивает “rapid turn-around”, то есть возможность вносить мелкие изменения.

1. Ну, если бы в J2EE-фреймворках компоненты складывались/конфигурировались не на XML, а на Java … он, наверное, еще больше бы смеялся :)

2. Рассудим так: читаемость XML резко ухудшается при множестве уровней в дереве. В ZCML-файлах - 1-2 уровня (не считая корня). IMHO, они наоборот удобны: смотришь на основной конфиг и видишь все приложение как на ладони.

3. Регистрация компонент, “позднее связывание” интерфейсов и т.д. вручную, т.е. на Python, будет гораздо менее прозрачным, чем на zcml. Фреймворк на то и фреймворк, чтобы брать на себя черную работу.

4. В Zope 3 xml-подобный конфиг наоборот, не убивает “repid turn-around”, а значительно облегчает. И мое мнение таково, что облегчает изменения / дополнения очень и очень сильно. По моему, это очевидно.

5. Конечно, все это дело вкуса … Но zcml, насколько вижу, нравится многим своим удобством, поэтому, например такой Zope3-фреймворк, как Grok (избавляющий от написания zcml), вызывает довольно противоречивые мнения.

6. Одна из причин громоздкости ZCML-файлов в том, что для каждой компоненты нужно явно указать доступы, не “вынося за скобки”. Выглядит это как многократное повторение одного и того же в разных местах. Но это и приемущество - так как дает полную гибкость в указании свойств каждой конкретной компоненты.

7. Сложность Zope 3 в большом количестве приготовленных для разработчика велосипедов в виде интерфейсов, которые писать не нужно, но ведь нужно еще и знать об их существовании.

nss
* дурацкие значки в урлах. Не понимаю, зачем пользователю видеть в адресной строке браузера двойные плюсы и @. Мне думается, что это глупо.

Недавно, сделав в частном порядке сайтик на Django, я с большой гордостью показывал заказчику на красивые урлы.
Что поразило, он никак не отреагировал на это и сказал “мне по барабану, что там в адресной строке”.
При том, что заказчик - заядлый вэб-серфер.
Ну а если применять разные пространства имен к одному и тому же объекту, что есть очень удобно, то, IMHO, ++ - это красивее, чем ?qwres=kjhg56kj&h7h=7kgjhgk&lzfdsz=kjhg… :)
К тому же @@ как частный и стандартный случай “++” - не нужен на каждом шагу, в реальности если посмотреть на Zope-3 сайты, то эти @@ встречаются очень редко, так как в большинстве случаев объектов и представлений с одинаковыми именами в одной папке нет.

Отредактировано (Сен. 23, 2007 01:14:37)

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

ZCML - это не способ настроить то что есть чтобы оно работало, а способ создать то чего еще не было. Ну в общем-то громоздким кажется из-за отсутствия нормальных редакторов.

xen
Ну в общем-то громоздким кажется из-за отсутствия нормальных редакторов.

xen, что имеешь ввиду ?

ZCML - это большие конфигурационные файлы. Обвязку писать неудобно, а мысль выразить можно. Неудобство часто можно уменьшить если использовать удобный IDE. Наши программисты как-то научились эту работу перекладывать на Eclipse, но заставить их написать статью про это пока не получилось :)

xen, вот смотри: пользуюсь Vim'ом. Привычно и удобно. Но меня посещала идея - а не сделать ли для ZCML, скажем на wxPython, Нечто, даже сам не представляю что … не совсем похожее на редактор, а с какими-то формочками что-ли … :/

Автоподстановку классов и интерфейсов - вроде бессмыссленно.
Запускть debugzope, а в его среде wxPython-приложение ? Совместив с неким функционалом для тестирования ?

Другое дело - стандартные директивы, подсказка по выбору атрибутов и поддиректив. Что ваша команда считает по этому поводу ? Стоит ли ?

Eclipse - вообще придуман для того, чтобы к нему плагины писать.
Но, я например предпочитаю бегать с автоматом, чем в танке сидеть.

Отредактировано (Окт. 17, 2007 23:23:34)

Я вообще с картой в руках на бой смотрю, так что только впечатления других рассказываю :)

Если посмотреть apidoc, то там есть реестр всех директив, можно сделать генератор конфига для Eclipse (или другого редактора) который натравливается на целевую инстранцию и запустив zope в debug-mode считывает все что надо. И быстро и бегать можно.

xen
Я вообще с картой в руках на бой смотрю, так что только впечатления других рассказываю :)

Если посмотреть apidoc, то там есть реестр всех директив, можно сделать генератор конфига для Eclipse (или другого редактора) который натравливается на целевую инстранцию и запустив zope в debug-mode считывает все что надо. И быстро и бегать можно.

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