Для начала нужно отделить мух от котлет.
Какое отношение БД имеет к вебу?
Правильный ответ: Никакое.
Те удобная работа с базой таки нужна но это совершенно отдельная от веба полезная сама по себе тема.
По этому эту тему в контексте обсуждения веб-фреймворка трогать смысла не имеет.
У нас есть интерфейс бекенда и больше нас ничего не интересует.
Всю логику не связанную с отображением выжимаем в бекенд, а то что остается делить на контроллер и вьюху уже не имеет смысла.
Единственное что может пригодится это весьма универсальная механика фьючеров. (Я их давно написал. Скоро залью в снипеты.)
Те метод возвращает не значение, а обертку в которую другой поток через некоторое время положет значение.
Это нужно для того чтобы можно было вызвать несколько методов которые упираются в IO. Например хождение в базу или просто в другого демона на другой машине.
Чем должен заниматься собственно веб фреймворк:
Разбором и генерацией урлов и кук.
Рендером HTML.
Трансляцией немерлового кода в жабаскрипт.
Организацией AJAX взаимодействия клиентского и серверного кода.
В качестве прототипа нужно брать http://www.impredicative.com/ur/
Те весь рендер должен быть полностью статически типизирован.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Трансляцией немерлового кода в жабаскрипт. WH>Организацией AJAX взаимодействия клиентского и серверного кода.
Вот это как-то не внятно. Лично я как пользователь такой либы хотел бы для многих задач получить готовые решения в виде неких компонентов. Так чтобы можно было в табличку данные вывести, дать их ползователю изменить, а потом получить на сервере и залить в БД. Да так чтобы при этом минимум телодвижений.
Есть идеи как это реализовать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
WH>>Трансляцией немерлового кода в жабаскрипт. WH>>Организацией AJAX взаимодействия клиентского и серверного кода. VD>Вот это как-то не внятно. Лично я как пользователь такой либы хотел бы для многих задач получить готовые решения в виде неких компонентов. Так чтобы можно было в табличку данные вывести, дать их ползователю изменить, а потом получить на сервере и залить в БД. Да так чтобы при этом минимум телодвижений.
Готовые решения в виде компонентов — это в веб-формс, там все это есть. Таблички, контролы, события и прочая.
VD>Есть идеи как это реализовать?
Например, когда вью пишется на XSLT очень просто. Стандартный шаблон, который внутри себя разделен на несколько шаблонов. Основная ценность шаблона — сама логика трансформация, построенная на матчах по дереву. Взял готовые шаблон, который использовался для генерации дерева. Хочешь вместо дерева таблицу. Подменил один-два "дочерних" шаблона — получил таблицу. Контролам такое и не снилось.
Хотелось бы что-то в таком ключе.
ВВ>Например, когда вью пишется на XSLT очень просто. Стандартный шаблон, который внутри себя разделен на несколько шаблонов. Основная ценность шаблона — сама логика трансформация, построенная на матчах по дереву. Взял готовые шаблон, который использовался для генерации дерева. Хочешь вместо дерева таблицу. Подменил один-два "дочерних" шаблона — получил таблицу. Контролам такое и не снилось. ВВ>Хотелось бы что-то в таком ключе.
XSLT — это очень гибко, но к сожалению очень ресурсозатратно!
Здравствуйте, stilux, Вы писали:
ВВ>>Например, когда вью пишется на XSLT очень просто. Стандартный шаблон, который внутри себя разделен на несколько шаблонов. Основная ценность шаблона — сама логика трансформация, построенная на матчах по дереву. Взял готовые шаблон, который использовался для генерации дерева. Хочешь вместо дерева таблицу. Подменил один-два "дочерних" шаблона — получил таблицу. Контролам такое и не снилось. ВВ>>Хотелось бы что-то в таком ключе. S>XSLT — это очень гибко, но к сожалению очень ресурсозатратно!
Ты имеешь в виду что — скорость? В 1.0 было медленновато, начиная с 2.0 дотнет переехал на новый MSXML и стало вполне приемлимо. Ну на крайний случай есть compiled XSLT.
Я бы сказал главные недостатки — это ограниченность самого XSLT как языка, а также его "пухлость".
ВВ>Ты имеешь в виду что — скорость? В 1.0 было медленновато, начиная с 2.0 дотнет переехал на новый MSXML и стало вполне приемлимо. Ну на крайний случай есть compiled XSLT. ВВ>Я бы сказал главные недостатки — это ограниченность самого XSLT как языка, а также его "пухлость".
А когда это .Net переехал на XSLT 2.0? Просветите пожалуйста .
Здравствуйте, stilux, Вы писали:
ВВ>>Ты имеешь в виду что — скорость? В 1.0 было медленновато, начиная с 2.0 дотнет переехал на новый MSXML и стало вполне приемлимо. Ну на крайний случай есть compiled XSLT. ВВ>>Я бы сказал главные недостатки — это ограниченность самого XSLT как языка, а также его "пухлость". S>А когда это .Net переехал на XSLT 2.0? Просветите пожалуйста .
Где ты увидел XSLT 2.0? Я вообще его реализацию даже не трогал вживую. Речь была про новую на тот момент версию MSXML, которая просто тупо быстрее работало, чем то, что было в 1.0.
Я сейчас точно не помню, проводили тесты, разница получалась до 4х раз.
Здравствуйте, WolfHound, Вы писали:
WH>Чем должен заниматься собственно веб фреймворк: WH>Разбором и генерацией урлов и кук. WH>Рендером HTML. WH>Трансляцией немерлового кода в жабаскрипт. WH>Организацией AJAX взаимодействия клиентского и серверного кода.
+Обеспечением защиты от появления хотя бы XSS, CSRF и HRS уязвимостей в коде, ибо только статическая типизация эти проблемы решить не сможет.
.
