Comments 67
Хм, заинтересовало. я вообще в Django работаю и еще с универских времен терпеть не могу Java. Стоит попытаться поковырять?
Выглядит очень интересно. Обязательно попробую.
А вы не пробовали Circumflex?
Было бы интересно мнение человека, который хорошо владеет лифтом.
Было бы интересно мнение человека, который хорошо владеет лифтом.
Сайт читал какое-то время назад, определённо положительное впечатление осталось, но времени попробовать не было.
На меня, честно говоря (я тока доки читал) он произвел куда более позитивное впечатление. А уж их ORM вообще выше всяких похвал.
Насторожило: «шаблоны Lift — валидный HTML, не могут содержать кода, но не являются необходимыми, можно генерировать HTML прямо из кода»
Шаблоны, не являются необходимыми? да…
Генерировать html прямо из кода? Они это серьезно?
Шаблоны, не являются необходимыми? да…
Генерировать html прямо из кода? Они это серьезно?
Почему нет? Если, например, я — программист и пишу какую-нибудь мелкую утилитную страничку для себя? XML же не строковыми константами отдаётся, а честно валидируется компилятором. Вот здесь есть пример такого кода, использовано для удобства и краткости: liftweb.net/getting_started
view code
Шаблоны содержат сниппеты в атрибутах класс. Это конечно доставляет, особенно реализация отложенной загрузки и др. Но логику уровня представления нужно держать в уровне представления. Без циклов и условий в шаблонах делать нечего. А мешать HTML/XML с кодом, извините..
override def fixedRender = {
<lift:form>
{
SHtml.text("", s => {
ChatServer ! s
SetValById("chat_box", "")
}, "id" -> "chat_box")
}
/>
</lift:form>
}
извиняюсь предпросмотр не нажал, там еще в коде
<input type="submit" value="Chat"/>
Судить по одному примеру, извините… Судить, не вдаваясь в детали, не разобравшись,…
Конкретно по этому примеру: если необходимо, код для генерации HTML в данном случае можно вынести из метода (в данном случае fixedRender). Получится вызов функции с параметрами. Эта функция может вызывать шаблон, подставлять в него параметры, возвращать результат.
Конкретно по этому примеру: если необходимо, код для генерации HTML в данном случае можно вынести из метода (в данном случае fixedRender). Получится вызов функции с параметрами. Эта функция может вызывать шаблон, подставлять в него параметры, возвращать результат.
Циклы и условия делаются лучше, чем в если бы они были в шаблонах :) Например, так:
"#line *" #> List("a", "b", "c") // <li id="line">sample</li> -> <li id="line">a</li><li>b</li><li>c</li>
вы это верстальщику покажите, когда ему переверстать кусочек HTML подконтрольного циклу придется
У верстальщика буду проблемы с этим?
<li id="line">sample</li>
У него проблемы будет с поиском вашего куска не в html шаблоне, а в исходном коде. И кто возьмет на себя ответственность что он не напортачит там? Удалит пару строчек и сайт заляжет.
А вдруг ему scala так понравится и он прямо в исходнике оставшиеся куски html верстки вставлять начнет?
А вдруг ему scala так понравится и он прямо в исходнике оставшиеся куски html верстки вставлять начнет?
Вы не так всё поняли, возможно, стоит прочитать ещё раз и разобраться получше. No offense.
Так. Я перечитал еще раз. В Lift шаблонах нет логики. Некоторые куски HTML находятся в исходном коде приложения. Чтобы переверстать/доработать HTML сайта нужно переделать HTML шаблоны и HTML куски в исходном коде.
Так что, не все лучшее они почерпнули, не все… и шаблоны дизайнерам дружественные только из-за того что туда не включили циклы и условия, спорно…
Вот сниппеты — круто. Не спорю.
Так что, не все лучшее они почерпнули, не все… и шаблоны дизайнерам дружественные только из-за того что туда не включили циклы и условия, спорно…
Вот сниппеты — круто. Не спорю.
Меня смущает в lift'е, что они в шаблонах пошли по какому то java way, а не ror/django/asp.net (да да, не закидывайте помидорами).
Я имею ввиду, когда в шаблоне мы работаем с view model и инлайним (например, через @Model.Property) значения прямо в шаблон. Насколько я понял (честное слово, с lift не работал), в lift'е надо писать свой снипет, который будет возвращать значение из модели, и потом этот снипет вставлять в шаблон, и указывать теги, в которые он будет замещать. Как то разрывается логика представления и чтобы понять как шаблон будет выглядеть при рендеринге надо скакать от шаблона в класс снипета и обратно.
Я имею ввиду, когда в шаблоне мы работаем с view model и инлайним (например, через @Model.Property) значения прямо в шаблон. Насколько я понял (честное слово, с lift не работал), в lift'е надо писать свой снипет, который будет возвращать значение из модели, и потом этот снипет вставлять в шаблон, и указывать теги, в которые он будет замещать. Как то разрывается логика представления и чтобы понять как шаблон будет выглядеть при рендеринге надо скакать от шаблона в класс снипета и обратно.
Я не совсем понимаю, о чём речь. Мне сейчас, чтобы «понять, как шаблон будет выглядеть» надо просто открыть этот .html файл в браузере. Там, конечно, не появятся данные из базы и не будут работать кнопки, но в остальном всё выглядит один в один.
А если в шаблоне есть условия? Как быть с false ветками? И вообще когда есть шаблон все намного понятней. Еще момент если возможность пользоваться генераторами типа .haml, .sass и т.д.?
Да, написал кашу. Я имею ввиду, как и ivolodin, что в шаблонах нельзя иметь код. А рендерингом участов занимаются снипеты, которые возврощают html. В этом конечно есть и свои плюсы, начиная от большей тестопригодности, pure реализацией шаблона и т.д. Просто когда приходишь из мира, где в шаблонах происходит почти весь рендеринг (конечно, в шаблонах не должно быть взаимодействия с базой или логикой, только исключительно рендеринг модели), это немного вводит в ступор.
Да, я уже говорил, что мне понадобилось несколько заходов, чтобы понять, в чём фишка. Но сейчас чувствую себя вполне комфортно и в целом всё устраивает. В том числе и то, что шаблоны — это html страницы.
Опять же, можно спокойно пользоваться другими temlpate engine-ами, если не ошибаюсь, поддержка Scalate (в котором бывает код в шаблонах, опять же, если не ошибаюсь) поставляется с дистрибутивом.
Опять же, можно спокойно пользоваться другими temlpate engine-ами, если не ошибаюсь, поддержка Scalate (в котором бывает код в шаблонах, опять же, если не ошибаюсь) поставляется с дистрибутивом.
А что двигало Вами? Т.е. обычно если с первого раза не зацепит больше не возвращаешься к этому, а тут 3 попытки)
Во-первых, я постоянно читаю твиттеры, группы и т.п. о Scala и там, так или иначе, постоянно упоминается Lift и новости о нём. А он развивается достаточно быстро и появляются интересные возможности, которые интересно попробовать.
Во-вторых, именно сам факт, что Lift сильно не похож на всё, с чем я привык работать в Java меня сильно притягивал — для расширения кругозора и выхода на более высокий уровень, с которого можно пересмотреть свои старые знания (я этот эффект ещё раньше, со Scala хорошо почувствовал и оценил).
В-третьих, попался удобный проект — с неким подобием веб-чата и кучей интерактивности на ajax. Решил попробовать на Lift, хорошо пошло, втянулся, делаю :)
Во-вторых, именно сам факт, что Lift сильно не похож на всё, с чем я привык работать в Java меня сильно притягивал — для расширения кругозора и выхода на более высокий уровень, с которого можно пересмотреть свои старые знания (я этот эффект ещё раньше, со Scala хорошо почувствовал и оценил).
В-третьих, попался удобный проект — с неким подобием веб-чата и кучей интерактивности на ajax. Решил попробовать на Lift, хорошо пошло, втянулся, делаю :)
А какой логики вам не хватает в шаблонах? циклы и условия легко заменяются сниппетами, причем представление итерации остается в шаблоне и легко меняется. Хтмл очень редко генерится в коде, это либо какие-нить простые элементы (SHtml.text, SHtml.submit, Text, SHtml.ajaxButton), либо небольшие куски шаблона, которые проще держать в коде (например для виджетов).
Естественно, стиль очень непривычный, особенно после классических MVC, мне кажется я до сих пор не привык. Но я от него тащусь :) Особенно от интеграции жс и аякса в фреймворке.
Естественно, стиль очень непривычный, особенно после классических MVC, мне кажется я до сих пор не привык. Но я от него тащусь :) Особенно от интеграции жс и аякса в фреймворке.
Ну вот конкретный пример — надо сделать страницу профиля. Есть UserViewModel с полями типа имя, пароль, email. В RoR/Ruby/Asp.Net MVC я просто делаю шаблон и фигачу туда @Model.Name, @Model.Email и т.д.
В lift'е мне придется сделать шаблон и пометить места, где должны выводится поля юзера как div или span, и в другом месте, в классе написать функции, которые будут возвращать текст или html.
Вот это прыганье меня и смущает.
В lift'е мне придется сделать шаблон и пометить места, где должны выводится поля юзера как div или span, и в другом месте, в классе написать функции, которые будут возвращать текст или html.
Вот это прыганье меня и смущает.
Самый простейший вариант есть, называется CRUDify: www.assembla.com/wiki/show/liftweb/Creating_the_UI_for_Mapper_entities
А вообще, такую штуку при желании можно без проблем реализовать самому. Все нужные точки интеграции открыты. Вот тут в прошлом году кто-то даже делал: www.assembla.com/wiki/show/liftweb/Creating_the_UI_for_Mapper_entities
А может уже где-то и есть в последних версиях, если хорошо поискать :) Сейчас команда большая стала, много комитят.
А вообще, такую штуку при желании можно без проблем реализовать самому. Все нужные точки интеграции открыты. Вот тут в прошлом году кто-то даже делал: www.assembla.com/wiki/show/liftweb/Creating_the_UI_for_Mapper_entities
А может уже где-то и есть в последних версиях, если хорошо поискать :) Сейчас команда большая стала, много комитят.
вторая ссылка должна быть такой: github.com/tromberg/Winglet/wiki/bindmapper
спасибо! посмотрю. scala мне как раз нравится как язык, ибо actor почти в точь в точь взят из erlang'а (чего они и не отрицают). еще мне очень понравился github.com/scalatra/scalatra — думаю на нем делать restful API для одного из проектов.
К сожалению не знаком с шаблонами в РоР/асп.нет, но разве вфигачивание @Model.Name и прочих нельзя сравнить с добавлением бинд-тэгов (<model:name />) или селекторов на хтмл-элементы (<span class="name">name</span>), тем более оч часто селекторы уже присутсвуют? И ассайн переменных в контроллере с биндом в сниппетах? В итоге почти одно и тоже. Единственное, что соглашусь, в контроллере пришлось бы только модель зассайнить, а в сниппетах придется каждое поле. Но на фоне остальных преимуществ — это такая мелочь.
При помощи SBT и JRebel цикл разработки (время между внесением изменений в код и обновлением в браузере) сокращается до нескольких секунд.
По опыту написания на Rails если отключен кеш моделей все происходит мгновенно.
А мне Scala не понравилась. Беспредельный язык, как и руби. Хотя я бы хотел какой-то красивый питона со статической типизацией.
* хотел бы найти какой-то красивый язык вроде питона со статической типизацией.
Дело вкуса, я так Руби предпочел питону и никогда не жалел)
трудно представить…
Хотя я бы хотел какой-то красивый питона со статической типизацией.
трудно представить…
А вы не представляйте, вы смотрите :)
www.python.org/~guido/static-typing/index.htm
www.python.org/~guido/static-typing/index.htm
Только зачем это?
Не могу понять эту идею, нужна скорость и типы, пиши расширения на Си или возьми другой язык.
Зачем пытаться одним языком покрывать все парадигмы и технологии!?
Я как понимаю код написанный с этой опции не совместим с традиционным кодом?
И где тогда красота!? В табуляциях что ли(
Не могу понять эту идею, нужна скорость и типы, пиши расширения на Си или возьми другой язык.
Зачем пытаться одним языком покрывать все парадигмы и технологии!?
Я как понимаю код написанный с этой опции не совместим с традиционным кодом?
И где тогда красота!? В табуляциях что ли(
На 10-м слайде простро страшный сон питониста, перешедшего с C++… )
Есть язык boo: boo.codehaus.org/
Синтаксис питона, типизация статическая. И всякие там еще плюшки.
Правда он под .net, не под JVM.
Синтаксис питона, типизация статическая. И всякие там еще плюшки.
Правда он под .net, не под JVM.
Cython?
Boo
Haskell — там похожий import и можно при желании отступами код группировать
Haskell — там похожий import и можно при желании отступами код группировать
Ну меня вообще не столько формат синтаксиса волнует (скобочки или отступы пофиг), как чистота языка, работа со списками, функциональные возможности. Ruby позволяет такие выкрутасы вытворять, что программа перестаёт вообще напоминать о том, что это ruby. Это грязный трюк, я считаю.
Хаскель — интересный вариант. Поиграюсь, спасибо!
Хаскель — интересный вариант. Поиграюсь, спасибо!
Как может современный, статически типизированный, еще и научно-исследовательский яызык быть беспредельным.
А ну да) Если я не ошибаюсь у скалы компиляция в java-байткод, тогда конечно круто!
Scala очень красивый язык, обожаю его и пишу на нем диплом ;) Лифт обязательно попробую — есть пара идей, на которые пока нет времени.
Я тут встречал мнение, что с нулевым знанием Java в мире Scala делать нечего. Это правда? Просто мало того, что монструозный синтаксис Scala надо освоить, так еще всякие Java-классы, Maven и т.д.
Читал первое издание Programming in Scala — очень интересно, но язык достаточно сложный. Решил изучать Python вместо Scala.
Читал первое издание Programming in Scala — очень интересно, но язык достаточно сложный. Решил изучать Python вместо Scala.
Мне сложно сказать, правда ли это, потому что я много лет программировал на Java. Но, знаю, что в Scala приходят и из динамических языков (например, Twitter, насколько мне известно, изначально был весь на Ruby&Rails, а потом большие куски серверной части были переписаны на Scala).
Я думаю, тут сложно не столько в наследии Java, сколько в том, что объединены 1) мощная статическая типизация 2) объектно ориентированное программирование 3) функциональное программирование. Поэтому, вполне возможно, Python для начала будет удобнее.
Кстати, второе издание книги, по-моему, заметно лучше первого.
Я думаю, тут сложно не столько в наследии Java, сколько в том, что объединены 1) мощная статическая типизация 2) объектно ориентированное программирование 3) функциональное программирование. Поэтому, вполне возможно, Python для начала будет удобнее.
Кстати, второе издание книги, по-моему, заметно лучше первого.
Но, знаю, что в Scala приходят и из динамических языков (например, Twitter, насколько мне известно, изначально был весь на Ruby&Rails, а потом большие куски серверной части были переписаны на Scala).Я не исключаю, что в Twitter специально нанимали спецов по Scala для написания бэкенда.
А вот Foursquare с PHP перешли сами, что для меня действительно на грани фантастики звучит. Не знаю, по-моему, такой переход делать очень тяжело.
Кстати, второе издание книги, по-моему, заметно лучше первого.Ок, может хоть теперь дочитаю. Книга даже без практического изучения языка интересна для осваивания новых приемов и тенденций в программировании. Недаром Scala грант Евросоюза получила.
А вот Foursquare с PHP перешли сами, что для меня действительно на грани фантастики звучит. Не знаю, по-моему, такой переход делать очень тяжело.
Да, звучит на грани фантастики, С-подобный стиль очень отличается от скала. Но это чертовски приятный переход, со временем пхп становится мало, мешает его деревянность. Хочется, так сказать, перейти на уровень выше. По немногу пробовал питон, джава, груви, но в итоге остановился на скала :)
Нужно просто спросить у себя: «А может ли пхп быть лучше и гибче?». Если ответ положительный, то можно пробовать. Если же пхп хватает с головой — то переход будет очень трудным.
UFO just landed and posted this here
Sign up to leave a comment.
Lift: самый мощный и безопасный веб фреймворк из всех?