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

VD>Смысл в настройках и доработках. Иначе вообще никакого смысл что-то генерировать?

VD>Тогда уж нужно просто иметь некие компоненты которые по делают морду по описанию. Но это ведь не скафолдинг?

В моем понимании это именно создание некого интерфейса по метаданным модели. Наверное этот интерфейс так же можно генерить не в рантайме а в редактируемый текст суть от этого особо не меняется, но смысла я в этом большого не вижу.

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

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

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

L>>Ассоциацию между чем и чем?

VD>Между именами полей и значениями лэйблов для разных языков.

Можно и отдельно, но тогда нужно отдельно позаботиться о том, чтобы при переименовании полей менялась и соответствующая ассоциация.

L>>Добавилось в сущность еще одно поле, опять генерим и опять вручную вносим изменения?

VD>Ну, такова суть рельсов. Если ничего не мерял, то можешь просто генерить.

В динамик дата — по другому.

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

VD>Тогда уж нужно просто иметь некие компоненты которые по делают морду по описанию. Но это ведь не скафолдинг?

Он и есть.

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

VD>>Тогда уж нужно просто иметь некие компоненты которые по делают морду по описанию. Но это ведь не скафолдинг?

L>Он и есть.

Что-то в статьях по Руби и Груви он описывается по другому.

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

L>>Он и есть.

VD>Что-то в статьях по Руби и Груви он описывается по другому.

Про груви не знаю, а в руби именно то, о чем я написал.

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

VD>Зачем строить асинхронную логику? Нужно просто иметь возможность отдать нужные данные. Асинхронным все станет само собой (так как страница будет запрашивать данные асинхронно).

Тогда я ничего не понял. Либо это схема WolfHound с хитрым фронтэндом, который собирает страницу из виртуальных кусков запрашивая их асинхронно либо то, что MVC умеет из коробки.

VD>Мы имеем простейшую REST-схему. Данные из БД => ИСД => рендеринг ХТМЛ-а или отправка данных на клинета через скрипты.

VD>Проще не куда. Дублироваться просто не чему.

В чем идея-то? Макро для генерации рест методов сделать для контроллера? Вобщем-то я собирался. В рельсах это resourses.

VD>А зачем для вьюхи? В общем, опиши это по подробнее. Лучше с примерами (на псевдокоде).

Допустим вьюха отображает список товаров в интернет магазине. Моделью для нее в текущем MVC будет List<Goods>. Потом в ней же понадобилось отобразить что-то еще, например название магазина. Надо либо создавать класс

[Record]
class GoodsViewModel
{
  [Accessor] def goods : list[Goods];
  [Accessor] def shopCaption : string;
}

вьюха будет иметь тип View<GoodsViewModel>
либо передавать название через нетипизированный хеш ViewData["ShopCaption"] = db.CurrentShop.Caption;

Я же хочу генерить такие классы по использованию. Псевдокод

def model = View.Current.Model(); // это указание для какой вьюхи мы будем генерить модель
model.ShopCaption = db.CurrentShop.Caption; // string
model.Goods = db.Goods.Where(g => g.Category == categoryId).Select(g => new (g.Name, g.Price)).ToList();

VD>Как данные могут служить контроллером и зачем?

Контейнером.

Z>> Для валидации в мвц уже много всего, пусть оно и занимается, надо только помочь слегка.

VD>Я не знаком с МВЦ, так что мне тяжело судить. Но если можно сделать лучше, то мне кажется, не нужно замыкаться на их реализацию.

Вот это зря. Получается, что ты много велосипедов изобретаешь. А я хочу просто решить проблемы вполне себе неплохого MVC.

Z>>Ок, давай конкретнее. Типичные задачи на клиенте:
Z>>[list]
Z>>

заменить контент в нужном месте DOM
Z>>

загрузить готовый контент в нужное место DOM

VD>В чем разница?
это делается так:

('#place').load('/product/10');

на сервере нет аналогов для этого действия просто потому, что это нафик не нужно.

VD>На мой взгляд разработчика нужно защитить от знаний DOM-а. Нужно создать некий абстрактный слой, назавем его плэйсхолдер, и дать людям удобный АПИ по замене содержимого этих плэйсхолдеров.

Бррр. Мне точно не нужно таких абстракций. Веб разработчик в любом случае знает DOM.

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

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

VD>1. Гонять данные между броузером и сервером в виде ХМЛ/Джейсон. Эту задачу решают предложенные мной ИСД (иерархические структуры данных) которые умеют автоматом серилизоваться и загружаться из ХМЛ и джейсон.

Да кроме экзоктики так все умеют сериализоваться. Я не понял что такое ИСД кто их будет создавать и их основное назначение.

VD>2. Наличие неких плэйсхолдеров в ДОМ-е и АПИ позволяющее заменять их контент.

Хорошо сделанный и отлично документированный jQuery.

VD>3. АПИ которое позволит нам быстро, просто и качественно преобразовать данные в формате ХМЛ/джейсон в ХТМЛ который будет подставляться в плэйсхолдеры.

VD>Третий пункт мало чем отличается от задач выполняемых на сервере. Для этой задачи на сервере ты предлагаешь использовать движок рендеринга аля СтрингТемплэйт. Ну, так почему бы не создать такой же движек работающий на клиенте?

Т.е. view engine на клиенте? Вероятно это может быть полезно в некоторых случаях, но в первую очередь надо максимально упростить генерацию порций html на сервере и запрашивать не джейсон а готовый хтмл.

Например кладем в папку вьюх файлик partials.spark, а там методы типа:

<def goodsRow row="Goods">
  <tr><td>$(row.Name)<td>$(row.Price)</tr>
</def>

Нужно только в рест вызове указать format=goodsRow и нам приедет готовый html вместо джейсона. Это позволит практически отказаться от генерации html на клиенте.

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

Z>Я же хочу генерить такие классы по использованию. Псевдокод
Z>

Z>def model = View.Current.Model(); // это указание для какой вьюхи мы будем генерить модель
Z>model.ShopCaption = db.CurrentShop.Caption; // string
Z>model.Goods = db.Goods.Where(g => g.Category == categoryId).Select(g => new (g.Name, g.Price)).ToList();
Z>

А если созданием модели занимается отдельный класс, его можно будет как то вернуть из метода?

Имхо, самый простой и гибкий вариант был бы что то типа статически типизированного ExpandoObject.
Явно определяем класс

class UserVM {}

var model = new UserVM();
model<-Test = "test";
model.Test //ok
model.Test1 // compile error

Может в Nemerle уже есть такая фича?

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

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

Z>>Я же хочу генерить такие классы по использованию. Псевдокод
Z>>

Z>>def model = View.Current.Model(); // это указание для какой вьюхи мы будем генерить модель
Z>>model.ShopCaption = db.CurrentShop.Caption; // string
Z>>model.Goods = db.Goods.Where(g => g.Category == categoryId).Select(g => new (g.Name, g.Price)).ToList();
Z>>

D>А если созданием модели занимается отдельный класс, его можно будет как то вернуть из метода?

А какая разница где это будет? Главное чтобы для вьюхи был сгенерирован класс модели. Наврядли удастся конечно сохранить такой именно синтаксис.

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

VD>1. Подобную функциональность нужно иметь не только для форм, но и вообщем.

Вобщем главное это удобный механизм получения метаданных.

VD>2. Нам нужно работать не с классами, а с их проекциями. Скажем если кто-то выполнил запрос и получил только список имен Person (в виде анонимного типа с одним полем), то чтобы если мы передадим этот список анонимных типов в такой генератор, чтобы он и таком случае сгенерировал проверки на клиенте. Для этого в запросах нужно копировать всю метаинформацию для возвращаемых полей.

VD>Собственно анонимных типов хватит только для простых случаев. Так что нужны те самые иерархические структуры данных (ИСД). В них так же должна копироваться метаинформация из полей модели.

Вот только я не очень представляю как это сделать. Путь данных лежит через сторонние библиотеки. Надо бы спросить IT, насколько реально протащить метаинформацию сквозь сложный linq запрос.

Но если это получится это будет реально киллер фичей. Так даже рельсы не умеют, афайк.

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

Z>Вот только я не очень представляю как это сделать. Путь данных лежит через сторонние библиотеки. Надо бы спросить IT, насколько реально протащить метаинформацию сквозь сложный linq запрос.

Линк реализован в нашех же макросах (смотри здесь). Так что, думаю, любые пробелмы можно будет решить.

Z>Но если это получится это будет реально киллер фичей. Так даже рельсы не умеют, афайк.

Ну, и хорошо.

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

VD>>Ну, такова суть рельсов. Если ничего не мерял, то можешь просто генерить.
D>А зачем тогда что то вообще генерить, думается мне что должна быть в рельсах поддержка генерации в рантайме.

Как я понял — это такой дизайн.

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

Z>Да кроме экзоктики так все умеют сериализоваться. Я не понял что такое ИСД кто их будет создавать и их основное назначение.

Кто все? Нам нужно конерктеные (свои) объекты сериализовать. А это нужно делать. Само собой ничего не произойдет.

VD>>2. Наличие неких плэйсхолдеров в ДОМ-е и АПИ позволяющее заменять их контент.

Z>Хорошо сделанный и отлично документированный jQuery.

jQuery — это скриптовая библиотека не имеющая отношения к нашей библиотеке. Понятно, что если будет нужно, то возьмут jQuery или еще что-то и сделают все вручную. Но хочется ведь по больше автоматики и декларативности. Хочется так, чтобы для большинства простых сценариев можно было бы отбойтись без jQuery.

Z>Т.е. view engine на клиенте?

Да.

Z>Вероятно это может быть полезно в некоторых случаях, но в первую очередь надо максимально упростить генерацию порций html на сервере и запрашивать не джейсон а готовый хтмл.

Не должно тут быть первой и второй очереди. Движок генерации XML/HTML должен быть удобен, быстр и доступен как на сервере, так и на клиенте. Причем лучше всего если клиентский код можно было бы заранее проеврить на наличие багов при компиляции серверной части.

Z>Например кладем в папку вьюх файлик partials.spark, а там методы типа:

Ну, спарк — это за маломощьностю и ореентацие на строки нужно сразу забывать. Нужно делать своей варинт на базе макросов. Вот он то и сможет сгенерировать как оптимальный код как для сервера, так и для клиента.

Z>

Z><def goodsRow row="Goods">
Z>  <tr><td>$(row.Name)<td>$(row.Price)</tr>
Z></def>
Z>

Z>Нужно только в рест вызове указать format=goodsRow и нам приедет готовый html вместо джейсона. Это позволит практически отказаться от генерации html на клиенте.

Вот это в корне не правильное суждение. Я бы даже сказал нарочито не верный дизайн!

Передавать лчше данные, а не верстку. Есть масса причин по которых не стоит всегда генерировать HTML с сервера.

Первая, и самая важная — это возможность использования возвращаемых сервером значений как REST-RPC (REST-подобные веб-сервисы).
Вторая — производительность и загрузка сети.
Третья — гибкость.
Четвертая — метаинформация. В данные мы можем добавить метаинформацию которую можно будет использовать для автоматическое генерации кода проверок на клиенте. В HTML же это будет более затруднительно.

Конечно мы всегда сможем сгенерить XML с помощью серверного движка рендеренга, но обрабатывать его на клиенте без наличия аналогичного клиентского движка будет мягко говоря неудобно.

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

Z>>Да кроме экзоктики так все умеют сериализоваться. Я не понял что такое ИСД кто их будет создавать и их основное назначение.

VD>Кто все? Нам нужно конерктеные (свои) объекты сериализовать. А это нужно делать. Само собой ничего не произойдет.

Все что должно идти в джейсон должно иметь довольно простую структуру. Эту простую структуру парсер сам разгрызет рефлекшеном.

VD>>>2. Наличие неких плэйсхолдеров в ДОМ-е и АПИ позволяющее заменять их контент.

Z>>Хорошо сделанный и отлично документированный jQuery.

VD>jQuery — это скриптовая библиотека не имеющая отношения к нашей библиотеке. Понятно, что если будет нужно, то возьмут jQuery или еще что-то и сделают все вручную. Но хочется ведь по больше автоматики и декларативности. Хочется так, чтобы для большинства простых сценариев можно было бы отбойтись без jQuery.

Однако она есть в стандартной поставке MVC, и ее активно используют все мвцшники.

VD>Не должно тут быть первой и второй очереди. Движок генерации XML/HTML должен быть удобен, быстр и доступен как на сервере, так и на клиенте. Причем лучше всего если клиентский код можно было бы заранее проеврить на наличие багов при компиляции серверной части.

Не бывает ничего без очереди. Что-то всегда делается раньше.

Z>>Например кладем в папку вьюх файлик partials.spark, а там методы типа:

VD>Ну, спарк — это за маломощьностю и ореентацие на строки нужно сразу забывать. Нужно делать своей варинт на базе макросов. Вот он то и сможет сгенерировать как оптимальный код как для сервера, так и для клиента.

Согласен. Правда не по причине маломощности спарка, а по причине многомощности макросов и лучшей поддержки студией

VD>Передавать лчше данные, а не верстку. Есть масса причин по которых не стоит всегда генерировать HTML с сервера.

Я же не отказываюсь от передачи данных.

VD>Первая, и самая важная — это возможность использования возвращаемых сервером значений как REST-RPC (REST-подобные веб-сервисы).

И? Это будет всего лишь один из форматов рест ответа, по умолчанию вернется json.

VD>Вторая — производительность и загрузка сети.

Не думаю, что это может стать узким местом, нет разницы сгенерировать json ответ или html. И кешироваться они будут абсолютно идентично. А вот гонять по сети библиотеку которая умеет рендерить как сервер придется, даже если этот рендер используется на одной странице.

VD>Третья — гибкость.

Гибкость чего?

VD>Четвертая — метаинформация. В данные мы можем добавить метаинформацию которую можно будет использовать для автоматическое генерации кода проверок на клиенте. В HTML же это будет более затруднительно.

И? Нужны будут данные — клиент возьмет данные. Без указания формата будет выдан дефолтный, для ajax запроса это будет json. Вот если по этим данным ему понадобится html, проще взять уже готовый html.

VD>Конечно мы всегда сможем сгенерить XML с помощью серверного движка рендеренга, но обрабатывать его на клиенте без наличия аналогичного клиентского движка будет мягко говоря неудобно.

А зачем XML? JSON прекрасно обрабатывается клиентом без какого либо движка.

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

Z>Все что должно идти в джейсон должно иметь довольно простую структуру. Эту простую структуру парсер сам разгрызет рефлекшеном.

Похоже ты меня не понимаешь. Я говорю о том, что мы должны сериализовать структуры данных существующие в процессе сервера. Скажем класс или вариант сам собой ни в ХМЛ ни в джейсон не запишется. Для этого нужно написать макру которая это сделает.

VD>>jQuery — это скриптовая библиотека не имеющая отношения к нашей библиотеке. Понятно, что если будет нужно, то возьмут jQuery или еще что-то и сделают все вручную. Но хочется ведь по больше автоматики и декларативности. Хочется так, чтобы для большинства простых сценариев можно было бы отбойтись без jQuery.

Z>Однако она есть в стандартной поставке MVC, и ее активно используют все мвцшники.

Ну, и что? Пусть будет. Ты хочешь чтобы твоей библиотекой было проще пользоваться?

VD>>Не должно тут быть первой и второй очереди. Движок генерации XML/HTML должен быть удобен, быстр и доступен как на сервере, так и на клиенте. Причем лучше всего если клиентский код можно было бы заранее проеврить на наличие багов при компиляции серверной части.

Z>Не бывает ничего без очереди. Что-то всегда делается раньше.

Очередность не важна если запланировано то что нужно. А вот если в процессе реализации на одну из фич забить, то будет плохо.

Z>Согласен. Правда не по причине маломощности спарка, а по причине многомощности макросов и лучшей поддержки студией

Нихай так . Хотя, уверен, что после реализации данной фичи ты согласишься с моим мнением.

Z>Я же не отказываюсь от передачи данных.

А чем их на клиенте в ХМТЛ превращать? jQuery-ем что ли?

VD>>Первая, и самая важная — это возможность использования возвращаемых сервером значений как REST-RPC (REST-подобные веб-сервисы).

Z>И? Это будет всего лишь один из форматов рест ответа, по умолчанию вернется json.

А зачем делать работу дважны? Не важно json или ХМЛ. Главное, чтобы не надо было еще вручную ХТМЛ-версию создавать.

json или ХМЛ должны отдаваться просто указанием некоторого параметра и в любом случае. А вот ХТМЛ только если это запланировал разработчик.

VD>>Вторая — производительность и загрузка сети.

Z>Не думаю, что это может стать узким местом, нет разницы сгенерировать json ответ или html. И кешироваться они будут абсолютно идентично.

А что тут думать то?
1. Объем передаваемых данных больше.
2. Нужно время на создание ХТМЛ-я (который еще может содержать сктипты и вообще быть рыхлым).

Z>А вот гонять по сети библиотеку которая умеет рендерить как сервер придется, даже если этот рендер используется на одной странице.

Библиотеки — это всего лишь текстовые файлы которые на раз кэшируются броузером, в отличии от динамического ХТМЛ-я. Код рендеринга у нас будет выглядеть очень компактно — это же ДСЛ! Так что ты опять не прав.

Но тут важны не какие-то отдельные причины, а сам факт не вреного дизайна ориентированного на постоянный рендеринг на сервере.

Только прикладной программист должен решать где рендерить ХТМЛ на сервере, или на клиенте. И его решение должно быть обусловлено исключительно соображениями прикладной логики, а не тем, что рендерить ХТМЛ на сервере проще чем на клиенте.

По этому надо иметь движок с одним АПИ который должен позволять рендерить код и так, и там. При этом код шаблонов должен быть одинаковым и декларативным.

VD>>Третья — гибкость.

Z>Гибкость чего?

См. выше.

VD>>Четвертая — метаинформация. В данные мы можем добавить метаинформацию которую можно будет использовать для автоматическое генерации кода проверок на клиенте. В HTML же это будет более затруднительно.

Z>И? Нужны будут данные — клиент возьмет данные. Без указания формата будет выдан дефолтный, для ajax запроса это будет json. Вот если по этим данным ему понадобится html, проще взять уже готовый html.

А как ты будешь json и ХМЛ генерировать? И как ты потом будешь по этому json-у формировать на клиенте ХМТЛ?
Надо думать на шаг (а то и на 10) вперед! Иначе по удобству твоя библиотека не сильно превзойдет оригинальный МВЦ.

VD>>Конечно мы всегда сможем сгенерить XML с помощью серверного движка рендеренга, но обрабатывать его на клиенте без наличия аналогичного клиентского движка будет мягко говоря неудобно.

Z>А зачем XML? JSON прекрасно обрабатывается клиентом без какого либо движка.

Да без разницы! XML и JSON — это не более чем формат передачи данных. Главено чтобы потом было чем их обработать. Наш движок (по крайней мере его клиентская версия) должен уметь на входе принять как ХМЛ, так и JSON. И то, и то можно рассматривать как ту самую ИСД.

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

Z>В чем идея-то? Макро для генерации рест методов сделать для контроллера? Вобщем-то я собирался. В рельсах это resourses.

И это тоже. Но главное — иметь четкую и простую логику.

1. Формируем ИСД (думаю, что это нечто похожее на твое ViewModel) с помощью запросов к БД и другим источникам данных.
2. Публикуем ее под некоторым URL. Уже на этом этапе имеем возможность запаивать данные в форматах ХМЛ и JSON.
3. (опционально) Формируем шаблон для преобразования нашей ИСД в ХТМЛ.
4. (опционально) Публикуем под тем же ЮРЛ (или другим) результат преоразования (ХТМЛ). Это позволяет открыть данный ЮРЛ напрямую в браузере.
5. (опционально) Публикуем под тем же ЮРЛ (или другим) сам шаблон. Это позволяет какому-то клиентскому коду получить данные (созданные в п. 2) и сгенерировать по ним ХМТЛ на клиенте (подставив его в некоторый плейсхолдер).

В итоге получаем красивую, простую и ясную схему разработки веб-прилоожения.

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

Z>>Все что должно идти в джейсон должно иметь довольно простую структуру. Эту простую структуру парсер сам разгрызет рефлекшеном.

VD>Похоже ты меня не понимаешь. Я говорю о том, что мы должны сериализовать структуры данных существующие в процессе сервера. Скажем класс или вариант сам собой ни в ХМЛ ни в джейсон не запишется. Для этого нужно написать макру которая это сделает.

Чем JsonConvert.SerializeObject(объект) хуже макры?

VD>>>jQuery — это скриптовая библиотека не имеющая отношения к нашей библиотеке. Понятно, что если будет нужно, то возьмут jQuery или еще что-то и сделают все вручную. Но хочется ведь по больше автоматики и декларативности. Хочется так, чтобы для большинства простых сценариев можно было бы отбойтись без jQuery.

Z>>Однако она есть в стандартной поставке MVC, и ее активно используют все мвцшники.

VD>Ну, и что? Пусть будет. Ты хочешь чтобы твоей библиотекой было проще пользоваться?

Расскажи про сценарии в которых можно заменить jQuery более удобной вещью, с примерами.

VD>Очередность не важна если запланировано то что нужно. А вот если в процессе реализации на одну из фич забить, то будет плохо.

Я не против запланировать рендер на клиенте, когда все остальное будет работать без нареканий.

Z>>Я же не отказываюсь от передачи данных.

VD>А чем их на клиенте в ХМТЛ превращать? jQuery-ем что ли?

А надо ли? Может они нужны именно в виде данных. Например задать значение готовым контролам.

VD>>>Первая, и самая важная — это возможность использования возвращаемых сервером значений как REST-RPC (REST-подобные веб-сервисы).

Z>>И? Это будет всего лишь один из форматов рест ответа, по умолчанию вернется json.

VD>А зачем делать работу дважны? Не важно json или ХМЛ. Главное, чтобы не надо было еще вручную ХТМЛ-версию создавать.

Почему дважды? Формировать придется один раз.

VD>json или ХМЛ должны отдаваться просто указанием некоторого параметра и в любом случае. А вот ХТМЛ только если это запланировал разработчик.

Z>>Не думаю, что это может стать узким местом, нет разницы сгенерировать json ответ или html. И кешироваться они будут абсолютно идентично.

VD>А что тут думать то?
VD>1. Объем передаваемых данных больше.

Примерно равен, может быть как больше так и меньше.

VD>2. Нужно время на создание ХТМЛ-я (который еще может содержать сктипты и вообще быть рыхлым).

Вот сравни практически идеальные по скорости конечные методы генерации html и json.

def json(product)
{
  $"{'Name':'$(jEscape(product.Name))','Price':$(jEscape(product.Price))}"; 
}
def html(product)
{
  $"<tr><td>$(hEscape(product.Name))<td>$(product.Price)</tr>"; 
}

Нужен лишь html который будет еще одним форматом представления продукта. Будет ли он рыхлым это выбор пользователя.

VD>Библиотеки — это всего лишь текстовые файлы которые на раз кэшируются броузером, в отличии от динамического ХТМЛ-я. Код рендеринга у нас будет выглядеть очень компактно — это же ДСЛ! Так что ты опять не прав.

Давай пример использования, пусть без деталей. Просто пример.

VD>Но тут важны не какие-то отдельные причины, а сам факт не вреного дизайна ориентированного на постоянный рендеринг на сервере.

VD>Только прикладной программист должен решать где рендерить ХТМЛ на сервере, или на клиенте. И его решение должно быть обусловлено исключительно соображениями прикладной логики, а не тем, что рендерить ХТМЛ на сервере проще чем на клиенте.

Тут ты прав, просто я уточнил, что рендер html на клиенте явление не столь частое и в большинстве случаев легко заменятся рендером на сервере. Поэтому и сомневаюсь, что игра стоит свеч, особенно если это начнет накладывать ограничения на удобство серверного рендера (типа эта фича не будет работать на клиенте, значит мы не будем вводить ее и на сервере).

VD>>>Конечно мы всегда сможем сгенерить XML с помощью серверного движка рендеренга, но обрабатывать его на клиенте без наличия аналогичного клиентского движка будет мягко говоря неудобно.

Z>>А зачем XML? JSON прекрасно обрабатывается клиентом без какого либо движка.

VD>Да без разницы! XML и JSON — это не более чем формат передачи данных. Главено чтобы потом было чем их обработать. Наш движок (по крайней мере его клиентская версия) должен уметь на входе принять как ХМЛ, так и JSON. И то, и то можно рассматривать как ту самую ИСД.

jScript умеет обрабатывать Java Script Object Notation, я не понимю зачем его учить обрабатывать еще и тормозной XML, если кому-то понадобится он возьмет готовую либу.

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

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

Z>>В чем идея-то? Макро для генерации рест методов сделать для контроллера? Вобщем-то я собирался. В рельсах это resourses.

VD>И это тоже. Но главное — иметь четкую и простую логику.

VD>1. Формируем ИСД (думаю, что это нечто похожее на твое ViewModel) с помощью запросов к БД и другим источникам данных.

Не, не похоже. Она должна использоваться в куче мест. Поэтому ее все же лучше описать руками или взять из базы. Моя ViewModel используется одной view. А формируется в одном или нескольких экшенах.

VD>2. Публикуем ее под некоторым URL. Уже на этом этапе имеем возможность запаивать данные в форматах ХМЛ и JSON.

Я планировал так — в контроллере пишем макрос который генерит рест методы для модели бд. Либо любой другой модели, но тогда придется прописать руками методы CRUD. Так делает макрос ресурсы в рор.

VD>3. (опционально) Формируем шаблон для преобразования нашей ИСД в ХТМЛ.
VD>4. (опционально) Публикуем под тем же ЮРЛ (или другим) результат преоразования (ХТМЛ). Это позволяет открыть данный ЮРЛ напрямую в браузере.
VD>5. (опционально) Публикуем под тем же ЮРЛ (или другим) сам шаблон. Это позволяет какому-то клиентскому коду получить данные (созданные в п. 2) и сгенерировать по ним ХМТЛ на клиенте (подставив его в некоторый плейсхолдер).

Ну да, оно все само получится, не надо будет ничего специально публиковать. Взгляни на рельсовский respond_to

VD>В итоге получаем красивую, простую и ясную схему разработки веб-прилоожения.
A la RoR. Что в общем-то и планируется.