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

<ul visible="Tasks().length > 0">
Это нормально? что присваивается текст напрямую?
последний пример больше не работает

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

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

Суть в том, что это код на типизированном языке. "class", "public" и т.п. — это его неотъемлемые элементы.

В принципе можно было бы создать чистый ДСЛ, но средствами Немерла это делать слишком сложно. Вот когда мы доделаем N2, то создавать подобные ДСЛ-и будет намного проще и можно будет немного разгрузить синтаксис. А пока что это встроенные ДСЛ-и.

Здравствуйте, Аноним, Вы писали:
А> <ul visible="Tasks().length > 0">
А>Это нормально? что присваивается текст напрямую?
Это пережитки прошлого, я просто не заметил.

А>последний пример больше не работает
Поправили.

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


<a href="#" click="$RemoveTask">Delete</a>
тут не понятно какое значение передаеться в RemoveTask

Здравствуйте, Аноним, Вы писали:
А><a href="#" click="$RemoveTask">Delete</a>
А>тут не понятно какое значение передаеться в RemoveTask

Это особенность KnockoutJS, если вызов внутри тела цикла, то передаётся текущий item.

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

I>Здравствуйте, Аноним, Вы писали:
А>><a href="#" click="$RemoveTask">Delete</a>
А>>тут не понятно какое значение передаеться в RemoveTask

I>Это особенность KnockoutJS, если вызов внутри тела цикла, то передаётся текущий item.

Если 2 вложенных цикла? в немерли может быть цикл с with и вообще куча извращений

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

А>Если 2 вложенных цикла? в немерли может быть цикл с with и вообще куча извращений

Теоретичски можно писать click="() => loopItem.Method(outerLoopItem)", но я это ещё не тестировал.
Все конструкции немерли в разметке повторять не нужно, достаточно основных выражений.

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

А>> <ul visible="Tasks().length > 0">
А>>Это нормально? что присваивается текст напрямую?
I>Это пережитки прошлого, я просто не заметил.

А где же контроль типов?

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

VD>А где же контроль типов?
А он так нужен? контроль типов явно не самое главное в жизни.

VD>>А где же контроль типов?
А>А он так нужен? контроль типов явно не самое главное в жизни.

Раньше все представления были сделаны в текстовом виде. Потом постепенно они были переведены на сплайсы.
Я же говорю, не заметил просто. Обновите страницу.

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

VD>>А где же контроль типов?
А>А он так нужен? контроль типов явно не самое главное в жизни.

Весь этот фрэймворк разрабатывается в основном для того чтобы иметь контроль типов во время компиляции. Если его нет, то нет и смысла в проекте.

Ну, а все кого контроль типов не интересуют могут смело переходить в форум посвященный скриптам. Здесь им делать не чего. Объяснять в 100501 раз преимущества статической типизации мне что-то в лом.

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

public this() {
  server.Load(tasks => {
    Tasks = tasks.ToList();
  });
}


public Load() : IEnumerable[Task]
{
  [
    Task() <- (Title = "Wire the money to Panama", IsDone = true, _destroy = false),
    Task() <- (Title = "Get hair dye, beard trimmer, dark glasses and \"passport\"", IsDone = false, _destroy = false),
    Task() <- (Title = "Book taxi to airport", IsDone = false, _destroy = false),
    Task() <- (Title = "Arrange for someone to look after the cat", IsDone = false, _destroy = false),
  ]
}

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

Будут ли свойства помечаемые Клиент или Сервер. Такие свойства не должны ходить между клиентом и сервером.

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

А>[code]
А>public this() {
А>server.Load(tasks => {
А>Tasks = tasks.ToList();
А>});
А>}

А>Тут на мой взгляд какая то ересь.В вызове мы передаем параметр, а в реализации параметра нет.

Дело в том, что вызов асинхронный, поэтому приходится добавлять параметр коллбек. Если у вас есть предложения, как это сделать красивее, то пишите.

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

А>Будут ли свойства помечаемые Клиент или Сервер. Такие свойства не должны ходить между клиентом и сервером.

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

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

А>Будут ли свойства помечаемые Клиент или Сервер. Такие свойства не должны ходить между клиентом и сервером.

Кстати, стоит учесть, что классы общие для клиента и сервера. Т.е. как бы мы ни помечали поля, они всё равно будут видны на сервере, пускай с невыставленным значением. И если, например, прямиком их куда-то сериализировать, то будут лишние поля. Есть вариант создавать в макросе два класса, но для начала хотелось бы услышать аргументацию в пользу этого решения.

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

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

А>>Будут ли свойства помечаемые Клиент или Сервер. Такие свойства не должны ходить между клиентом и сервером.

I>Кстати, стоит учесть, что классы общие для клиента и сервера. Т.е. как бы мы ни помечали поля, они всё равно будут видны на сервере, пускай с невыставленным значением. И если, например, прямиком их куда-то сериализировать, то будут лишние поля. Есть вариант создавать в макросе два класса, но для начала хотелось бы услышать аргументацию в пользу этого решения.


public AvailableMeals : List[Meal] { get; set; }
public SeatCount : int;
я могу на клиенте подменить значение и при передаче на сервер.......
Поля могут быть не доступны для изменения с клента. Пароли не должны передаваться на клиент и вообще все неиспользуемые там данные. Так можно усилить безопасность.

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

А> public AvailableMeals : List[Meal] { get; set; }
А> public SeatCount : int;
А>я могу на клиенте подменить значение и при передаче на сервер.......
А>Поля могут быть не доступны для изменения с клента. Пароли не должны передаваться на клиент и вообще все неиспользуемые там данные. Так можно усилить безопасность.

Если я правильно тебя понимаю, то проблема такая:

class User 
{
   Username  : string;
   Age       : string;
   AvatarUrl : string;
   Password  : string;
}

На клиентской стороне есть представление позволяющее изменять Age и AvatarUrl. Но если злоумышленник добавит в запрос поле Username или Password, то они будут включены в обновление. Так?

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

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

А>> public AvailableMeals : List[Meal] { get; set; }
А>> public SeatCount : int;
А>>я могу на клиенте подменить значение и при передаче на сервер.......
А>>Поля могут быть не доступны для изменения с клента. Пароли не должны передаваться на клиент и вообще все неиспользуемые там данные. Так можно усилить безопасность.

I>Если я правильно тебя понимаю, то проблема такая:

I>

I>class User 
I>{
I>   Username  : string;
I>   Age       : string;
I>   AvatarUrl : string;
I>   Password  : string;
I>}
I>

I>На клиентской стороне есть представление позволяющее изменять Age и AvatarUrl. Но если злоумышленник добавит в запрос поле Username или Password, то они будут включены в обновление. Так?

Как один из вариантов.
В действительности часто бывает что не значительную часть данных надо передать. Кроме того можно ненароком передать ссылку на объект содержащий конфиденциальные данные и они передадутся на клиента.

вообщем есть 4 варианта
сериализируемые
несереализируемые
только клиент
только сервер

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

А>Как один из вариантов.
А>В действительности часто бывает что не значительную часть данных надо передать. Кроме того можно ненароком передать ссылку на объект содержащий конфиденциальные данные и они передадутся на клиента.

А>вообщем есть 4 варианта
А>сериализируемые
А>несереализируемые
А>только клиент
А>только сервер

Дело не в том, что мы хотим передать, а в том, что сервер примет. Если на сервере данные будут биндится к модели, у которой есть поле Password, то мы никаким образом не сможем помешать это поле обновить. (кроме, конечно, явного указания, что это поле не должно биндится). Совсем не важно, есть ли в JS модели поле Password или нету.

Правильное решение имхо исходит из самого фреймворка MVVM. На сервере есть модель User со всеми нужными полями. На клиенте у нас есть UserInfoViewModel, у которого есть только Age и AvatarUrl. Экшн сервера выглядит примерно так:

public UpdateUserInfo(model : UserInfoViewModel) : ActionResult
{
  var user = Map.[User](model);
  db.Update(user);
  ...  
}