А расскажите про разные веб-ориентированные языки программирования
Все вот твердят про всякие Ruby + Rails или Phyton + Zope.тогда уж Python + Django, жопа это немного другое.
Мне сейчас сильно влом развёрнуто отвечать на твой вопрос, постараюсь завтра рассказать о личных ощчучениях.
Пока контрвопрос.
Это как, если строковые и прочие функции давно корректно работают с уникодом? Ряд веб-проектов целиком на уникоде пашет.
Пока контрвопрос.
Первый очень удобен, но потихоньку протухает в силу отсутсвия встроенной поддержки юникода
Это как, если строковые и прочие функции давно корректно работают с уникодом? Ряд веб-проектов целиком на уникоде пашет.
Переменные, пришедшие снаружи не поддерживают юникод. Писать исходники в юникоде формально нельзя (т.е. они интерпретируются побайтово, потому в UTF-8 можно). И вообще, создание юникод-сайта на PHP вызывает лёгкое отвращение к его разработчикам, ибо могли и включить юникод в пхп5.
Про питон+джанго:
1) язык не заточен под веб, что не мешает ему иметь все, что у тебя в скобках перечисленно, частью на уровне стандартной библиотеки питона, частью средствами веб-фреймворка джанго.
2) на уровне языка действует единый стандарт общения с БД драйверами (sqllite, mysql, postgresql,oracle и еще несколько). на уровне джанго имеется приличный ORM.
3) можно. в питон 2.5 вообще без гемора (и раньше можно было без гемора, но сейчас в стандартную библиотеку включили ctypes)
4) охрененный =)
1) язык не заточен под веб, что не мешает ему иметь все, что у тебя в скобках перечисленно, частью на уровне стандартной библиотеки питона, частью средствами веб-фреймворка джанго.
2) на уровне языка действует единый стандарт общения с БД драйверами (sqllite, mysql, postgresql,oracle и еще несколько). на уровне джанго имеется приличный ORM.
3) можно. в питон 2.5 вообще без гемора (и раньше можно было без гемора, но сейчас в стандартную библиотеку включили ctypes)
4) охрененный =)
Еще для Python есть Twisted. Там и язык шаблонов и еще куча всего.
Язык шаблонов: Cheetah круче всех.
Язык шаблонов: Cheetah круче всех.
Про Ruby on Rails немного расскажу.
Фреймворк заточен исключительно под веб
Поставляется в комплекте с написанным на ruby веб-сервером webricks, позволяет цепляться к апачу и другим, рекомендованный - lighthttp/.
Основан на концепции Model-View-Controller.
Из БД держит довольно много.. MySQL, Postgres, Oracle, еще чтототам.
Библиотеки подключать вроде можно, краем глаза в документации где-то видел, сам пока не пробовал.
Встроенные механизмы кеширования и всего-чего-только-можно. Мощный ООП, довольно приятно сделанный.
Огромный минус - ресурсоемкость и отсутствие поддержки на российских провайдерах (только на двух есть).
Фреймворк заточен исключительно под веб
Поставляется в комплекте с написанным на ruby веб-сервером webricks, позволяет цепляться к апачу и другим, рекомендованный - lighthttp/.Основан на концепции Model-View-Controller.
Из БД держит довольно много.. MySQL, Postgres, Oracle, еще чтототам.
Библиотеки подключать вроде можно, краем глаза в документации где-то видел, сам пока не пробовал.
Встроенные механизмы кеширования и всего-чего-только-можно. Мощный ООП, довольно приятно сделанный.
Огромный минус - ресурсоемкость и отсутствие поддержки на российских провайдерах (только на двух есть).
+1 за Cheetah
Я ее сам использую вместо джанговского средства.
Просто джанговцы ставили себе цель убрать из шаблонов ну хоть сколь-нить сложную логику и имхо перестарались =)
Я ее сам использую вместо джанговского средства.
Просто джанговцы ставили себе цель убрать из шаблонов ну хоть сколь-нить сложную логику и имхо перестарались =)
Про минус - берешь virtual dedicated server и пускаешь, что хочешь
Хоть RoR, хоть Python'овский фреймворк.
Ресурсоемкость RoR и Python-овских движков примерно на одном уровне, поэтому этим руководствоваться при выборе не стоит.
Из опробованных и изученных в какой-то степени по документации Python'овских MVC-фреймворков, ни один из них не может сравниться с RoR по уровню развития и удобству использования.
В Django понравился ORM, не понравилось всё остальное
Движок шаблонизации Cheetah в чём-то нравится даже больше, чем оный из Rails.
Но, к сожалению, не удалось найти Python'овского фреймворка, который был бы настолько же хорош, как Rails, по сумме всех компонент.
Сам язык Ruby мне нравится больше, чем Python (тема для отдельного треда
поэтому для меня выбор однозначен.
Хоть RoR, хоть Python'овский фреймворк.
Ресурсоемкость RoR и Python-овских движков примерно на одном уровне, поэтому этим руководствоваться при выборе не стоит.
Из опробованных и изученных в какой-то степени по документации Python'овских MVC-фреймворков, ни один из них не может сравниться с RoR по уровню развития и удобству использования.
В Django понравился ORM, не понравилось всё остальное
Движок шаблонизации Cheetah в чём-то нравится даже больше, чем оный из Rails.
Но, к сожалению, не удалось найти Python'овского фреймворка, который был бы настолько же хорош, как Rails, по сумме всех компонент.
Сам язык Ruby мне нравится больше, чем Python (тема для отдельного треда
поэтому для меня выбор однозначен.В общем, если опосля маткроса все же захочется на питоне =)
то советую связку
python2.5+django0.95+cheetah(фиг знает что за номер =) )
то советую связку
python2.5+django0.95+cheetah(фиг знает что за номер =) )
А что насчёт Python+TurboGears ?
TurboGearsЯ не , но вмешаюсь, если никто не возражает =)
Уж больно я натерпелся от SQLObject (ORM в TurboGears): cущий кошмар с юникодом, слабые возможности. =)
Никому не посоветую.
Мне нравится Perl + Catalyst + Template Toolkit.
А насколько гибко кэширование настраивается?
И насколько ресурсоёмко по сравнению с тем же PHP или mod_perl?
И ещё. Что есть Rails по отношению к Ruby?
И можно поподробне про то, как вообще оно устроено? Ну, в частности как там MVC устроен...
И насколько ресурсоёмко по сравнению с тем же PHP или mod_perl?
И ещё. Что есть Rails по отношению к Ruby?
И можно поподробне про то, как вообще оно устроено? Ну, в частности как там MVC устроен...
И ещё. Что есть Rails по отношению к Ruby?Ruby - язык, Rails - библиотека (или как ее любят называть, framework).
MVC там устроен как обычно, классы С и M разложены в отдельные папки
View можно делать либо на Ruby, либо с таким вот языком шаблонов:
<td><%= link_to recipe.title, :action => "show", :id => recipe.id %></td>
А вот такой вопрос. Можно ли сделать так:
В качестве view я буду класть некоторые специальные xml надстройки над xhtml, в которой вообще нет кода, только разве что переменные подставляются. Контроллер парсит его, находит отдельные узлы, для которых вызывает нужный зарегистрированный компонент, передав ему в качестве параметров содержимое узла, а результат работы вставляет на место этого узла. Компонент уже знает, откуда ему брать данные, подставляет переменные в переданное ему содержимое узла, делает с этим содержимым что-нибудь ещё по своему усмотрению и возвращает.
То есть реализовать на Ruby свой XML-based шаблонизатор, не реряя всех преимуществ RoR?
В качестве view я буду класть некоторые специальные xml надстройки над xhtml, в которой вообще нет кода, только разве что переменные подставляются. Контроллер парсит его, находит отдельные узлы, для которых вызывает нужный зарегистрированный компонент, передав ему в качестве параметров содержимое узла, а результат работы вставляет на место этого узла. Компонент уже знает, откуда ему брать данные, подставляет переменные в переданное ему содержимое узла, делает с этим содержимым что-нибудь ещё по своему усмотрению и возвращает.
То есть реализовать на Ruby свой XML-based шаблонизатор, не реряя всех преимуществ RoR?
в силу отсутсвия встроенной поддержки юникодаНу вместо всяких там substr пользуйся mbstring_substr - чем это будет отличаться от "встроенной поддержки", тем, что надо сначала в php.ini этот mbstring подключить?
геморойностью интеграции с библиотеками на других языкахА у кого-то это лучше?
1. Мне надо ручками переписывать $_GET, $_POST и т.д., дабы перекодировать в юникод то, что пришло.
2. В phyton
2. В phyton
phytonчо за зверь?
или это из разряда как fhtagn и fthagn перепутать?
А вот такой вопрос. Можно ли сделать так:Конечно, можно! А зачем?
В качестве view я буду класть некоторые специальные xml надстройки над xhtml, в которой вообще нет кода, только разве что переменные подставляются. Контроллер парсит его, находит отдельные узлы, для которых вызывает нужный зарегистрированный компонент, передав ему в качестве параметров содержимое узла, а результат работы вставляет на место этого узла. Компонент уже знает, откуда ему брать данные, подставляет переменные в переданное ему содержимое узла, делает с этим содержимым что-нибудь ещё по своему усмотрению и возвращает.
То есть реализовать на Ruby свой XML-based шаблонизатор, не реряя всех преимуществ RoR?
А зачем вообще шаблонизаторы делают? Для экономии сил тех, кто ими будет пользоваться.
Чем плох шаблонизатор ERB, встроенный в Rails?
Теоретически такое сделать можно, но Rails довольно сильно заточен под свой собственный шаблон, придется многое менять. Кроме того, ORM там сделано строго по паттерну ActiveRecord, отсюда очень жесткая привязка объектной модели к базе.
Серьезные приложения под Rails я не писал (и пока не знаю никого в Москве, кто бы этим занимался). Зато очень приятный язык Ruby, по мощности не уступающий Smalltalk.
А почему не рассматриваются варианты типа .NET?
Серьезные приложения под Rails я не писал (и пока не знаю никого в Москве, кто бы этим занимался). Зато очень приятный язык Ruby, по мощности не уступающий Smalltalk.
А почему не рассматриваются варианты типа .NET?
Серьезные приложения под Rails я не писал (и пока не знаю никого в Москве, кто бы этим занимался).А что называется серьезным приложением?
О. Вот я тоже глядя на RoR подумал, что он довольно специфичен и при нестандартном использовании будут проблемы. Это и останавливает.
.NET рассматривается. Ежели есть опыт - рассказывай что и как. Но знакомство с множеством других продуктов от MS подсказывает мне, что там шаг влево, шаг вправо от предполагаемых MS сценариев работы - и ты в глухом непроходимом лесу, где всё делается через жопу. Может касательно их веб-сервера это и не так, конечнго...
.NET рассматривается. Ежели есть опыт - рассказывай что и как. Но знакомство с множеством других продуктов от MS подсказывает мне, что там шаг влево, шаг вправо от предполагаемых MS сценариев работы - и ты в глухом непроходимом лесу, где всё делается через жопу. Может касательно их веб-сервера это и не так, конечнго...
Я с ним незнаком. Может и хорош. Но я хочу сделать шаблоны минимально отличающиеся от xhtml, не содержащие программного кода и доступные домохозяйкам.
Странно... если я отправляю пользователю свой вывод в юникоде, то и данные от него тоже в юникоде приходят 
Вполне естественно, что от пользователя данные приходят в той же кодировке, в которой их отправляешь ему ты, что тебе не нравится-то?
О. Вот я тоже глядя на RoR подумал, что он довольно специфичен и при нестандартном использовании будут проблемы. Это и останавливает.Поскольку Ruby динамически типизирован, ты сможешь изменить поведение любой части Rails безо всяких проблем. Другое дело, что тебе для этого придется рыться в исходниках фреймворка или хотя бы очень хорошо и в деталях представлять себе, как он работает.
Для того, чтобы реализовать описываемое тобой поведение, сильно глубоко лезть не надо, хотя это зависит от того, насколько удобно ты хочешь с этим работать. Например, неудобно будет писать в каждом action'е controller'а:
render :text => do_my_mega_template_stuff(render_to_string(....С первого взгляда мне кажется, что с помощью API Rails можно реализовать необходимую логику более красивым способом.
Но я хочу сделать шаблоны минимально отличающиеся от xhtml, не содержащие программного кода и доступные домохозяйкам.Приведи какие-нибудь пояснения того, что ты считаешь доступным домохозяйкам, а что нет. Примеры приветствуются
Моя твоя не понимать.. у меня переваривается юникод на ура.. Что я делаю не так? Приведи пример.
То, что ты описываешь, в принципе встречается в таких библиотеках как Tapestry или Wicket.
Синтаксис Perl действительно труден, объектная модель также оставляет желать лучшего. В этом я согласен.
С юникодом в php я проблем еще не встречал, у меня несколько достаточно крупных проектов работают на нем. К тому же уже давно на php.net лежат исходники 6 ветки php, которая, как было заявлено Змеевским (один из разработчиков php) на последней российской конференции, посвященной PHP, полностью будет поддерживать юникод. При желании можно собрать и проверить (там еще частичную типизацию обещали ввести).
Расширение возможностей php, также не представляет проблем - далеко ходить не надо, PDO - ые библиотеки, тому отличный пример.
Так что причин отказываться от php вижу мало, да и не сказал бы я, что язык загибается, пока замечаю исключительно обратную тенденцию.
С юникодом в php я проблем еще не встречал, у меня несколько достаточно крупных проектов работают на нем. К тому же уже давно на php.net лежат исходники 6 ветки php, которая, как было заявлено Змеевским (один из разработчиков php) на последней российской конференции, посвященной PHP, полностью будет поддерживать юникод. При желании можно собрать и проверить (там еще частичную типизацию обещали ввести).
Расширение возможностей php, также не представляет проблем - далеко ходить не надо, PDO - ые библиотеки, тому отличный пример.
Так что причин отказываться от php вижу мало, да и не сказал бы я, что язык загибается, пока замечаю исключительно обратную тенденцию.
имхо, но использовать русский язык непосредственно в исходнике - извращение, т.к. полностью исключается возможность интернацианализации приложения
а комментарии к методам, можно и на английском писать
а комментарии к методам, можно и на английском писать
Да, видимо проглючил. Просто был когда-то у мну гемор из-за отключеново iconv на хосте.
В любом случае напрягает необходимость юзать для юникода отдельные функции.
В любом случае напрягает необходимость юзать для юникода отдельные функции.
Ну можешь и не отдельные, mbstring - это вообще-то универсальные функции, можешь их для всего использовать.
А как у Ruby с Unicode дела? Как исходники в UTF-8 воспринимаются, строковые функции знают от этом и т.д.?
Исходники в UTF-8 воспринимаются на ура, строковые методы по умолчанию работают со строками, как с байтовым массивом, но есть специальный модуль, который переопределяет методы String'а так, что они начинают понимать UTF-8.
но есть специальный модуль, который переопределяет методы String'а так, что они начинают понимать UTF-8А ссылочки можно, а то я когда гуглил чего-то ничего путного не нашёл. Или не воспринял это как надо.
Ищи по словам:Ну такое я уже видел. Бегло твою ссылку проглядел - это какое-то частичное решение, как я понял. Для ввода-вывода. А функции работы со строками, регулярные выражения и подобное?
code:$KCODE = 'u'
require 'jcode'
На LOR'е вот ещё ссылку подкинули: http://live.julik.nl/2006/10/we-are-the-champions - это уже получше, но ещё есть над чем поработать, я так понимаю. Жалко, а то язык не такой и плохой, а работа с уникодом, мне кажется, уже давно стала востребованной в современных языках.
Я имел ввиду вот это. Там не только ввод-вывод, есть в т.ч. некоторые строковые функции, regexp'ов нет. Да, поддержка слабовата, но я полагаю, что со временем её доведут до нормального уровня.
Сейчас совершенно точно есть закрытый проект, назвать которого не могу, в котором реализованы unicode'ные regexp'ы для Ruby, вероятно, либо его откроют, либо кто-то напишет open source-аналог.
Спасибо за ссылку.
Сейчас совершенно точно есть закрытый проект, назвать которого не могу
, в котором реализованы unicode'ные regexp'ы для Ruby, вероятно, либо его откроют, либо кто-то напишет open source-аналог.Спасибо за ссылку.
Оставить комментарий
sbs-66
Сам я работал с PHP и Perl.Первый очень удобен, но потихоньку протухает в силу отсутсвия встроенной поддержки юникода и геморойностью интеграции с библиотеками на других языках.
Второй не совсем веб-ориентированный, плюс ужасный синтаксис, плюс страшная ООП-модель - в общем, не идеал.
Потому хочется перейти на что-то более удобное. Все вот твердят про всякие Ruby + Rails или Phyton + Zope. Вот расскажите про их плюсы и минусы, кто пользовался. Что это и с чем его едят.
Интересует следущее:
1. Насколько язык заточен под нужды веба и интеграция с апачем (обработка параметров, переданных по GET, POST, куки, сессии, работа со строками, регекспы, XML, XSTL и т.д.)
2. Интеграция с ДБ (что поддержено, насколько лаконично и удобно и т.д.)
3. Можно ли подключать библиотеки на C++ или других быстрых компилируемых языках.
4. Ну, личные очучения от языка.
PS. Может кто-нибудь расскажет про решения от MS - что да как. Насколько универсально, настраиваемо, быстродейственно и т.д. Может есть какие-то принципиальные отличия от связки Apache + MySQL/pgSQL + PHP/Perl?