Интенсив «Шаблоны и анти-шаблоны дизайна». Загрузка прямо в мозг разработчика.

TurboGears: разрабатываем веб-приложения на Python

Иван Сагалаев с увлечением взялся рассказывать о Django — среде для разработки веб-приложений на Питоне. Подстегнутые популярностью Ruby on Rails, Python разработчики, похоже, кинулись готовить достойный ответ. Точнее, ответы.;-)

Я определился с выбором в пользу TurboGears. Почему не django или что-то другое?

Во-первых, разработчик (и) TurboGears не стали изобретать велосипед, а взяли готовые, зарекомендовавшие себя компоненты: MochiKit, Kid, CherryPy, SQLObject. Это дает не только внушительный объем функциональности, но и доступ к сложившимся вокруг этих проектов коммьюнити. Во-вторых, мне понравился исходный код, организация проект и «первая производная» (а. к. а вектор развития). Ну и наконец — не хочу повторяться. Пусть Иван Салагаев описывает Django, а я буду писать о TurboGears (если это кому-то интересно).

ЗЫ: К «промышленному» использованию TurboGears пока не готов, ИМО, так что если вы ищите готовую среду для разработки веб-проекта с конкретными сроками лучше посмотрите что-то другое. Ruby on Rails, к примеру.;-)

  • Популярное

19 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Я не ошибусь, если скажу что Zope CMS (а на ней и построен Плон) древнее Django. Хотя это отнють не говорит о приемуществе одних над другими. А вообще очень внимательно слежу за развитием TurboGears, и их результаты очень впечатляют. Ждем 1.0 с нетерпением. ЗЫ: Последних пару проектов сдал именно на 0.9a4−5. Я давно не чувствовал такого азарта:)

Django уже существовал в production когда РоР начали создаваться.

Факты?

Подстегнутые популярностью Ruby on Rails, Python разработчики, похоже, кинулись готовить достойный ответ.

Django уже существовал в production когда РоР начали создаваться.Так, на заметку...

to max: Курица или яйцо?:) Эту шкуру вижу на многих девулоперский сайтах

По-моему, даже по названию темы ясно ее происхождение: plubrick == plone + kubrick.; -)

dem: Нет, сайт на PHP (WordPress).

Кстати, что то мне подсказывает, что и этот сайт на Plone писаный.А скин, этот можно с plone.org закачать;)

Не знал что на родной Украине есть python community.С Вашего разрешения пару реплик обо всем выше сказаном.TurboGears я еще никогда не рисковал использовать для реальных проэктов. Уж больно они молоды, и пока дальше чем на бета версию не тянут. Чего в свою очередь нельзя сказать про компоненты Гиарс: Cherrypy, SQLObject, Kid — использую как альтернативу Zope + Plone в более простых проэктах. Скажем, для большинства проэктов этого сочетания достаточно. Единственно чего не понял — так это Mochkit (да и не зачем это программеру, которому выдают готовые шаблоны:)) Хочется сразу же развеять миф о якобы «тормозах» Zope и иеще больших гальмах Plone. Вот сдаю сайт одного «торгового комплекса» (в народе — рынка) 1030 торговых мест, у каждого свой товар, а у соседа надцать вариатций того же самого... Вобщем черт ногу сломает. Предварительные тесты показали, что Плон (вернее ZSQL Methods) тормозит не намного больше, чем SQLObject. Просто сам по себе Зоп «кушает» много оперативной памяти. Но за все нужно платить. Благо дело для закупил свой сервер, и теперь и шнец, и жнец... и хостиг в придачу...ПС. А сайт этот я сделал за 3 недели, по вечерам с бутылкой пива в свое удовольствие. Делайте выводы.

Веприк, мне кажется вы несколько искаженно представляете TurboGears. Да и у Ruby (который просто, не Rails) проблем куда как больше чем у питона.

Можете помочь по TurboGears и Pyton???
Какие там файлы являются индексными там???
Свяжитесь со мной при возможности skype: technosila.com.ua
icq 345076065

Веприк, вот и оформил бы это в виде поста «почему все фигня кроме Zope».
Я не казав, що все фігня крім Zope. На жаль детальніше написати про нього мені важко, бо користуюся ним (навіть не ним, Plone) в основному на рівні користувача для власних потреб слабо вникаючи в деталі його роботи і це для мене перевага, бо ця система вже має промислову якість і я її можу вже реально використовувати нічого не підкручувати. Наразі я знайомий з кількома людьми, які займаються впровадженням рішень на їх основі, але їх завантаженість теж не дозволяє цього зробити.А стосовно TurboGears і їм подібним, то моя думка повторить кимось вже сказану, другий Rails on Python не вийде, бо він буде завідомо гірший за перший, поки ви займатиметесь простим копіюванням функціональності, Rails приростатиме новими можливостями, хоча як полігон для випробування це без сумніву добре. От що мене дратує, так це фрагментарність, наразі тільки більш-менш популярних веб-фреймворків під Пітон вже можна нарахувати під 10 штук, які кожен в базі своїй повторно реалізує одну і туж функціональність, наприклад низькорівневу роботу з HTTP протоколом, от це мене хвилює. Ще одне проблема багатопоточності в реалізації інтерпритатора Пітона, що змушує шукати альтернативні нестандартні підходи, а це є серйохним обмежувачем для маштабованорсті, бо зараз рідко який blade-сервер ставиться з одним процесором.

Извините, Иван, сейчас исправлю.

Только сейчас заметил, что в фамилии моей ошибка. Правильно — Сагалаев.

Веприк, вот и оформил бы это в виде поста «почему все фигня кроме Zope».; -) Хотя я эту позицию (и аргументы) совсем не разделяю.

Власне сам Zope як сервер аплікацій мені не потрібена, але як двигунець CMS Plone, дуже хороша штука, я підняв інтранет сайт, налагодив за його допомогою мінімальний документообііг і я досі не вникав на те як його програмувати, оскільки наразу можливостей стандартних та завантажуваних компонентів є значно більше, ніж мені треба. Зовнішній вигляд окремо мніяється через спеціальні шаблони, що теж не вимагає знання Python, хоча ця мова вартує, щоб її вивчили.А стосовно TurboGears, Django історія їх виникнення зазвичай стандартна. Раптом знаходиться людина, яка думає мені це неподобається треба переписати все на... я зроблю гарну просту систему якою всі будуть користуватися, але з часом вимоги до такої системи зростають, користувачі вимагають все більше можливостей і з простого неминуче виходить монстр, це не є добре чи зле, істина десь посередині, але я остерігаюся пропонувати клієнтам продукти, що базуються на неперевірених технологіях з неясною перспективою. Стосовно Rails, то як я зрозумів основна його фішка в тому, що за рахунок ослаблення взаємозвязку, точніше навіть не ослаблення, а динамізму та гнучкості, між реляційною моделлю бази та обєктною вебаплікації спрощується розробка власне аплікації. Проте як на мене дане рішення має обмежену застосовність, так воно добре до користувачів далеких від ІТ-технологій, оскільки дозволяє їм зосередитись власне на контенті, а не особливостях реалізації, але наприклад в сфері е-комерції на перший план виступає безпека і мені важко поки що сказати як вільності в поводженні з даними, а головне в їх інтерпритації скажуться на захищеності, оскільки теоретично це відкриває широкий простір для різного роду маніпуляцій, знову ж таки відповідь на це може дати лише час.

..., а я буду писать о TurboGears (если это кому-то интересно)...

Очень интересно, продолжайте

Ви знаєте, мені якось ніколи не приваблювала платформа Zope. Можливо просто не було доречних задач. Якщо є натхнення, напишіть про цю платформу пост — думаю, багатьом було б цікаво.

А може все таки справді надійні використовувати компоненти. Які вже готові до промислового використання. Той самий Zope, Plone.

Подписаться на комментарии