15 мар. 2009 г.

Juno - lightweight web framework

Напоролся на Juno случайно. Впечатлен примерами кода с http://brianreily.com/project/juno/:

'Hello, World' in Juno

  • The basics:
        from juno import *

    @route('/')
    def index(web):
    return 'Juno says Hi'

    run()



  • Add some url handling:
        @route('/hello/:name/')
    def hello(web, name):
    return 'Hello, %s' % name



  • Use a template:
        @get('/template/:name/')
    def template_hello(web, name):
    template('hello.html', name=name)




Models




  • Basics:
        >>> Person = model('Person', name='string')
    >>> p = Person(name='brian')
    >>> # p.name, p.id
    >>>
    >>> find(Person).all() # => [ <Person: id = 1> ]





Как видно из примеров, все очень быстро. Синтаксис реально минималистичен. Умеет MVC, совместим с WSGI, включает в себя "development server and SCGI/FastCGI servers", Jinja2 и Mako в качестве шаблонов и SQLAlchemy.

14 комментариев:

  1. Хм, напоминает чем-то синтаксис джанги.

    ОтветитьУдалить
  2. И то правда, но они, кстати, все очень похожи...

    ОтветитьУдалить
  3. Под всеми ты, как я понял, понимаешь пайтоновские фреймворки?

    ОтветитьУдалить
  4. Видимо дело в особенностях языка... Разработчики wfw нашли оптимальную структуру и используют ее вовсю) А ты как думаешь?
    PS А чем джуно аргументирует свой "lightweight" ?

    ОтветитьУдалить
  5. Он очень легкий в плане реального веса фреймворка - это раз, конструкции языка, как видно, короче, чем в джанго в разы - это два, не хватает звезд с неба (узкая функциональность) - это три.

    ОтветитьУдалить
  6. Я собственно так и не понял цели создания этого фреймворка... Разве что как произведение программерского искусства?

    ОтветитьУдалить
  7. Кто бы говорил :) Весь "студент" с его экшн-менеджерами - одно большое произведение искусства :)

    ОтветитьУдалить
  8. ну в этом собственно и вопрос: для какого проекта им это понадобилось?

    ОтветитьУдалить
  9. Этого я, к сожалению, не знаю. Тут вопрос в другом: на западе, в европе и пр. есть "культура" разработки ПО. Например, "там" не зазорно писать док-тесты, сильно заморачиваться на обратной совместимости и выстраивать линию поддержки продуктов так, что продуктом можно пользоваться долго, постоянно мигрируя на новые версии.

    И кроме того, публичный продукт, коим и является Juno в разы лучше не публичного как раз тем, что его уже кто-то использует, кроме разработчиков. Вот мы, например, о нем говорим, а его создатели найдут этот пост и задумаются, а стоит ли ломать функцию, которая лично им уже не нужна, или лучше её оставить, а то вдруг iceone её использует :)

    ОтветитьУдалить
  10. На мой взгляд такая "культура" - это правильно( только если не пишешь проект, которым будешь пользоваться исключительно сам) :)
    Пусть, для этого требуются затраты дополнительных ресурсов, но проект выглядит более привлекательным, если имеет поддержку со стороны разработчиков.

    ОтветитьУдалить
  11. Приложения корпоративного уровня по определению не подпадают под "проект, которым будешь пользоваться исключительно сам", а все что пишется в нефтегазе - живое воплощение парадокса совмещения "пользуешься сам" и "корпоративный уровень".
    Давайте представим ситуацию, что Денис и Дима через 2-3 месяца уезжают из Тюмени достаточно далеко, чтоб не тратить время на нефтегаз. Как думаете что произойдет? Ответ: руководство будет вынуждено полностью поменять ПО, которое они написали.
    Такой подход норма для предприятия с 20ю сотрудниками, но когда речь идет про 3 тысячи сотрудников (!) - моя удивляться сильно-сильно...

    ОтветитьУдалить
  12. Ну вот, если пользуются более 10 человек, то категория "пользуюсь сам" отпадает сама собой, если только продуктом не пользуются только сами разработчики )))))

    ОтветитьУдалить