Здравствуйте, <Аноним>, Вы писали:

WH>>Этот пример не работает.
А>Работает
Теперь и у меня заработал.

не понравилось что много кода

Здравствуйте, Аноним, Вы писали:

А>не понравилось что много кода
В смысле много? (много кода не бывает, бывает наоборот мало и глючного).
Есть идеи как сделать короче?

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

I>Уже почти доделана поддержка встраевамых шаблонов.

Что значит "встраиваемых"?

I>Как только будет более менее окончательный вариант, то можно будет написать небольшую статью-описание.

Это дело.

ЗЫ

Было бы здорово подумать над процессом создания вьюх и контролов. Под контролами я понимаю некие повторно испоьзуемые вьюхи которые могут использоваться как отдельные элементы управления.

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

I>Добавил показ исходников и дописал движок представлений. Теперь весь рендеринг статически типизирован. (пока кроме options)
I>http://user1663.netfx45lab.discountasp.net/

Исходники лучше показывать через prettify, там есть немерловая раскраска.

Здравствуйте, Аноним, Вы писали:

А>не понравилось что много кода
Что конкретно каждется лишним? Там много ненужных юзингов, которые можно удалить хоть сегодня, также можно будет избавится от аттрибутов в угоду соглашениям. У вас есть ещё какие-то идеи?

Здравствуйте, Ziaw, Вы писали:
Z>Исходники лучше показывать через prettify, там есть немерловая раскраска.

Отлично, сегодня добавим.

Здравствуйте, VladD2, Вы писали:
VD>Что значит "встраиваемых"?
Наверное слово "встраивамый" здесь лишнее. Это обыкновенные шаблоны привязанные к моделям.
Сейчас это выглядит так:

[JsModel]
public class SeatReservation 
{
    public Name : string { get; set; }
    public Meal : Meal { get; set; }
    public Root : ListsAndCollectionsViewModel { get; set; }
    
    [Html]
    public EditTemplate() : string {
        <#
            <div>
                <td><input value="$(Name)" /></td>
                <td><select options="$(Root.AvailableMeals)" data-bind="value: Meal" data-bind="optionsText: MealName"></select></td>
                <td>$(FormattedPrice)</td>
                <td><a href="#" click="$(Root.RemoveSeat)">Remove</a></td>
            </div>
        #>
    }
      
}

[ViewModel]
public partial class ListsAndCollectionsViewModel
{   
    ....
    
    public Seats          : List[SeatReservation] { get; set; }      

    [Html]
    public View() : string {
        <#  <div>
                <h2>Your seat reservations (<span>$(Seats.Count())</span>)</h2>
                <div $(Template(Seats, _.EditTemplate))></div>
            </div> #>
    }
}

VD>Было бы здорово подумать над процессом создания вьюх и контролов. Под контролами я понимаю некие повторно испоьзуемые вьюхи которые могут использоваться как отдельные элементы управления.
В принципе шаблоны должны решать эту задачу, ведь никто не мешает шарить их между разными MVVM страницами.
Можно, например, сделать модель содержащюю только шаблон, без данных. А можно сделать модель TextBox и хранить в поле Value текущее значение. Правда его придётся доставать оттуда перед сохранением на сервер, но это небольшая проблема.

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

I>Что конкретно каждется лишним? Там много ненужных юзингов, которые можно удалить хоть сегодня, также можно будет избавится от аттрибутов в угоду соглашениям. У вас есть ещё какие-то идеи?

view model Introduction
{
    FirstName     : string;//Свойства которые можно читать/писать.
    LastName      : string;//Система автоматом отслеживает их изменения.
    FullName      : string { FirstName + " " + LastName } //Вычислимое свойство. Можно только читать.
    //Обновляется автоматически при изменении любого из значений от которого зависит.

    CapitalizeLastName() : void
    {
        LastName = LastName.ToUpper();
    }
}

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

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

I>>Что конкретно каждется лишним? Там много ненужных юзингов, которые можно удалить хоть сегодня, также можно будет избавится от аттрибутов в угоду соглашениям. У вас есть ещё какие-то идеи?

view model Introduction
{
    FirstName     : string;//Свойства которые можно читать/писать.
    LastName      : string;//Система автоматом отслеживает их изменения.
    FullName      : string { FirstName + " " + LastName } //Вычислимое свойство. Можно только читать.
    //Обновляется автоматически при изменении любого из значений от которого зависит.

    CapitalizeLastName() : void
    {
        LastName = LastName.ToUpper();
    }
}

Думаю тут лучше будет

property FirstName: string;
server FirstName: string;
client FirstName: string;

потому что часть значений не должна ходить между сервером и клиентом

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

I>>Что конкретно каждется лишним? Там много ненужных юзингов, которые можно удалить хоть сегодня, также можно будет избавится от аттрибутов в угоду соглашениям. У вас есть ещё какие-то идеи?
WH>

WH>view model Introduction
WH>{
WH>    FirstName     : string;//Свойства которые можно читать/писать.
WH>    LastName      : string;//Система автоматом отслеживает их изменения.
WH>    FullName      : string { FirstName + " " + LastName } //Вычислимое свойство. Можно только читать.
WH>    //Обновляется автоматически при изменении любого из значений от которого зависит.

WH>    CapitalizeLastName() : void
WH>    {
WH>        LastName = LastName.ToUpper();
WH>    }
WH>}
WH>

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

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

I>Что конкретно каждется лишним? Там много ненужных юзингов, которые можно удалить хоть сегодня, также можно будет избавится от аттрибутов в угоду соглашениям. У вас есть ещё какие-то идеи?

Небери в голову. Это какой-то "доброжелатель". В суть не въехал, а настроение плохое сутра.

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

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

I>>Что конкретно каждется лишним? Там много ненужных юзингов, которые можно удалить хоть сегодня, также можно будет избавится от аттрибутов в угоду соглашениям. У вас есть ещё какие-то идеи?
WH>

WH>view model Introduction
WH>{
WH>    FirstName     : string;//Свойства которые можно читать/писать.
WH>    LastName      : string;//Система автоматом отслеживает их изменения.
WH>    FullName      : string { FirstName + " " + LastName } //Вычислимое свойство. Можно только читать.
WH>    //Обновляется автоматически при изменении любого из значений от которого зависит.

WH>    CapitalizeLastName() : void
WH>    {
WH>        LastName = LastName.ToUpper();
WH>    }
WH>}
WH>

Хм, ну за исколючением небольших деталей так оно и есть.
Свойство — observable значение
Свойство, где объявлен только get — вычисляемый observable
Поле — обычное значение, которое не отслеживает изменений

Замена class на view model конечно не помешала бы, но для этого слишком много городить надо.

Здравствуйте, Аноним, Вы писали:

А>Думаю тут лучше будет
А>

А>property FirstName: string;
А>server FirstName: string;
А>client FirstName: string;
А>

А>потому что часть значений не должна ходить между сервером и клиентом

Ты не забыл, что код то на немерле?

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

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

Ну, можно и по проще. Только ради чего?

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

I>Здравствуйте, VladD2, Вы писали:
VD>>Что значит "встраиваемых"?
I>Наверное слово "встраивамый" здесь лишнее. Это обыкновенные шаблоны привязанные к моделям.

Вот привязка к модели — это, на мой взгляд, не очень правильно.

I>Сейчас это выглядит так:

I>[JsModel]
I>public class SeatReservation 
I>{
I>    public Name : string { get; set; }
I>    public Meal : Meal { get; set; }
I>    public Root : ListsAndCollectionsViewModel { get; set; }
    
I>    [Html]
I>    public EditTemplate() : string {
I>        <#
I>            <div>
I>                <td><input value="$(Name)" /></td>
I>                <td><select options="$(Root.AvailableMeals)" data-bind="value: Meal" data-bind="optionsText: MealName"></select></td>
I>                <td>$(FormattedPrice)</td>
I>                <td><a href="#" click="$(Root.RemoveSeat)">Remove</a></td>
I>            </div>
I>        #>
I>    }      
I>}

Это что-то вроде контрола?

I>[ViewModel]
I>public partial class ListsAndCollectionsViewModel
I>{   
I>    ....
    
I>    public Seats          : List[SeatReservation] { get; set; }      

I>    [Html]
I>    public View() : string {
I>        <#  <div>
I>                <h2>Your seat reservations (<span>$(Seats.Count())</span>)</h2>
I>                <div $(Template(Seats, _.EditTemplate))></div>
I>            </div> #>
I>    }
I>}
I>

Как-то вложенность представления в модель представления выглядит странно. Пока не могу сказать плохо ли это. Но решение неожиданное, как минимум.

I>В принципе шаблоны должны решать эту задачу, ведь никто не мешает шарить их между разными MVVM страницами.
I>Можно, например, сделать модель содержащюю только шаблон, без данных. А можно сделать модель TextBox и хранить в поле Value текущее значение. Правда его придётся доставать оттуда перед сохранением на сервер, но это небольшая проблема.

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

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

VD>Не бери в голову. Это какой-то "доброжелатель". В суть не въехал, а настроение плохое с утра.
В суть въехал. Очень понравилось. Но кода на мой взгляд должно быть раза в 2 меньше. Код==токен.
Мои возражения не по сути, а по дизайну текста. Использовать ключевое слово класс не есть красиво.

Здравствуйте, VladD2, Вы писали:
VD>Вот привязка к модели — это, на мой взгляд, не очень правильно.
Как я ни думал, всё равно получалось, что представление без модели это скорее исключение чем правило.
Далее может возникнуть вопрос, а что если для рендеринга нужно несколько моделей. Так это и сейчас, на серверной стороне реализуется через viewmodel.
Грубо говоря должны быть View и View[T]. Оба этих варианта реализуются через шаблоны в моделях.

VD>Это что-то вроде контрола?
Типичный сценарий:
Есть модель User, для неё создаётся контроллер и представления для каждого из действий.
А у нас получается, что все представления User'а являются его методами. Пока я не нашёл отрицательных сторон у этого решения.

VD>Как-то вложенность представления в модель представления выглядит странно. Пока не могу сказать плохо ли это. Но решение неожиданное, как минимум.
Согласен, что выглядит немного необычно. Но, мне кажется, это должно быть очень удобно.

VD>Я тут имею в виду, что в таких контролах может быть произвольный код превращающийся в произвольный жабаскрипт.
Оно так и есть, если хочешь, добавляй метод и вперёд, пиши произвольный код, точно так же как в основной ViewModel.

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

I>Есть модель User, для неё создаётся контроллер и представления для каждого из действий.
I>А у нас получается, что все представления User'а являются его методами. Пока я не нашёл отрицательных сторон у этого решения.

Такой дизайн препятствует раздельной компиляции представлений. Не находишь?

VD>>Я тут имею в виду, что в таких контролах может быть произвольный код превращающийся в произвольный жабаскрипт.
I>Оно так и есть, если хочешь, добавляй метод и вперёд, пиши произвольный код, точно так же как в основной ViewModel.

ОК. Это здорово!

Остается только вопрос что такое "js" (в коде примеров) и зачем оно надо?

Здравствуйте, VladD2, Вы писали:
VD>Такой дизайн препятствует раздельной компиляции представлений. Не находишь?
Насчёт раздельной компиляции надо будет ещё крепко подумать. Я думаю, что всё можно будет сделать и так, но это отдельная и довольно сложная задача.
В ASP.NET, кстати, неслабо приходится извращаться, чтобы раздельно компилировать. Оно только снаружи кажется простым.

VD>Остается только вопрос что такое "js" (в коде примеров) и зачем оно надо?
Мы ведь это уже обсуждали, это вставка произвольного Js кода. Повторно начинать спор не хочу, на данном этапе без Js в любом случае не обойтись.
Возможно, когда-то мы выйдем на такой уровень, где точно не понадобится писать javascript вручную, т.к. абсолютно все случаи будут покрыты фреймворком. Сейчас об этом рано думать.