Re: XSLT или контролы? - ASP.NET

Я сейчас пишу топиковое приложение. На страницу у меня есть всего один элемент Label и поле hidden submit.

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

Обратная связь такая — команда (типа "pressedButton_Play") записывается в hidden поле и делается Form.Submit.

Вопрос. Имеет ли смысл то, что я делаю, или все нормальные люди все же пользуются стандартными средствами ASP.NET?

Ведет ли этот метод к задержке по сравнению с "нормальным"?

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

M>Страницу я рисую через XSLT, а не через контролы. Во-первых, больший контроль над содержимым, во-вторых у меня все данные из баз и файлов грузятся и записываются в виде XML и мне проще кинуть пачку XMLек в XSLT, чем распихивать их по контролам.

А потом распихивать данные по hidden полям тоже просто? XML+XSLT удобно когда нужно сделать отображение данных, а интенстивное взаимодействие с пользователем на ASP.NET будет сделать проще...

M>Обратная связь такая — команда (типа "pressedButton_Play") записывается в hidden поле и делается Form.Submit.

M>Вопрос. Имеет ли смысл то, что я делаю, или все нормальные люди все же пользуются стандартными средствами ASP.NET?

Смотря что делать... Многим и обычно ASP.NET хватает. Да и решение XML+XSLT для динамического контента может оказаться медленнее традиционного ASP.NET приложения

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

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

M>>Страницу я рисую через XSLT, а не через контролы. Во-первых, больший контроль над содержимым, во-вторых у меня все данные из баз и файлов грузятся и записываются в виде XML и мне проще кинуть пачку XMLек в XSLT, чем распихивать их по контролам.

TK>А потом распихивать данные по hidden полям тоже просто? XML+XSLT удобно когда нужно сделать отображение данных, а интенстивное взаимодействие с пользователем на ASP.NET будет сделать проще...
Не, ОДНО хидден поле чтобы обратно от клиента инфу посылать.

M>>Обратная связь такая — команда (типа "pressedButton_Play") записывается в hidden поле и делается Form.Submit.

M>>Вопрос. Имеет ли смысл то, что я делаю, или все нормальные люди все же пользуются стандартными средствами ASP.NET?

TK>Смотря что делать... Многим и обычно ASP.NET хватает. Да и решение XML+XSLT для динамического контента может оказаться медленнее традиционного ASP.NET приложения

Понятно. Спасибо.

Я могу рассказать как делаем это мы.

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

Простой пример — в разработке одного коммерческого приложения на чистом ASP.NET потребовалось делать редизайн 3 раза. Отсутвуие шаблонов как таковых и объединение дизайна и фукционала в ASPX привело к увеличению работы в разы.

В результате мы пошли по другому пути. Мы разработали собственные библиотеки классов для:

1. Отображения объектов на XML
2. Рендернига объектов встроенных в ASPX страницы с помощью XSLT
3. Форм как объектов отображаемых на XML (заполнение параметров из запросов, поддержка визардов, и т.д)
3. Отображения объектов на таблицы в базе (MS SQL)

Все дополнительные свойства описываются в коде .NET аттрибутами.

В XSLT тоже сделан набор готовых шаблонов для форм, контролов, и т.д.

Затраты на создание всего этого довольно велики (около 4 человеко-месяцев), но мы это сделали в бюджете одного проекта и теперь успешно реюзаем в большинстве новых проектов.

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

E>В самом начале мы посмотрели на ASP.NET и поняли, что это — самое худшее из того что есть в .NET. Такое впечатление, что проектировали его те же люди, что и старый

А вот ес достаточно популярное мнение что это — лучшее в .Net

Не стоит путать ASP.Net и Web Forms.

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

Это я вообще не понял. Это как???

E>Простой пример — в разработке одного коммерческого приложения на чистом ASP.NET потребовалось делать редизайн 3 раза. Отсутвуие шаблонов как таковых и объединение дизайна и фукционала в ASPX привело к увеличению работы в разы.

Студию и codebehind использовать не пробовали?

Вообще, странные аргументы. Может в консерватории что поправить?

E>В результате мы пошли по другому пути. Мы разработали собственные библиотеки классов для:

Мы пойдем другим путем... где-то я уже это слышал.

... << RSDN@Home 1.0 beta 6a >>

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

E>В результате мы пошли по другому пути. Мы разработали собственные библиотеки классов для:

E> 1. Отображения объектов на XML
E> 2. Рендернига объектов встроенных в ASPX страницы с помощью XSLT
E> 3. Форм как объектов отображаемых на XML (заполнение параметров из запросов, поддержка визардов, и т.д)
E> 3. Отображения объектов на таблицы в базе (MS SQL)

E>Все дополнительные свойства описываются в коде .NET аттрибутами.

E>В XSLT тоже сделан набор готовых шаблонов для форм, контролов, и т.д.

E>
E>Затраты на создание всего этого довольно велики (около 4 человеко-месяцев), но мы это сделали в бюджете одного проекта и теперь успешно реюзаем в большинстве новых проектов.

Ээ... А можно посмотреть?

Не на все конечно, а какие-нибудь образцы? Чтобы знать, как это правильные люди делают?

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

E>Я могу рассказать как делаем это мы.

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

В старом VisualBasic с абстракциями как раз было очень плохо...

E>Простой пример — в разработке одного коммерческого приложения на чистом ASP.NET потребовалось делать редизайн 3 раза.

Посмотреть один раз на технологию и сразу-же браться за коммерческий проект — это самый верный способ составить о ней плохое мнение.

E>Отсутвуие шаблонов как таковых и объединение дизайна и фукционала в ASPX привело к увеличению работы в разы.

Дизайн и функционал был объединен в старом ASP. Естественно, что многие программисты имевшие дело с обычным ASP путаются использовать свои навыки и в .NET это не ошибочная идея.

E>В результате мы пошли по другому пути. Мы разработали собственные библиотеки классов для:

E> 1. Отображения объектов на XML
E> 2. Рендернига объектов встроенных в ASPX страницы с помощью XSLT
E> 3. Форм как объектов отображаемых на XML (заполнение параметров из запросов, поддержка визардов, и т.д)
E> 3. Отображения объектов на таблицы в базе (MS SQL)

Если не используются ASP.NET элементы управления, то для чего нужно использовать *.ASPX страницы???

E>Затраты на создание всего этого довольно велики (около 4 человеко-месяцев), но мы это сделали в бюджете одного проекта и теперь успешно реюзаем в большинстве новых проектов.

А на освоение ASP.NET сколько человеко-месяцев было затрачено?

посмотреть — можно. Вот кусочек класса формочки на нашей технологии:

    [XMLNode("Form")]
    public class ExportCartForm : BaseForm
    {
        [XMLNode("ExportCart")]
        public ExportCart cart = null;

        [XMLNode("Email")]
        [FormParam("Email", Storage = FormParamStorage.HTTP)]
        [EmailFieldValidator()]
        public string Email;

        public override void init() 
        {
            try
            {
                DbLayer dbl = new DbLayer();
                DbObjects.PublicUser u = dbl.RetrieveObject(PL.SessionObjects.SessionObjects.getUserID(), typeof(DbObjects.PublicUser)) as DbObjects.PublicUser;
                if (u != null) this.Email = u.Email;
            }
            catch (Exception e)
            {
                e = e;
            }

        }

E>>Простой пример — в разработке одного коммерческого приложения на чистом ASP.NET потребовалось делать редизайн 3 раза.

TK>Посмотреть один раз на технологию и сразу-же браться за коммерческий проект — это самый верный способ составить о ней плохое мнение.

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

Я не хочу, сказать, что web forms — полный отстой. Для некоторых НЕБОЛЬШИХ приложений подход с WYSIWYG редактором вполне подходит. Так же как VB 6.0 для декстопных приложений аналогичной сложности.

TK>Дизайн и функционал был объединен в старом ASP. Естественно, что многие программисты имевшие дело с обычным ASP путаются использовать свои навыки и в .NET это не ошибочная идея.

В ASP можно тоже было очень красиво и приятно разделять отображение и обработку, в частности с помощью того-же XSLT. Для этого, естественно, надо было писать нужные модули самому.

TK>Если не используются ASP.NET элементы управления, то для чего нужно использовать *.ASPX страницы???

Для layout-a страницы. В них перечисляются большие независимые блоки страницы, такие как меню, основная часть окна, футер, и т.п.

TK>А на освоение ASP.NET сколько человеко-месяцев было затрачено?

В обычных коммерческих организациях достаточно редко удается обучать сотрудников целенаправленно (курсы, экзамены, тесты и т.п.). Поэтому обучение шло в фоновом режиме, и в том числе на коммерческих проектах. Хочу заметить, что сроков мы не срывали

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

E>Тогда попробуйте мне объяснить, как можно сделать так, что бы стили всех кнопок проекта были одинаковы и менялись изменением одной строчки в исходниках.

А что css не подходит?

E>В ASP можно тоже было очень красиво и приятно разделять отображение и обработку, в частности с помощью того-же XSLT. Для этого, естественно, надо было писать нужные модули самому.

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

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

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

E>>Тогда попробуйте мне объяснить, как можно сделать так, что бы стили всех кнопок проекта были одинаковы и менялись изменением одной строчки в исходниках.

GB>А что css не подходит?

Нет, если речь идет о совместимости с разными устаревшими версиями браузеров.

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

Не часть в весь дизайн в XSLT — и это хорошо. Плохо, когда логики много в XSLT или в другом презнтационном слое. А в ASPX — сплошая логика получается.

GB>А дизайнеру ну ОЧЕНЬ сложно разобраться в этой петрушке.

А каково дизайнеру в VS.NET рисовать? Дизайнер на то и дизайнер, что бы в Photoshope рисовать и HTML клепать. Если есть возможность — садятся выделенные люди занимающиеся только презентационной частью (XSLT, HTML, JavaScript), а программеры кодом занимаются.

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

E>Тогда попробуйте мне объяснить, как можно сделать так, что бы стили всех кнопок проекта были одинаковы и менялись изменением одной строчки в исходниках.

Изменить строчку в методе Render кнопки.

E>Я не хочу, сказать, что web forms — полный отстой. Для некоторых НЕБОЛЬШИХ приложений подход с WYSIWYG редактором вполне подходит. Так же как VB 6.0 для декстопных приложений аналогичной сложности.

E>В ASP можно тоже было очень красиво и приятно разделять отображение и обработку, в частности с помощью того-же XSLT. Для этого, естественно, надо было писать нужные модули самому.

Так ASP.NET тоже предоставляет для этого свои возможности, просто идет другим путем.

E>Для layout-a страницы. В них перечисляются большие независимые блоки страницы, такие как меню, основная часть окна, футер, и т.п.

Независимые болки можно как-раз и вынести из страницы и вставлять их использую post обработку.

TK>>А на освоение ASP.NET сколько человеко-месяцев было затрачено?

E>В обычных коммерческих организациях достаточно редко удается обучать сотрудников целенаправленно (курсы, экзамены, тесты и т.п.). Поэтому обучение шло в фоновом режиме, и в том числе на коммерческих проектах. Хочу заметить, что сроков мы не срывали

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

E>посмотреть — можно. Вот кусочек класса формочки на нашей технологии:

E>

E>    [XMLNode("Form")]
E>    public class ExportCartForm : BaseForm
E>    {
E>        [XMLNode("ExportCart")]
E>        public ExportCart cart = null;

E>        [XMLNode("Email")]
E>        [FormParam("Email", Storage = FormParamStorage.HTTP)]
E>        [EmailFieldValidator()]
E>        public string Email;

E>        public override void init() 
E>        {
E>            try
E>            {
E>                DbLayer dbl = new DbLayer();
E>                DbObjects.PublicUser u = dbl.RetrieveObject(PL.SessionObjects.SessionObjects.getUserID(), typeof(DbObjects.PublicUser)) as DbObjects.PublicUser;
E>                if (u != null) this.Email = u.Email;
E>            }
E>            catch (Exception e)
E>            {
E>                e = e;
E>            }

E>        }

E>

Спасибо. Оказывается, кто-то таки использует аттрибуты (если я правильно понял смысл квадратных скобок)... Надо бы попробовать.

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

Кстати, у тебя в коде есть корявость

E> catch (Exception e)
E> {
E> e = e;
E> }

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

E> catch (Exception)
E> {
E> }

Тогда получается логичнее.

Далее, какой смысл в двойном SessionObjects PL.SessionObjects.SessionObjects.getUserID()?

Перерендеривается ли у вас форма после каждого непринятого сабмита или меняются только значения в полях?

И еще, у меня все источники данных (селекты из базы, файлы в разных форматах) забираются по имени через единый класс — диспетчер в виде XML. Имена и источники прописаны в конфиге. У вас — так же, или по-другому?

E>http://www.icago.com/

Сайт выглядит очень профессинально, но вам не кажется, что ему немного не хватает единства решений?
Только на первой странице я насчитал 6 способов выделения ссылки при наведении — и еще одну нв второй странице.

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

E>Не часть в весь дизайн в XSLT — и это хорошо. Плохо, когда логики много в XSLT или в другом презнтационном слое. А в ASPX — сплошая логика получается.

Ну это знаешь ли как писать. Хотя на 100% разделить неполучится. В XSLT тоже логика присутствует сам ведь говоришь.

E>А каково дизайнеру в VS.NET рисовать? Дизайнер на то и дизайнер, что бы в Photoshope рисовать и HTML клепать. Если есть возможность — садятся выделенные люди занимающиеся только презентационной частью (XSLT, HTML, JavaScript), а программеры кодом занимаются.

Ну и пусть рисует себе в каком-нибудь дреамвивер эмикс, который прекрассно понимает все ASPX-овые теги. Вот именно что дизайнер чтобы в Photoshope рисовать и HTML клепать, а ты его каим-то XSLT напрягаешь

Так что как правило XSLT пишут кодеры, а дизайнеры смотрят на него как гусь на молнию.
ASP.NET — это компонентно ориентированная технология, следовательно гораздо больше пространства для маневра, легко разбить страницы на части типа меню, футер, хедер и т.д.
XSLT в этом плане плоско выглядит.

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

E>>А каково дизайнеру в VS.NET рисовать? Дизайнер на то и дизайнер, что бы в Photoshope рисовать и HTML клепать. Если есть возможность — садятся выделенные люди занимающиеся только презентационной частью (XSLT, HTML, JavaScript), а программеры кодом занимаются.

GB>Ну и пусть рисует себе в каком-нибудь дреамвивер эмикс, который прекрассно понимает все ASPX-овые теги. Вот именно что дизайнер чтобы в Photoshope рисовать и HTML клепать, а ты его каим-то XSLT напрягаешь

GB>Так что как правило XSLT пишут кодеры, а дизайнеры смотрят на него как гусь на молнию.
GB>ASP.NET — это компонентно ориентированная технология, следовательно гораздо больше пространства для маневра, легко разбить страницы на части типа меню, футер, хедер и т.д.
GB>XSLT в этом плане плоско выглядит.

Как человек с опытом работы с WEB-дизайнерами могу сказать, что наиболее удобный для обоих метод — это когда дизайнер рисует страницы на HTML, а программер разбавляет HTML тэгами логики (например, на XSLT) по надобности.

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

M>Как человек с опытом работы с WEB-дизайнерами могу сказать, что наиболее удобный для обоих метод — это когда дизайнер рисует страницы на HTML, а программер разбавляет HTML тэгами логики (например, на XSLT) по надобности.

То, что ты говоришь, не фокус. Так работают очень многие.
Фокус начинается когда дизанеру надо что-то поправить в представлении, по которому уже проехался кодер

И в XSLT ему это сделать не очень просто.
Выход типа: дизайнер заново рисует страницы на HTML, а потом по ним опять едет кодер — понятное дело не является нормальным.
Это очень известная проблема и решений предлагается множество.
Например в жабе есть всекие template engine.
ИМХО в ASPX это проблема не стоит так остро, и есть неплохое преимущество, что все это компонентно ориентировано. Т.е. если есть какой-то блок то и код и представление лежат вместе, но не перемешаны

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

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

M>>Как человек с опытом работы с WEB-дизайнерами могу сказать, что наиболее удобный для обоих метод — это когда дизайнер рисует страницы на HTML, а программер разбавляет HTML тэгами логики (например, на XSLT) по надобности.

GB>То, что ты говоришь, не фокус. Так работают очень многие.
GB>Фокус начинается когда дизанеру надо что-то поправить в представлении, по которому уже проехался кодер

GB>И в XSLT ему это сделать не очень просто.

Если он способен понять, как работает HTML, то и подправить локальное место в XSLT он сможет.

GB>Выход типа: дизайнер заново рисует страницы на HTML, а потом по ним опять едет кодер — понятное дело не является нормальным.
Если изменнения небольшие, то программер может их внести ручками по объяснениям и измененному коду дизайнера. Мы делали так.

GB>Это очень известная проблема и решений предлагается множество.
GB>Например в жабе есть всекие template engine.
GB>ИМХО в ASPX это проблема не стоит так остро, и есть неплохое преимущество, что все это компонентно ориентировано. Т.е. если есть какой-то блок то и код и представление лежат вместе, но не перемешаны

А это когда как.

И XSLT ИМХО Web-дизайнеру выучить гораздо проще, чем ASP. По крайней мере, необходимый минимум.

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

GB>>Выход типа: дизайнер заново рисует страницы на HTML, а потом по ним опять едет кодер — понятное дело не является нормальным.
M>Если изменнения небольшие, то программер может их внести ручками по объяснениям и измененному коду дизайнера. Мы делали так.

Это геморно да и то нормально если изменения небольшие.
А если редизайн делается?

GB>>Это очень известная проблема и решений предлагается множество.
GB>>Например в жабе есть всекие template engine.
GB>>ИМХО в ASPX это проблема не стоит так остро, и есть неплохое преимущество, что все это компонентно ориентировано. Т.е. если есть какой-то блок то и код и представление лежат вместе, но не перемешаны

M>А это когда как.

Ну если писать через попу то XSLT не поможет

M>И XSLT ИМХО Web-дизайнеру выучить гораздо проще, чем ASP. По крайней мере, необходимый минимум.

Не знаю не знаю скорее всего где-то одинаково.

Можно в принципе WEB controls на XSLT писать.
Вобщем ASP.NET конечно не панацея от старой проблемы разделения кода и представления, но это шаг в правильном направлении.

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

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

GB>>>Выход типа: дизайнер заново рисует страницы на HTML, а потом по ним опять едет кодер — понятное дело не является нормальным.
M>>Если изменнения небольшие, то программер может их внести ручками по объяснениям и измененному коду дизайнера. Мы делали так.

GB>Это геморно да и то нормально если изменения небольшие.
GB>А если редизайн делается?

А как это решается в ASP.NET?

GB>>>Это очень известная проблема и решений предлагается множество.
GB>>>Например в жабе есть всекие template engine.
GB>>>ИМХО в ASPX это проблема не стоит так остро, и есть неплохое преимущество, что все это компонентно ориентировано. Т.е. если есть какой-то блок то и код и представление лежат вместе, но не перемешаны

M>>А это когда как.

GB>Ну если писать через попу то XSLT не поможет

Это да.

M>>И XSLT ИМХО Web-дизайнеру выучить гораздо проще, чем ASP. По крайней мере, необходимый минимум.
GB>Не знаю не знаю скорее всего где-то одинаково.

Просто XSLT роднее. Т.е. он, в отличие от всего остального, придуман пррактически именно для этого. Кроме того, Программер может писать на рзных языках, а дизайнер для них всех — в том же XSLT.

GB>Можно в принципе WEB controls на XSLT писать.
GB>Вобщем ASP.NET конечно не панацея от старой проблемы разделения кода и представления, но это шаг в правильном направлении.

На самом деле мне просто XSLT по духу привычнее. Я когда-то писал движок шаблонов для перла, так там идеология была точно такая же — шаблон получает дерево и уже в нем лазает по ветвям.

И в условиях недостатка времени и знания HTML освоить XSLT можно гораздо быстрее, чем контролы.

	От:	mihoshi
	Дата:	28.03.03 09:02
	Оценка:

От:	TK	кывт.рф
Дата:	28.03.03 09:12
Оценка:	12 (1)

	От:	mihoshi
	Дата:	28.03.03 09:26
	Оценка:

	От:	expert
	Дата:	28.03.03 09:32
	Оценка:	18 (1)

	От:	Gollum
	Дата:	28.03.03 09:39
	Оценка:

	От:	gl#b
	Дата:	31.03.03 14:50
	Оценка:

	От:	gl#b
	Дата:	01.04.03 06:47
	Оценка:

	От:	gl#b
	Дата:	01.04.03 07:33
	Оценка:

	От:	gl#b
	Дата:	01.04.03 11:51
	Оценка: