Выбор web фреймворка

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

Огласите всю информацию. Какая нагрузка на магазин, какой бюджет, какой размер команды, какая квалификация разработчиков, какие особенности IT-инфраструктуры предприятия, для которого вы делаете сайт. А то как то по-пионерски получается. Пишите на Uncommon Web, говорят, круто.

Да именно по-пионерски :) нагрузка на магазин небольшая, делается исключительно для постоянных клиентов, коих не больше сотни.
Команда - 2 человека: дизайнер и кодер.
Кодер, он же админ, имеет несколько написанных веб проектов на перле (cgi и mod_perl).
Задача есть не написать магазин, а изучить изучить и научиться :) чтобы в перспективе использовать в дальнейших проектах. Магазин скорее как боевая реальная задача.

Ruby On Rails

В книге Agile Web Development with Rails описано создание магазина по шагам, причём не абстрактного, а почти http://www.pragprog.com/ (именно о нём почти все примеры).

В результате, можно сделать C-c C-v, в книге почитать описания/пояснение, по КАЖДОЙ мелочи и как оно делается,
а дизайнер в это время пусть готовит css-ки, рисунки.

Причём RoR, весьма способствует несложным переделыванием сайта(в вашем случае магазина), так что оно не будет похоже ни на какой другой.

Несправедливо.

Дофига крутых магазинов написано не на Java.

Ничего не имею против Java, но "только джава" это фанатство.

В свою очередь выскажу следующее:

ВЕБ не настолько сложная штука, чтобы для более-менее серьезного проекта фреймворк что-то значил.

Скорее, фреймворк напрасно требует learning curve и органичивает в выборе компонентов.

Если хочется сразу и быстро начать, возьмите web.py - очень маленький и простой фреймворк. Никаких дурацких конфигов и создания проекта для hello world.

Если хочется начать обстоятельно, возьмите голый CherryPy WSGI сервер и пишите свой фреймворк (не так сложно, как может показаться. для начала достаточно десятка строчек на python). В качестве DB binding можно взять SQLAlchemy. Или опять же, написать свое.

> Если хочется начать обстоятельно, возьмите голый CherryPy WSGI сервер и пишите свой фреймворк (не так сложно, как может показаться. для начала достаточно десятка строчек на python). В качестве DB binding можно взять SQLAlchemy. Или опять же, написать свое.

Время затраченное на изучение, написание, тестирование соизмеримо с написанием интернет-магазина. В любом случае на готовом фреймворке будет быстрее. Что за привычка - изобретать велосипед?

> Время затраченное на изучение, написание, тестирование соизмеримо с написанием интернет-магазина. В любом случае на готовом фреймворке будет быстрее. Что за привычка - изобретать велосипед?

В данной ситуации академический аспект превалирует над коммерческим. Посему написание чего-то своего даст отличный опыт. Если время позволяет - изобретать велосипеды можно и нужно.

> Время затраченное на изучение, написание, тестирование соизмеримо с написанием интернет-магазина. В любом случае на готовом фреймворке будет быстрее. Что за привычка - изобретать велосипед?

Веб фремворк это несколько строчек на питоне, в самом простом случае. Если берете готовые компоненты для ORM. Десять строчек можно и отдебажить.

А вот разбираться в фреймворке, отлавливать его темные места и писать для них воркэраунды - это потеря времени.

анонимус - дура. жанга писец какая стабильная, многим проектам такого долгоживущего апи можно пожелать.

> жанга писец какая стабильная, многим проектам такого долгоживущего апи можно пожелать.

+1

> жанга писец какая стабильная, многим проектам такого долгоживущего апи можно пожелать

а толку ? сделай в стабильной джанге SQL запрос с OUTER JOIN и указанием принудительного использования ключей ... даже SQLAlchemy не полностью справляется с этим, куда там SQLObject то ?)

В Jango ORM вообще нельзя делать JOIN'ы. Впрочем, джанго пока еще не умеет и много другого.

Насчет стабильности: http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges

Это стабильный API?

а за каким хуем, простите, вам нужен SQLObject в жанге? если вы имели ввдиу жанговский ORM - то не его задача собирать сложные запросы.

а вы повнимательнее посмотрите на список изменений за 2 (!) года. там половина того, что вы даже никогда и не видели, не говорю уже что использовали. смена названия некой локали es_AR на es-ar например. оно лично вас сильно задело?

> В Jango ORM вообще нельзя делать JOIN'ы

Ты наркоман штоле?

Реквестирую пример джойнов с использованием ванильного штатного джанго-орма.

ForumPost.objects.filter(author__username='Antichrist')

Специально для таких маньяков есть такая фича:

http://www.djangoproject.com/documentation/design_philosophies/#option-to-dro...

extra(select=None, where=None, params=None, tables=None)

Sometimes, the Django query syntax by itself can’t easily express a complex WHERE clause. For these edge cases, Django provides the extra() QuerySet modifier — a hook for injecting specific clauses into the SQL generated by a QuerySet.

Что куришь? Где здесь JOIN? Это обычный SELECT FROM WHERE.

И? Это не отменяет того, что через ORM это сделать нельзя. Вы предлагаете объединять таблицы вставляя собственные SQL костыли в сгенерированный запрос.

Недостатки ORM'а вы предлагаете обходить используя собственные SQL запросы даже для простейшего объединения таблиц? Красота. Может вообще выкинуть ORM и оставить только connection.cursor().execute()?

> Что куришь? Где здесь JOIN? Это обычный SELECT FROM WHERE.

Лолшто? А ну марш читать про двойное подчёркивание в джанговских запросах. HINT: author - это FK.

это ли не left inner join ?