Здравствуйте.
Есть необходимость создать интранет приложение для работы со сложными древовидными обьектами. Сама логика не столь сложна, и частично уже была реализована в отдельном приложении wxPython. Потому в основном предполагается портирование для работы на интранет сервере. Нагрузка небольшая.
Задача появилась из-за того, что возникает довольно серьезная путаница с версиями как хранимых обьектов, так и самого приложения (последнее становится все более насущной проблемой, ведь py2exe генерирует много файлов, обновлять из которых нужно только несколько. пользователей не получается приучить к аккуратности).
Предполагается дать возможность редактировать обьекты, просматривать, генерировать документы для печати, импорт/экспорт разных форматов. Хочется активно пользоваться дополнительными словарями стандартных данных (типы, виды, и т.п.) кои немаленькие, и полностью делать их доступными на клиенте не будет возможности. А потому наверно придется смотреть в сторону AJAX.
Прошу помощи в определении оправданности использования Zope3 в такой системе.
Наверно, у некоторых есть свое мнение насчет выбора другого подхода. Буду рад хорошим советам.
Спасибо за помощь.

несоветую. zope ну очень показал себя неудобным в плане разработки, версий и самой структуры (zexp).

spSerg
…ведь py2exe генерирует много файлов…

Ерунда. Опция ‘bundle_files’ спасет.

я бы посмотрел в сторону TurboGears

spSerg
Сама логика не столь сложна, и частично уже была реализована в отдельном приложении wxPython.

1) несложно и довольно быстро перенести логику в контролеры ТГ

spSerg
Потому в основном предполагается портирование для работы на интранет сервере. Нагрузка небольшая.

идеальные условия для ТГ

spSerg
ведь py2exe генерирует много файлов, обновлять из которых нужно только несколько.

есть пакет tg2exe по сборке *.exe для проекта

spSerg
А потому наверно придется смотреть в сторону AJAX.

прекрасно работает с AJAX - много готовых виджетов и дополнений (http://www.turbogears.org/cogbin/)

j2a
Ерунда. Опция ‘bundle_files’ спасет.

Премного благодарен за такую подсказку.

pythonwin
я бы посмотрел в сторону TurboGears

Хм. в нете мало откликов о тг. и не такие уж они и позитивные все :(
а то, что из слухов “Turbogears 2.0 будет основан на базе Pylons” не помешает функциональности?

pythonwin
прекрасно работает с AJAX - много готовых виджетов и дополнений

а список поддерживаемых браузеров конечно не входит ІЕ5 (вот такие неприятные условия :( )

похоже придется попробовать под несколькими фреймворками. (если узнают, что я затеял еще пару версий, то на меня обидятся ;) )

Zope3 - да, очень удобен. Для разработки, особенно командной. Быстро и эффективно. А какие данные - древовидные или нет - неважно.

Возможно тебе полезно будет использовать пакет: z3c.blobfile (посмотри в репозитариях.), но не уверен.
Особо сложные персистентные древовидные структуры “с нуля” сам старайся не проектировать (можно накосячить) - используй BTree, его хватит.
Catalog нужно будет обязательно, тогда поиск данных в огромной объектной базе разнородных данных будет мгновенным. AJAX - зачем ? Можно и так сделать, чтоб все летало и прыгало. Не надо в виде (будь то HTML или XML-RPC) отображать весь словарь, можно ведь частями.

cybergrind
несоветую. zope ну очень показал себя неудобным в плане разработки, версий и самой структуры

я тоже не советую заниматься TTW-скриптованием а-ля aquisition logic. Если так делать, то придется использовать ZClasses, а это - зло неимоверное. А продукты зоуп-два писать давно нет смысла, когда есть Zope3.

pythonwin

spSerg
Сама логика не столь сложна, и частично уже была реализована в отдельном приложении wxPython.

1) несложно и довольно быстро перенести логику в контролеры ТГ

По моему глубокому, хотя возможно и неверному убеждению место бизнес-логики в модели

PooH

pythonwin

spSerg
Сама логика не столь сложна, и частично уже была реализована в отдельном приложении wxPython.

1) несложно и довольно быстро перенести логику в контролеры ТГ

По моему глубокому, хотя возможно и неверному убеждению место бизнес-логики в модели

IMHO, понятия MVC-шаблона и что к чему относится в нем и его терминах, достаточно однозначное для GUI-приложений. А вот в вэбе - абсолютно расплывчато, кто что хочет, то и подразумевает. :)

astoon
я тоже не советую заниматься TTW-скриптованием а-ля aquisition logic. Если так делать, то придется использовать ZClasses, а это - зло неимоверное. А продукты зоуп-два писать давно нет смысла, когда есть Zope3.

а разве в Zope3 они отказались от того что весь сайт должен быть в одном файле? и доступен для экспорта только в виде zexp or xml?
Просто я когда увидел что такое Zope2, и что такое RoR, Django или TG, то zope явно был не в лидерах моего хит-парада =)

PooH
По моему глубокому, хотя возможно и неверному убеждению место бизнес-логики в модели

согласен - в принципе всё внутри программы должно быть построено вокруг БД (в разумных приделах :) ):
1) потом легче другим прогаммистам интегрировать с другими продуктами
2) проектируют базу (в ТГ пишут модели БД) примерно, когда и определяют бизнес-логику