- Было дело позарился на идею с DataTable от МСУ, но сразу встал вопрос с обработками trygetmember, а учитывая что отдаешь DataSet то нужно учесть чтобы внутри темплейта дизайнер юзал не DataRow а свой класс с оверлоудами, ну и дальше походу уже видно что будет много трудностей.
- ExpandoObject интересен, в плане приближения к Json но он явно недоделанный. Нравится что это класс позволяющий строить легко дерево, правда не так легко как хотелось в сравнении c JS.
- Dynamic получается обычный Dictionary. на него тоже нужно повесить класс , но пока это самый простой способ, который какбы заработал сразу.

Плюс всего этого геморроя, это получения варианта аналогичного браузерным темплейтам. Вы даете пользователю Json данные, и даете HTML шаблон. Имея к примеру удобоваримую разметку типа jsRender/Mustach/ и др. Обычный пользователь вполне может быстро справиться расставив метки и циклы. В итоге получив дерево в Company -> Users , можно в теплейте выбирать как строить результат. Толи вывести только компании и кол-во юзверей в них, толи вывести в виде дерева, толи присабачить CCS3. В таком виде серверная часть отделена от дизайнеров, темплейты можно строить и менять не трогая генератор данных.
Минусом в таких вещах является то что вам приходится отдавать весь набор данных даже если нужен только 1 левел и всего пару полей. Но и это решаемо при желании, в своем старом проекте я анализировал, что будет использовано в форме или таблице, и только это отдавал из базы не дергая лишние LEFT JOIN.

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

Самое главное это то что все генерится на сервере. Было время когда все кинулись в Ajax сломя голову. Да эту всю задачу на Ajax построить нефиг делать. Даже вопросов не возникает. Но как только вопрос затрагивает отчеты и рассылку, становится все в тупик. У вас все выводилось в браузере аяксом, а тут нужно такоеже 1в1 отослать клиенту раз в сутки с сервера, начинаются чудеса с курлами и другими чудесами, дергать URl раз в сутки, и пошло поехало. Вот тут все и упирается в генерацию вывода всетаки на сервере. Комуто типа МСУ это все кажется бредом, но такой подход окупается. Причем это не выдумка сумашедшего, а есть уже готовая система которая лет 10 так работает. Задача просто из всего того что сейчас предлагают технологии, сделать с максимальным результатом.

МСУ Razor










Никаких моделей даже не нужно.

это линейный данные, т.е. одномерный, их явно не хватит для серьезного проекта. Чтобы отдать дерево придется @Viewdata['items'] приводить к какому то типу, и снова встанет вопрос валидации в темплейте при обращении к проперти без проверки. Тут уже как не крути понятно , что нужно писать свой класс сверху. Только вот смущает меня когда приходится брать чужеродное и сторонее типа elasticobject, когда смотришь на монстра expando с структурой и на него еще нужно навесить огромный кусок. тоже и с DataRow - без обработки его отдавать клиенту нельзя. А заставить самого клиента следить за синтаксисом в итоге убивает весь смысл проекта, потом еще придется писать свои дебагеры и отладчики, чтобы выдавать клиенту инфу удобоваримую.

skyANAПо теме.

Шаблон StringTemplate:

Модель:

На выходе:


у StringTemplate есть минус. это простые задачи. в случае множественных вложений, внешних блоков/макросов. сложной структуры.. это все будет очень трудным и вылезет в тормоза, все таки это регулярка строковая :( Мой текущий проект построен как раз на своем старом аналоге StringTemplate писанный в древности на с++. Как раз на с++ и перегоняли чтобы получить максимальную скорость, но когда проект сильно вырос, начались сложные темплейты.. все стало тормозить.. как ни старайся а обычная регулярка строковая даже в C# очень сильно тормозит. Недавно столкнулся с парсингом большого отчета в 3метра длинной. Что регулярка что реплейс выдали одинаково плачевные цифры.

Изопропил*Ihor*- ExpandoObject интересен, в плане приближения к Json но он явно недоделанный.
Правда на нём живёт цельный интернет эксплорер от майкрософт.
(точнее IDispatchEx, IExpando - RCW реализация обёртки)
ExpandoObject это основа Json.Net но не более того, пока что динамика в ASP.NET все еще не приветствуется. Ведь сам принцип .NET
это компиляция/оптимизация/кеширование кода, а с динамикой ему приходится постоянно работать с изменчевым кодом, что нарушает саму концепцию. Это сравнимо с Query в SQL Server, где за динамичные запросы бьют больно по рукам как за зло неимоверное. Вот и в .NET также.. я был удивлен что вообще появились такие вещи, а раз появились то подумалось что нужно это все както заюзать, но гложат смутные сомнения что оно еще не готово. Это типа как с HTML5 , вроде уже много лет как есть, но не доделанное какоето, и официально примут только в 2015 году а все уже его везде пропихивают со скрежетом.

я когда увидел в MSDN вариант кода в C#


был просто безумна рад, сразу кинулся опробовать.. и сходу нарвался на необъявленный проперти. Т.е. после объявления всунуть новый проперти уже фигушки.. user.address уже не вставить, покрайней мере простыми силами. Получается какойто не доеланный момент.. вроде все больше и больше вводят классики от javascript но оно еще в самом зародыше, и нету гарантии что будут доводить до конца. В итоге народ начинает сам лепить свои куски кода, облепливать сверху своими методами чтобы оно заработало хотябы в примитиве.

SeVaэто будет еще один топик, где нам будут рассказывать о том, что все плохо в net. И того нет, и это не предусмотрели.
Одним словом, тяжела и неказиста жизнь простого программиста
ну зачем так плачевно. было бы так все плохо, давно бы бросили :)
да и не было конкретики насчет "нету", просто MSDN документация предоставляет примитивы, и описание структуры и зачастую это не дает полное представление. теже примеры кода восновном касаются школьных курсов, или задач для студентов, но в реальной жизни нужно больше чем (if else). Вот тут и возникают моменты поиска истины :) или намеков. Недаром появляются десятки вариантов вокруг одного и тогоже. Все находятся в поиске. Тоже вот наблюдалось с Json. Совсем сторонние люди создавали, свои куски кода. Теперь вот сам .NET предлагает с коробки. Но по прежнему растут сторонние ветки и ведь не просто так.
Это же вот и с динамикой, не просто так ведь появились elastico и другие расширения. Но у меня складывается ощущение, что гдето чтото было упущено, вот в попытке найти суть или решение и создал топик :) ктож знал оно все так затянется. Хотя уже в трениях понял что нужно брать dynamic и сверху завернуть в свое обвертку. По крайней мере в таком варианте уже можно собрать то что хотелось, но явно по ходу еще вылезут проблемы.