Откуда ветер дует?
недавно мне подсказали что есть библиотека MochiKit для Javscript'a, которую я пропустилнеудачник, что еще сказать
Например, недавно мне подсказали что есть библиотека MochiKit для Javscript'a, которую я пропустил.Читай специальные сайты и блоги типа http://ajaxian.com, http://www.ajaxplanet.ru и подобные.
Тем более, что на большинстве из них есть rss-ленты.
Часто просматриваю http://slashdot.org, чтобы посмеяться — http://linux.org.ru.
Остальное — сайты и новостные группы по конкретным интересующим меня вещам.
Я обнаружил MochiKit, когда (где-то полгода назад или даже год) смотрел, какие бывают web-фреймворки для Python'а. Наткнулся на TurboGears, а оттуда вышел на MochiKit, и, к сожалению, на SQLObject (никому не пожелаю пользоваться этим).
у меня гугл увешан рсс-виджетами со всяческих сайтов подобной направленности, если вижу интересный заголовок - иду, читаю.
Ну собственно не о MochiKit вопрос. Вообще о кругозоре. Даже не о JS в целом и не AJAX.
Согласен. В итоге какой ORM нравится? или решил что без него лучше?
обнаружил MochiKit, когдаШтука интересная, но 100 кб JS кода грузить при загрузке страницы... бррр. Для больших приложений.
к сожалению, на SQLObject
Согласен. В итоге какой ORM нравится? или решил что без него лучше?
а я дык вот совсем отсталый
недавно посоветовали jQuery
теперь тащусь
недавно посоветовали jQuery
теперь тащусь
SQLObject (никому не пожелаю пользоваться этим).какие у тебя к нему претензии?
а то что-то там у тебя с юникодом не срослось... где-то он не так работает.
а ничего конкретного не говоришь.
1) http://maxischenko.in.ua/blog/entries/89/sqlobject-unicode-a...
2) И снова utf-8. Различное поведение (одинаковый дамп на одинаковых мускул серверах давал либо норм результат либо вопросики в русском либо очередной UnicodeDecodeError и блаблабла) с различными MySQLdb модулями под debian и под FreeBSD. Закончилось фиксированием версии модуля, его патчением (грязным хаком я бы сказал и игрой с параметром unicode в connection url на различных платформах.
3) Кэширование. Хрен отключишь. Игра с параметром cache в connection url результата не дала. В конце концов руками сделал connection.cache.clear. Пока работает. Тьфу-тьфу-тьфу. Работа через mod_python
4) Какая-то совершенно долбанутая вешь. Пример:
Во вьюере проводим сравнение res.status == Status.beingFormed
Оно дает корректный результат в 90-95 процентах случаев.
res.statusID == Status.beingFormed.id работает всегда. Очень удобно, неправда ли?
Работа через mod_python.
5) Родная документация слишком бедна. Тот же вопрос с кэшированием практически вообще стороной обойден.
6) Совершенно непотребное время на инициализацию десятка моделей с 3-5 полями. На той же машине работает django и инициализируется быстрее. +Субъективно некоторые запросы работают медлеенее чем django'ские.
7) Не дотягивает по функционалу до django ORM. Открываем доку по SQLObject, доку по django ORM и подмечаем разницу в функционале.
ЗЫ Все что вспомнил.
2) И снова utf-8. Различное поведение (одинаковый дамп на одинаковых мускул серверах давал либо норм результат либо вопросики в русском либо очередной UnicodeDecodeError и блаблабла) с различными MySQLdb модулями под debian и под FreeBSD. Закончилось фиксированием версии модуля, его патчением (грязным хаком я бы сказал и игрой с параметром unicode в connection url на различных платформах.
3) Кэширование. Хрен отключишь. Игра с параметром cache в connection url результата не дала. В конце концов руками сделал connection.cache.clear. Пока работает. Тьфу-тьфу-тьфу. Работа через mod_python
4) Какая-то совершенно долбанутая вешь. Пример:
class Status(SQLObject):
nameTrans = ForeignKey('I18NString')
__beingFormed = None
...
@staticmethod
def beingFormed:
if not Status.__beingFormed:
Status.__beingFormed = Status.get(1)
return Status.__beingFormed
...
class Reservation(SQLObject):
initDate = DateTimeCol
status = ForeignKey('Status')
...
Во вьюере проводим сравнение res.status == Status.beingFormed
Оно дает корректный результат в 90-95 процентах случаев.
res.statusID == Status.beingFormed.id работает всегда. Очень удобно, неправда ли?
Работа через mod_python.
5) Родная документация слишком бедна. Тот же вопрос с кэшированием практически вообще стороной обойден.
6) Совершенно непотребное время на инициализацию десятка моделей с 3-5 полями. На той же машине работает django и инициализируется быстрее. +Субъективно некоторые запросы работают медлеенее чем django'ские.
7) Не дотягивает по функционалу до django ORM. Открываем доку по SQLObject, доку по django ORM и подмечаем разницу в функционале.
ЗЫ Все что вспомнил.
Вот всё расписал, а я только кратко могу сказать, что он ужасно тормозной, отвратительно глючит с юникодом (причем, по-разному от версии к версии и от окружения к окружению — под окружением я понимаю ОС, версию mysql и проч.) и умеет делать только очень примитивные запросы. Ни в какое сравнение не идёт с ORM в Django.
В целом, я не намерен сейчас мощно отстаивать свою точку зрения, поэтому умолкаю. Я уже полгода как не пользуюсь SQLObject'ом и конкретики почти не помню.
В целом, я не намерен сейчас мощно отстаивать свою точку зрения, поэтому умолкаю. Я уже полгода как не пользуюсь SQLObject'ом и конкретики почти не помню.
Согласен. В итоге какой ORM нравится? или решил что без него лучше?Реляционными БД уже давно не пользовался.
Нравились ActiveRecord в Rails (хотя в нём тоже не сильно мощные запросы можно строить Django.
Ни в какое сравнение не идёт с ORM в Django.а мне Django`вский ORM показался не очень навороченным, так что эта штука наверно совсем жесть =)
и слышал как нахваливали SQLAlchemy (сам на него не смотрел) и даже вроде его в Django собираются интегрировать.
Оставить комментарий
pilot
Как вы следите за развитием IT (и России, и за бугром)?Где читаете новости? Как заметить новые веяния?
Как расширяете кругозор?
Например, недавно мне подсказали что есть библиотека MochiKit для Javscript'a, которую я пропустил.
Google Docs & Spreadsheets кто-то находит сегодня, кто-то 2 месяца назад (в соседнем треде)[, а я ими пользовался еще в октябре].