Pull to refresh

Comments 67

Хм, заинтересовало. я вообще в Django работаю и еще с универских времен терпеть не могу Java. Стоит попытаться поковырять?
Простейшие примеры запускаются и понимаются очень легко. Но когда дело доходит до каких-то нетривиальностей — можно понадобится знание Scala и функциональщины.
Выглядит очень интересно. Обязательно попробую.
А вы не пробовали Circumflex?
Было бы интересно мнение человека, который хорошо владеет лифтом.
Сайт читал какое-то время назад, определённо положительное впечатление осталось, но времени попробовать не было.
На меня, честно говоря (я тока доки читал) он произвел куда более позитивное впечатление. А уж их ORM вообще выше всяких похвал.
А меня, если честно, их орм очень испугал. Идея крута, впрочем как и имплементация, но как представлю такое в коде писать — плохо становится почему-то :)
Мне кажется, что с таким подходом с этим ормом может разобраться любой человек, который знает SQL. ))
UFO just landed and posted this here
Насторожило: «шаблоны Lift — валидный 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). Получится вызов функции с параметрами. Эта функция может вызывать шаблон, подставлять в него параметры, возвращать результат.
Циклы и условия делаются лучше, чем в если бы они были в шаблонах :) Например, так:
"#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 верстки вставлять начнет?
Вы не так всё поняли, возможно, стоит прочитать ещё раз и разобраться получше. No offense.
Так. Я перечитал еще раз. В Lift шаблонах нет логики. Некоторые куски HTML находятся в исходном коде приложения. Чтобы переверстать/доработать HTML сайта нужно переделать HTML шаблоны и HTML куски в исходном коде.

Так что, не все лучшее они почерпнули, не все… и шаблоны дизайнерам дружественные только из-за того что туда не включили циклы и условия, спорно…

Вот сниппеты — круто. Не спорю.
В Lift практически нет каких-то прибитых гвоздями частей, всё можно подменять. В том числе и template engine. Если кому-то нужна логика в шаблонах, в дистрибутив входит модуль интеграции со Scalate
Меня смущает в lift'е, что они в шаблонах пошли по какому то java way, а не ror/django/asp.net (да да, не закидывайте помидорами).
Я имею ввиду, когда в шаблоне мы работаем с view model и инлайним (например, через @Model.Property) значения прямо в шаблон. Насколько я понял (честное слово, с lift не работал), в lift'е надо писать свой снипет, который будет возвращать значение из модели, и потом этот снипет вставлять в шаблон, и указывать теги, в которые он будет замещать. Как то разрывается логика представления и чтобы понять как шаблон будет выглядеть при рендеринге надо скакать от шаблона в класс снипета и обратно.
Я не совсем понимаю, о чём речь. Мне сейчас, чтобы «понять, как шаблон будет выглядеть» надо просто открыть этот .html файл в браузере. Там, конечно, не появятся данные из базы и не будут работать кнопки, но в остальном всё выглядит один в один.
А если в шаблоне есть условия? Как быть с false ветками? И вообще когда есть шаблон все намного понятней. Еще момент если возможность пользоваться генераторами типа .haml, .sass и т.д.?
В Lift шаблонах нет логики. Я не знаю, как с этим быть тому, кто привык, наверное, попробовать и понять, подходит ли это ему или нет. Или вообще не пробовать.

Всем, чем можно пользоваться из Java, можно пользоваться в Lift.
Да, написал кашу. Я имею ввиду, как и ivolodin, что в шаблонах нельзя иметь код. А рендерингом участов занимаются снипеты, которые возврощают html. В этом конечно есть и свои плюсы, начиная от большей тестопригодности, pure реализацией шаблона и т.д. Просто когда приходишь из мира, где в шаблонах происходит почти весь рендеринг (конечно, в шаблонах не должно быть взаимодействия с базой или логикой, только исключительно рендеринг модели), это немного вводит в ступор.
Да, я уже говорил, что мне понадобилось несколько заходов, чтобы понять, в чём фишка. Но сейчас чувствую себя вполне комфортно и в целом всё устраивает. В том числе и то, что шаблоны — это html страницы.

Опять же, можно спокойно пользоваться другими temlpate engine-ами, если не ошибаюсь, поддержка Scalate (в котором бывает код в шаблонах, опять же, если не ошибаюсь) поставляется с дистрибутивом.
А что двигало Вами? Т.е. обычно если с первого раза не зацепит больше не возвращаешься к этому, а тут 3 попытки)
Во-первых, я постоянно читаю твиттеры, группы и т.п. о Scala и там, так или иначе, постоянно упоминается Lift и новости о нём. А он развивается достаточно быстро и появляются интересные возможности, которые интересно попробовать.
Во-вторых, именно сам факт, что Lift сильно не похож на всё, с чем я привык работать в Java меня сильно притягивал — для расширения кругозора и выхода на более высокий уровень, с которого можно пересмотреть свои старые знания (я этот эффект ещё раньше, со Scala хорошо почувствовал и оценил).
В-третьих, попался удобный проект — с неким подобием веб-чата и кучей интерактивности на ajax. Решил попробовать на Lift, хорошо пошло, втянулся, делаю :)
А какой логики вам не хватает в шаблонах? циклы и условия легко заменяются сниппетами, причем представление итерации остается в шаблоне и легко меняется. Хтмл очень редко генерится в коде, это либо какие-нить простые элементы (SHtml.text, SHtml.submit, Text, SHtml.ajaxButton), либо небольшие куски шаблона, которые проще держать в коде (например для виджетов).
Естественно, стиль очень непривычный, особенно после классических MVC, мне кажется я до сих пор не привык. Но я от него тащусь :) Особенно от интеграции жс и аякса в фреймворке.
Ну вот конкретный пример — надо сделать страницу профиля. Есть UserViewModel с полями типа имя, пароль, email. В RoR/Ruby/Asp.Net MVC я просто делаю шаблон и фигачу туда @Model.Name, @Model.Email и т.д.
В 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

А может уже где-то и есть в последних версиях, если хорошо поискать :) Сейчас команда большая стала, много комитят.
спасибо! посмотрю. scala мне как раз нравится как язык, ибо actor почти в точь в точь взят из erlang'а (чего они и не отрицают). еще мне очень понравился github.com/scalatra/scalatra — думаю на нем делать restful API для одного из проектов.
К сожалению не знаком с шаблонами в РоР/асп.нет, но разве вфигачивание @Model.Name и прочих нельзя сравнить с добавлением бинд-тэгов (<model:name />) или селекторов на хтмл-элементы (<span class="name">name</span>), тем более оч часто селекторы уже присутсвуют? И ассайн переменных в контроллере с биндом в сниппетах? В итоге почти одно и тоже. Единственное, что соглашусь, в контроллере пришлось бы только модель зассайнить, а в сниппетах придется каждое поле. Но на фоне остальных преимуществ — это такая мелочь.
Бинд-тэги это очень похоже на RoR/Asp way — опять говорю, что подход Lift имеет место быть и насколько я знаю очень распространен в Java мире. Я вижу прямо с порога, что он дает более гранулированное тестирование шаблона, что является хорошим приемуществом.
При помощи SBT и JRebel цикл разработки (время между внесением изменений в код и обновлением в браузере) сокращается до нескольких секунд.



По опыту написания на Rails если отключен кеш моделей все происходит мгновенно.
Кто ж спорит, Rails на то и Rails чтобы всё происходило мгновенно :)
А мне Scala не понравилась. Беспредельный язык, как и руби. Хотя я бы хотел какой-то красивый питона со статической типизацией.
* хотел бы найти какой-то красивый язык вроде питона со статической типизацией.
Дело вкуса, я так Руби предпочел питону и никогда не жалел)

Хотя я бы хотел какой-то красивый питона со статической типизацией.


трудно представить…
А вы не представляйте, вы смотрите :)
www.python.org/~guido/static-typing/index.htm
Только зачем это?
Не могу понять эту идею, нужна скорость и типы, пиши расширения на Си или возьми другой язык.
Зачем пытаться одним языком покрывать все парадигмы и технологии!?
Я как понимаю код написанный с этой опции не совместим с традиционным кодом?
И где тогда красота!? В табуляциях что ли(
Все вопросы к Гвидо ван Россуму :) Но идея, как мы можем видеть, тогда так и осталась на этапе идеи (это слайды 2000 года)
Ну и славно) Не нужно значит было
На 10-м слайде простро страшный сон питониста, перешедшего с C++… )
Есть язык boo: boo.codehaus.org/
Синтаксис питона, типизация статическая. И всякие там еще плюшки.
Правда он под .net, не под JVM.
Не видел более или менее серьезных применений… не приживаются скриптовые языки на .NET и JVM. Плохо с нативными библиотеками. Хотя вот у jRuby 1.6.0 (по слухам) появилась способность работать с Си расширениями, может у питона под .NET или Java тоже такое есть…
Похоже офтоп творю) Сорри
Boo

Haskell — там похожий import и можно при желании отступами код группировать
Ну меня вообще не столько формат синтаксиса волнует (скобочки или отступы пофиг), как чистота языка, работа со списками, функциональные возможности. Ruby позволяет такие выкрутасы вытворять, что программа перестаёт вообще напоминать о том, что это ruby. Это грязный трюк, я считаю.

Хаскель — интересный вариант. Поиграюсь, спасибо!
Как может современный, статически типизированный, еще и научно-исследовательский яызык быть беспредельным.
А ну да) Если я не ошибаюсь у скалы компиляция в java-байткод, тогда конечно круто!
Scala очень красивый язык, обожаю его и пишу на нем диплом ;) Лифт обязательно попробую — есть пара идей, на которые пока нет времени.
Я тут встречал мнение, что с нулевым знанием Java в мире Scala делать нечего. Это правда? Просто мало того, что монструозный синтаксис Scala надо освоить, так еще всякие Java-классы, Maven и т.д.

Читал первое издание Programming in Scala — очень интересно, но язык достаточно сложный. Решил изучать Python вместо Scala.
Мне сложно сказать, правда ли это, потому что я много лет программировал на Java. Но, знаю, что в Scala приходят и из динамических языков (например, Twitter, насколько мне известно, изначально был весь на Ruby&Rails, а потом большие куски серверной части были переписаны на Scala).

Я думаю, тут сложно не столько в наследии Java, сколько в том, что объединены 1) мощная статическая типизация 2) объектно ориентированное программирование 3) функциональное программирование. Поэтому, вполне возможно, Python для начала будет удобнее.

Кстати, второе издание книги, по-моему, заметно лучше первого.
Но, знаю, что в Scala приходят и из динамических языков (например, Twitter, насколько мне известно, изначально был весь на Ruby&Rails, а потом большие куски серверной части были переписаны на Scala).
Я не исключаю, что в Twitter специально нанимали спецов по Scala для написания бэкенда.

А вот Foursquare с PHP перешли сами, что для меня действительно на грани фантастики звучит. Не знаю, по-моему, такой переход делать очень тяжело.
Кстати, второе издание книги, по-моему, заметно лучше первого.
Ок, может хоть теперь дочитаю. Книга даже без практического изучения языка интересна для осваивания новых приемов и тенденций в программировании. Недаром Scala грант Евросоюза получила.
А вот Foursquare с PHP перешли сами, что для меня действительно на грани фантастики звучит. Не знаю, по-моему, такой переход делать очень тяжело.

Да, звучит на грани фантастики, С-подобный стиль очень отличается от скала. Но это чертовски приятный переход, со временем пхп становится мало, мешает его деревянность. Хочется, так сказать, перейти на уровень выше. По немногу пробовал питон, джава, груви, но в итоге остановился на скала :)
Нужно просто спросить у себя: «А может ли пхп быть лучше и гибче?». Если ответ положительный, то можно пробовать. Если же пхп хватает с головой — то переход будет очень трудным.
UFO just landed and posted this here
Начинающим писать свои библиотеки на Scala не кошерно, пусть лучше эксперты пишут.

Rails на Ubuntu я могу в два счета установить, запустить и править (при том, что на самом деле мало с знаком с ROR). Со Scala как-то сложно все.
Со Scala сложно? Сложно установить в Ubuntu? Это значит распаковать архив со Scala и прописать к нему пути в PATH теперь стало невыносимо трудно? Я в шоке.
UFO just landed and posted this here
Мимо — через apt-get ставится maven, а этого уже более чем достаточно.
Only those users with full accounts are able to leave comments. Log in, please.

Articles