ищется фреймворк для веб разработки (на джава)
может быть, тогда надо отказаться от слова java? (почти трололо mode)
может быть, тогда надо отказаться от слова java? (почти трололо mode)разумное предложение.
Как топик стартер отностится к RoR, django, Lift? Они в принципе похожи друг на друга и представляют альтернативу джавовому подходу. При этом все три при желании могут хостится поверх виртуальной машины ява
насколько я понимаю в них магии еще больше ...
методы, которые нигде в объекте не объявлены, а в нем присутствуют; naming convention - шаг в сторону и все перестает работать без видимых причин и т.п.
но я глубоко не копал, с какой стоит начать?
методы, которые нигде в объекте не объявлены, а в нем присутствуют; naming convention - шаг в сторону и все перестает работать без видимых причин и т.п.
но я глубоко не копал, с какой стоит начать?
Lift24кб фреймворк это круто =)
но хотелось бы поддержки от IDE
методы, которые нигде в объекте не объявлены, а в нем присутствуют;это ты про наследование?
но я глубоко не копал, с какой стоит начать?Про рельсы vs джанго:
Однозначного ответа нет. Смотря чего хочется получить. В инете полно сравнений то в одну пользу то в другую.
У Руби больше community сайтоделателей, на Питоне больше библиотек для разных случаев.
Т.е. если хочется только делать сайты — Руби может и неплохой выбор.
good point!
я про вещи типа этого. Мне почему-то казалось, что RoR этим очень грешит. Возможно я не прав ...
Джанго не щупал, попробую.
я про вещи типа этого. Мне почему-то казалось, что RoR этим очень грешит. Возможно я не прав ...
Джанго не щупал, попробую.
это даже вопрос не фреймворков, а самого языка. Буду говорить за то, что знаю. В питоне, например, нету переопределения операторов, да и вообще операторов нету. Зато есть naming conventions для операторов: __add__,__radd__ - (+ __call__ - операция скобочек (вызов функции). В общем, такие фишки ограничены в количестве и определены в самом языке.
Так что тебе другого опасаться нужно. Некоторые фреймворки любят делать кастомные загрузчики для модулей (смотри py.test). Они интроспектят функции и в зависимости от названий (например наличия префикса test_) по-разному подключают. Вот это назывется неожиданно. Так же переопределяются вызовы станадртных функций вроде assert - мрак, в общем. Туда не лезь. django вот этим как раз не страдает
Так что тебе другого опасаться нужно. Некоторые фреймворки любят делать кастомные загрузчики для модулей (смотри py.test). Они интроспектят функции и в зависимости от названий (например наличия префикса test_) по-разному подключают. Вот это назывется неожиданно. Так же переопределяются вызовы станадртных функций вроде assert - мрак, в общем. Туда не лезь. django вот этим как раз не страдает
во, я как раз про подобную магию, ты правильно протелепачил
пойду читать джангу, тогда
пойду читать джангу, тогда
Тебе именно компонентный? Тогда Wicket.
Если не-pure-java, то Grails.
Если не-pure-java, то Grails.
Оставить комментарий
bansek
у меня странное желание: чтобы с одной стороны фреймворк брал на себя побольше boilerplate code, а с другой не делал "магии".примеры:
gwt 2.1: магия, магия и еще немного магии (в последнем - см метод getCurrentUserInformation)
gwt 2.0: практически никакой магии, широкая поддержка ИДЕ, но все нужно писать руками с нуля
tapestry 5: магия и МАГИЯ (см раздел про GridComponent)