Nemerle on Rails - Открытые проекты

Здравствуйте, AndrewVK, Вы писали:
AE>>Расскажи, как линк определит, какие поля мне дальше понадобятся?
AVK>По их использованию в самом запросе. Запросы в линке ленивые, и реально исполняются только когда ты
AVK>их начинаешь итерировать или сворачиваешь в скаляр.
Если данные запроса все равно перепаковывать в объекты модели, то согласен,
во время перепаковки набор полей и определится.

Собственно предмета для спора нет, если вы делаете не аналог рельсов, а что-то иное.
Со своими принципами и идеями, то большинство моих вопросов снимается. А дальше — время рассудит, удачен окажется проект или нет.
Я бы пожелал вам удачи.

Ибо "больше фреймворков хороших и разных".

Здравствуйте, Alex EXO, Вы писали:

AE>Если данные запроса все равно перепаковывать в объекты модели, то согласен,

Зачем их туда перепаковывать? ad hoc запросы тем и характерны, что не выставлятся просто наружу, а используются для дальнейшей обработки. И вот тут то вся мощь линка и проявляется — я могу описать в ленивом виде хитрющий алгоритм, разворачивающийся в несколько экранов sql, при этом код остается пристойным, легко читаемым и полностью контроллируемым компилятором.

... << RSDN@Home 1.2.0 alpha 4 rev. 1469 on Windows 7 6.1.7600.0>>

Здравствуйте, VladD2, Вы писали:
VD>Мне кажется идея сформулирована весьма конкретно — создать аналог Руби на Рельсах, но на статически типизированном языке поддерживающем макросы.
Ребята утверждают иное. Ну да ладно — поспорить в хорошей компании конечно прикольно

но поддерживать беседу не смогу, ибо завтра отбываю "на кокосовые острова" и комп с собой не беру.

VD>Ты просто плохо разбираешься в возможностях линка. И вместо того чтобы углубиться в этот вопрос вносишь поспешные суждения.
Влад, я можно сказать в линке вообще не разбираюсь. Ну не писал я под винды, линк просто из любопытства глянул.
И обсуждался не линк и AR конкретно, а места в которых рельсы используют динамическое расширение классов.
И мой вопрос был — "чем вы это собираетесь заменять?"
В качестве примера мог быть взят не класс модели, а класс вьюхи (там в рельсах подобные фишки тоже есть).
Просто не классах вьюхи менее удобно демонстрировать, они скрыты.

VD>Ну, а в статьях по Грувийным Рельсам все соответствует действительности?
Грувийные рельсы идеологически гораздо более тривиальны. А последнее время, и практически имеют не много смысла.
Года полтора назад они имели ключевое свойство — работать под java-машиной и цеплять java-вский легаси код.
Хотя тормозили раза в 4-5 сильнее чем обычные рельсы.
Но примерно к осени прошлого года проект jRuby дорос то того, что под ним запустились рельсы.
И выяснилось, что с определенного уровня нагрузки его эффективность сравнивается с эффективностью обычного RoR (а потом, хоть и медленно, начинает опережать). Жавовский код из под jRuby тоже доступен. Так что Грувийные Рельсы меня последнее время мало интересуют.

VD>Как я понял, ты считаешь, что знаешь эти моменты.
Не все. Далеко не все.
Просто я в коде достаточно часто натыкаюсь на разные забаные моменты, которые все больше и больше складываются в некую систему.
Сейчас я пишу примерно 20-й крупный проект на рельсах (мелочь не считаю). И как-то я сел сравнить код своих первых проектов с нынешним... если первые были похожи на то, что показывают во всяких учебных роликах, то сейчас... как будто пишу на совсем другом фреймворке.
Но полностью я это пока не осмыслил...
Так сходу несколько отличий нынешних проектов от первых:
— Про разрекламированные scaffold я забыл где-то уже к третьему проекту. Они хорошо смотрятся в демонстрационных примерах, но в реальной работе либо их надо полностью переписывать, либо просто забыть.
— Не помню с какого именно проекта, но достаточно давно, мы перешли со стандартного шаблонизатора на Builder::XmlMarkup. А в helpers оказались не заготовки кусков html кода, а классы объектной модели интерфейса (опирающиеся на класс Builder).
— При работе с базой, практически все варианты запросов инкапсулированы в классах модели через named_scope. Весьма красивый механизм, но слабо документированный.
— Вынос валидации на уровень модели (который порой критикуют в форумах) оказался особо ценным при нескольких входах на модель (например, через интерфейс и через веб-сервисы). В результате на валидаторы у нас повешены не только тривиальные проверки заполнения полей, но и некоторые проверки, обеспечивающие целостность модели на уровне бизнес-логики.
Ну, это сходу, реально там отличий гораздо больше...

VD>Если ты можешь помочь с идеологии, то вперед! Родина тебе не забудет!

Свою идеологию фреймворка я пока не потяну. По крайней мере такого фреймворка, который понравился бы мне самому.

Ну и потом, хорошие фреймворки рождаются из личных задачь и потребностей. А .Net мне сейчас в работе не актуален.
Актуальны рельсы и Ocsigen. У рельсов и так превосходная команда архитекторов, что же касается Ocsigen-а... то поживем-увидим.

Здравствуйте, AndrewVK, Вы писали:
AE>>Если данные запроса все равно перепаковывать в объекты модели, то согласен,
AVK>Зачем их туда перепаковывать? ad hoc запросы тем и характерны, что не выставлятся просто наружу, а используются для дальнейшей обработки.
Мы сказали одно и то же разными словами. "обработка" <=> "перепаковка"

Здравствуйте, Ziaw, Вы писали:

Z>

Milestone 5. Немного магии.

Z>Здесь я хочу избавиться от классов viewmodel. Точнее сделать их невидимыми для программиста, их поля будут задаваться прямо в контролле макросами.

Z>

Z>def model = Views.Home.Model();
Z>model.par1 = 10;
Z>model.par2 = "welcome to nemerle on rails world";
Z>

Z>Не уверен пока, что это вообще возможно, но очень хочется.

Я бы наоборот начал с этого пункта. Это то, что уже сейчас реально упростило бы работу над mvc проектами.

И наверное определять структуру модели нужно по инициализации, а не по использованию, для чего инициализацию стоит выделить явно. Это позволило бы более строго контролировать структуру класса модели. Что то вроде ананимных типов, только видимых как минимум в пределах сборки.

Z>def model = new(par1 = 10, par2 = "welcome to nemerle on rails world");

При этом представление будет автоматически параметризовываться "анонимным" типом, который будет выводится по уже существующему соглашению mvc о наименованиях и расположении представлений.

Здравствуйте, Alex EXO, Вы писали:

AE>Мы сказали одно и то же разными словами. "обработка" <=> "перепаковка"

Ну вот для обработки анонимных типов достаточно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1469 on Windows 7 6.1.7600.0>>

Здравствуйте, Alex EXO, Вы писали:

AE>- Не помню с какого именно проекта, но достаточно давно, мы перешли со стандартного шаблонизатора на Builder::XmlMarkup. А в helpers оказались не заготовки кусков html кода, а классы объектной модели интерфейса (опирающиеся на класс Builder).

Можно по подробнее?

AE>- При работе с базой, практически все варианты запросов инкапсулированы в классах модели через named_scope. Весьма красивый механизм, но слабо документированный.

И об этом тоже по подробнее, если можно.

AE>- Вынос валидации на уровень модели (который порой критикуют в форумах) оказался особо ценным при нескольких входах на модель (например, через интерфейс и через веб-сервисы). В результате на валидаторы у нас повешены не только тривиальные проверки заполнения полей, но и некоторые проверки, обеспечивающие целостность модели на уровне бизнес-логики.

Согласен. А где предлагается делать валидацию в ином случае?

Здравствуйте, seregaa, Вы писали:

Z>>Здесь я хочу избавиться от классов viewmodel. Точнее сделать их невидимыми для программиста, их поля будут задаваться прямо в контролле макросами.

S>Я бы наоборот начал с этого пункта. Это то, что уже сейчас реально упростило бы работу над mvc проектами.

Присоединяйся. Я этот пункт в конец поставил в расчете на свои силы. К тому времени я буду лучше понимать возможности nemerle и мне будет проще задизайнить это. Правда для начала нужно все равно нужно уметь строго указывать какая view будет использоваться, это 3й мейлстоун.

S>И наверное определять структуру модели нужно по инициализации, а не по использованию, для чего инициализацию стоит выделить явно.

Возможно. Хотя это, имхо, затруднит использование из нескольких экшенов.

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

Здравствуйте, VladD2, Вы писали:
AE>>- Не помню с какого именно проекта, но достаточно давно, мы перешли со стандартного шаблонизатора на Builder::XmlMarkup. А в helpers оказались не заготовки кусков html кода, а классы объектной модели интерфейса (опирающиеся на класс Builder).
VD>Можно по подробнее?
Кусочек из экзампла:

  xm.instruct!                   # <?xml version="1.0" encoding="UTF-8"?>
  xm.html {                      # <html>
    xm.head {                    #   <head>
      xm.title("History")        #     <title>History</title>
    }                            #   </head>
    xm.body {                    #   <body>
      xm.comment! "HI"           #     <!-- HI -->
      xm.h1("Header")            #     <h1>Header</h1>
      xm.p("paragraph")          #     <p>paragraph</p>
    }                            #   </body>
  }

Это базовый класс. То, что от него можно пронаследоваться и добавить всякие menu, calendar, box и т.д. я думаю, поняно.
Builder::XmlMarkup присутствует в базовой поставке рельсов с самых первых версий. И в документации описан. Но вот в учебной литературе не упоминается.

AE>>- При работе с базой, практически все варианты запросов инкапсулированы в классах модели через named_scope. Весьма красивый механизм, но слабо документированный.
VD>И об этом тоже по подробнее, если можно.
named_scope добавлен в базовую поставку начиная с версии 2.0, до этого был доступен отдельно. В документации отсутствует, подробно документирован внутри исходника (named_scope.rb), и в сгенеренном по исходникам rubydoc.
Вот цитата из искходника (пардон, что длинная):

      # Adds a class method for retrieving and querying objects. A scope represents a narrowing of a database query,
      # such as <tt>:conditions => {:color => :red}, :select => 'shirts.*', :include => :washing_instructions</tt>.
      #
      #   class Shirt < ActiveRecord::Base
      #     named_scope :red, :conditions => {:color => 'red'}
      #     named_scope :dry_clean_only, :joins => :washing_instructions, :conditions => ['washing_instructions.dry_clean_only = ?', true]
      #   end
      # 
      # The above calls to <tt>named_scope</tt> define class methods <tt>Shirt.red</tt> and <tt>Shirt.dry_clean_only</tt>. <tt>Shirt.red</tt>, 
      # in effect, represents the query <tt>Shirt.find(:all, :conditions => {:color => 'red'})</tt>.
      #
      # Unlike Shirt.find(...), however, the object returned by <tt>Shirt.red</tt> is not an Array; it resembles the association object
      # constructed by a <tt>has_many</tt> declaration. For instance, you can invoke <tt>Shirt.red.find(:first)</tt>, <tt>Shirt.red.count</tt>,
      # <tt>Shirt.red.find(:all, :conditions => {:size => 'small'})</tt>. Also, just
      # as with the association objects, name scopes acts like an Array, implementing Enumerable; <tt>Shirt.red.each(&block)</tt>,
      # <tt>Shirt.red.first</tt>, and <tt>Shirt.red.inject(memo, &block)</tt> all behave as if Shirt.red really were an Array.
      #
      # These named scopes are composable. For instance, <tt>Shirt.red.dry_clean_only</tt> will produce all shirts that are both red and dry clean only.
      # Nested finds and calculations also work with these compositions: <tt>Shirt.red.dry_clean_only.count</tt> returns the number of garments
      # for which these criteria obtain. Similarly with <tt>Shirt.red.dry_clean_only.average(:thread_count)</tt>.
      #
      # All scopes are available as class methods on the ActiveRecord::Base descendent upon which the scopes were defined. But they are also available to
      # <tt>has_many</tt> associations. If,
      #
      #   class Person < ActiveRecord::Base
      #     has_many :shirts
      #   end
      #
      # then <tt>elton.shirts.red.dry_clean_only</tt> will return all of Elton's red, dry clean
      # only shirts.
      #
      # Named scopes can also be procedural.
      #
      #   class Shirt < ActiveRecord::Base
      #     named_scope :colored, lambda { |color|
      #       { :conditions => { :color => color } }
      #     }
      #   end
      #
      # In this example, <tt>Shirt.colored('puce')</tt> finds all puce shirts.
      #
      # Named scopes can also have extensions, just as with <tt>has_many</tt> declarations:
      #
      #   class Shirt < ActiveRecord::Base
      #     named_scope :red, :conditions => {:color => 'red'} do
      #       def dom_id
      #         'red_shirts'
      #       end
      #     end
      #   end
      #
      #
      # For testing complex named scopes, you can examine the scoping options using the
      # <tt>proxy_options</tt> method on the proxy itself.
      #
      #   class Shirt < ActiveRecord::Base
      #     named_scope :colored, lambda { |color|
      #       { :conditions => { :color => color } }
      #     }
      #   end
      #
      #   expected_options = { :conditions => { :colored => 'red' } }
      #   assert_equal expected_options, Shirt.colored('red').proxy_options

VD>Согласен. А где предлагается делать валидацию в ином случае?
Оппоненты утверждают, что в контроллерах...

Здравствуйте, Alex EXO, Вы писали:

AE>>>- Не помню с какого именно проекта, но достаточно давно, мы перешли со стандартного шаблонизатора на Builder::XmlMarkup. А в helpers оказались не заготовки кусков html кода, а классы объектной модели интерфейса (опирающиеся на класс Builder).
VD>>Можно по подробнее?
AE>Кусочек из экзампла:
AE>

AE>  xm.instruct!                   # <?xml version="1.0" encoding="UTF-8"?>
AE>  xm.html {                      # <html>
AE>    xm.head {                    #   <head>
AE>      xm.title("History")        #     <title>History</title>
AE>    }                            #   </head>
AE>    xm.body {                    #   <body>
AE>      xm.comment! "HI"           #     <!-- HI -->
AE>      xm.h1("Header")            #     <h1>Header</h1>
AE>      xm.p("paragraph")          #     <p>paragraph</p>
AE>    }                            #   </body>
AE>  }     
AE>

AE>Это базовый класс. То, что от него можно пронаследоваться и добавить всякие menu, calendar, box и т.д. я думаю, поняно.
AE>Builder::XmlMarkup присутствует в базовой поставке рельсов с самых первых версий. И в документации описан. Но вот в учебной литературе не упоминается.

А что это даeт? Какие плюсы по сравнению с:

<?xml version="1.0" encoding="UTF-8"?>
<html>
<head>
  <title>History</title>
</head>
<body>
  <!-- HI -->
  <h1>Header</h1>
  <p>paragraph</p>
  <menu />
  <calendar select="${DateTime.Now}" />
  <box>
    some inner content
  </box>
</body>

(spark view engine)

AE>Оппоненты утверждают, что в контроллерах...
Цитатку можно?

Я, например, считаю, что в разных случаях по разному. Но точно не в классе данных.

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

Здравствуйте, Ziaw, Вы писали:
Z>А что это даeт? Какие плюсы по сравнению с:
Позволяет думать в терминах осмысленных объектов, а не в терминах html-разметки.
Разумеется, вариант не подходит, если верстку делает отдельный человек, знающий толко html.
Но при разработке приложений (а не сайтов) за интерфейс зачастую отвечают программисты.

AE>>Оппоненты утверждают, что в контроллерах...
Z>Цитатку можно?

Цитатку из чего? Из споров в рубевых эхах? Извини, не буду искать...

Z>Я, например, считаю, что в разных случаях по разному. Но точно не в классе данных.
Ну вот. А на мой взгляд, модель определяет "набор допустимых операций над множеством прикладных сущностей", и о логической целостности и непротиворечивости модель должна уметь позаботиться сама. Так что лично я, вполне доволен тем, куда авторы рельсов поместили валидаторы.

Здравствуйте, Alex EXO, Вы писали:

AE>Здравствуйте, Ziaw, Вы писали:
Z>>А что это даeт? Какие плюсы по сравнению с:
AE>Позволяет думать в терминах осмысленных объектов, а не в терминах html-разметки.
AE>Разумеется, вариант не подходит, если верстку делает отдельный человек, знающий толко html.
AE>Но при разработке приложений (а не сайтов) за интерфейс зачастую отвечают программисты.

Для jscript тоже придумали тулзу, чтобы думать о тексте на нем в терминах осмысленных объектов?

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

Здравствуйте, Ziaw, Вы писали:
Z>Для jscript тоже придумали тулзу, чтобы думать о тексте на нем в терминах осмысленных объектов?
А то... Если я кидаю на форму объект calendar, то естественно он с инкапсулированным jscript.
Как же иначе... (общий jscript-код в библиотеке, а настроечное замыкание — в контроле)

Здравствуйте, Alex EXO, Вы писали:

AE>Здравствуйте, Ziaw, Вы писали:
Z>>Для jscript тоже придумали тулзу, чтобы думать о тексте на нем в терминах осмысленных объектов?
AE>А то... Если я кидаю на форму объект calendar, то естественно он с инкапсулированным jscript.
AE>Как же иначе... (общий jscript-код в библиотеке, а настроечное замыкание — в контроле)

Ты не понял. Вот мне надо на странице написать свой jscript. Как я это буду делать это в XML?

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

Здравствуйте, Ziaw, Вы писали:
Z>Ты не понял. Вот мне надо на странице написать свой jscript. Как я это буду делать это в XML?
page.jscode("var x= ....")
В чем проблема?

Здравствуйте, Alex EXO, Вы писали:

AE>Здравствуйте, Ziaw, Вы писали:
Z>>Ты не понял. Вот мне надо на странице написать свой jscript. Как я это буду делать это в XML?
AE>page.jscode("var x= ....")
AE>В чем проблема?

В том, что это не строка, а код. В котором хотелось бы иметь форматирование, хайлайтинг и автокомплишен. Который можно было бы дебажить.

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

Здравствуйте, Alex EXO, Вы писали:

AE>Здравствуйте, Ziaw, Вы писали:
Z>>Ты не понял. Вот мне надо на странице написать свой jscript. Как я это буду делать это в XML?
AE>page.jscode("var x= ....")
AE>В чем проблема?

Кстати, если я сделаю 5 таких однострочных вызовов, они все будут в тегах <script>?

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

Здравствуйте, Ziaw, Вы писали:
Z>В том, что это не строка, а код. В котором хотелось бы иметь форматирование, хайлайтинг и автокомплишен. Который можно было бы дебажить.
Большой код я бы вынес в *.js файл. И удобнее, и кешироваться будет.
Но если уж упереться, то в Ruby есть форматированная запись строки (и даже несколько форматов).
И вставлять этот текст через

<script type="text/javascript">
//<![CDATA[
...
//]]>
</script>

Тоже без проблем:

def jscode(js)
  self.script(:type=>"text/javascript") { self<<"\n//<![CDATA[\n"; self<<js; self<<"\n//]]>\n" }
end

Но вообще-то разговор какой-то странныq. Я так и не могу понять, что ты хочешь...
Писать на RoR? Тогда начинать стоит с документации...
Делать аналог Builder::XmlMarkup на Немерле? Тогда какая разница как у нас реализован тот или иной хелпер?
(И все равно начинать нужно будет с документации.)

Здравствуйте, Alex EXO, Вы писали:

AE>Но вообще-то разговор какой-то странныq. Я так и не могу понять, что ты хочешь...
AE>Писать на RoR? Тогда начинать стоит с документации...
AE>Делать аналог Builder::XmlMarkup на Немерле? Тогда какая разница как у нас реализован тот или иной хелпер?
AE>(И все равно начинать нужно будет с документации.)

Для начала я хочу понять, зачем вообще нужен XmlMarkup. Пока не понял.

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

Здравствуйте, Ziaw, Вы писали:
Z>Для начала я хочу понять, зачем вообще нужен XmlMarkup. Пока не понял.
А мне, честно говоря, не понятно зачем доказывать его нужность. Что мне с того? Омар на блюде или икру на хлеб?
Изначально, Влад спросил к чему мы пришли за время использования рельсов — я ответил.

От:	Alex EXO	http://aleksandr-zubarev.moikrug.ru/
Дата:	09.04.10 15:52
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	09.04.10 16:06
Оценка:

От:	Alex EXO	http://aleksandr-zubarev.moikrug.ru/
Дата:	09.04.10 16:47
Оценка:	6 (1)

От:	Alex EXO	http://aleksandr-zubarev.moikrug.ru/
Дата:	09.04.10 16:50
Оценка:

От:	seregaa	http://blogtani.ru
Дата:	09.04.10 18:41
Оценка:

От:	VladD2	www.nemerle.org
Дата:	09.04.10 20:22
Оценка:

	От:	Ziaw
	Дата:	10.04.10 01:08
	Оценка:

	От:	Ziaw
	Дата:	10.04.10 06:39
	Оценка:

	От:	Ziaw
	Дата:	10.04.10 06:58
	Оценка:

	От:	Ziaw
	Дата:	10.04.10 07:11
	Оценка: