| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java tools & IDE's > Программное представление HTML элементов |
| Автор: Stampede 6.6.2005, 19:39 | ||
Недавно пришла в голову вот какая мысль, а ведь можно разработать программную модель для всех HTML элементов, и создавать страницы, используя код примерно такого вида:
Я не хочу сказать, что это было бы очень удобным способом программирования стрвниц, но если не доводить сей подход до крайности и абсурда, а использовать отдельные HTML элементы в таком представлении для автоматизации отдельных задач (например, автогенерация HTML форм из метаданных), то такая вещь в связке, например, с шаблонным движком - могла бы расширить арсенал программиста. Ну и вот. Так вот я и думаю, наверняка кто-то такое уже разрабатывал. Не может быть, что такая очевидная идея не пришла в голову еще кому-нибудь. Поэтому вопрос: если слышали про такие штуки - колитесь, пожалуйста |
| Автор: simanyay 6.6.2005, 19:43 |
| Для определенных задач вполне удобно. В Ruby такое есть и, не скрою, это иногда очень помогает. |
| Автор: Шмель 7.6.2005, 08:09 | ||
http://jakarta.apache.org/ecs/index.html - похоже на то, что ты описываешь. При использовании получается такой код:
|
| Автор: AntonSaburov 7.6.2005, 12:07 |
| А разве http://forum.vingrad.ru/index.php?showtopic=44988 не о таком варианте ? Хотя я давно очень читал - может и не понял точно все тогда. |
| Автор: Stampede 7.6.2005, 19:52 | ||
Нет-нет, это совсем разные вещи. Я говорю о библиотеке, где все HTML элементы были бы представлены в виде классов: Head, Body, P, UL, LI, Table, TR, TD и т. д. А про Velocity - обязательно напишу. Похоже, народ так и не понимает, в чем от него кайф. А кайф - огромный! Шмель - в самую точку. Администрация, прошу представить товарища к награде |
| Автор: simanyay 7.6.2005, 19:59 | ||||
А мы всё ждём-с...
Награждён почетным орденом "+". |
| Автор: Stampede 7.6.2005, 20:16 | ||
Георгиевский крест? |
| Автор: batigoal 7.6.2005, 22:18 |
| Что? Крест имени меня? Спасибо, конечно, но, право же, не стоит... Stampede Есть закрепленный топик на тему Velocity: http://forum.vingrad.ru/index.php?showtopic=44988. Есть желание - дополни, скажу спасибу. |
| Автор: Stampede 7.6.2005, 23:53 | ||
Дак, я ж знаю. Я же именно там и обещался. И выполнил - встречайте: http://forum.vingrad.ru/index.php?showtopic=44988&st=15entry435310 |
| Автор: Stampede 9.6.2005, 15:40 | ||||||
| Кстати, вот пример ситуации, где подобный класс будет весьма полезным. Посмотрите на тег <head>. В динамическом проложении он, как правило, хранится в отдельном файле и подключается при помощи какой-нибудь include в той или иной форме форме. Но содержимое тега <head> само по себе переменное и зависит от страницы. Хорошо, если изменяется только Title, тогда все относительно просто. А что если нужен разный Content-Tipe, например в многоязыковом проекте? А что если CSS подключается разный? А если нужно больше одного CSS файла? Передавать списком и итерировать в коде шаблона? Плюс та же фигня с мета параметрами http-equiv. Не слишком ли громоздко получится? А теперь представим, что у нас есть класс Head с такими методами:
Тогда мы запросто все это можем подготовить в классе, отвечающем за подготовку данных для шаблона, а в самом шаблоне просто одной строчкой сослаться на объект класса Head:
По соглашению Velocity при такой записи вызывается метод toString() ссылемого объекта. Который в случае класса Head должен делать то, что от него и ожидается: рендерить себя в HTML. Куль? Да, куль. Тут опять надо заметить, что наиболее естественным образом такой фокус можно осуществить, если приложение спроектировано в идеологи Velocity (см. http://vingrad.ru/JAVA-JAV-002896) Теперь смотрим на то, как класс Head реализован в библиотеке Jakarta ECS (Element Construction Set). А очень тупо он реализован. Слшком общО. Описания API в Javadoc в онлайне для него не нашел, поэтому привожу по той документации, что идет в пакете:
Нахера?! Вы же не generic API создаете, у вас же конкретная библиотека классов. Сделайте так, чтобы ею было удобно пользоваться! Дайте мне convenience методов. Чтобы можно было одной строчкой добавить CSS или там HttpEquiv - неужели так трудно? И ведь явно для себя писали, не для дяди, а вот поди ж ты. Короче, блин, как меня это уже задрало. Ни на кого нельзя положиться, все приходится делать самому. И буду делать. А кому щас легко |
| Автор: Stampede 10.6.2005, 19:51 | ||
[выжидательно смотрит] |
| Автор: batigoal 10.6.2005, 20:03 |
| Domestic уже сказал Просто я так и не поверил, что это лучше, чем использовать Expression Language. Но это уже мои проблемы. Потом пощупаю сам и решу. |
| Автор: Stampede 10.6.2005, 20:23 | ||||
Так давайте же обсуждать! Я же завершаю статью приглашением к обсуждению. В этом ведь главный пойнт нашего здесь тусения. А может я действительно неправ? Может, я чего-то важного не понимаю в этой жизни?
Я, между прочим не о регалиях, а о простом человеческом спасибе, которое было обещано. Старался, как-никак |
| Автор: batigoal 10.6.2005, 20:27 |
| Спасибо! И даже большое! А насчет обсуждения - пока я сам не попробовал, я не смогу квалифицированно вести дискуссию. Так что обождем. |
| Автор: simanyay 10.6.2005, 20:29 |
| Твоей статье даже http://blog.simanyay.org/?p=32 была |
| Автор: Sleepy_PIP 10.6.2005, 21:09 |
| чего я не понял в статъе: "Например, event-driven подход к программированию гуя - это инверсный подход по сравнению с тем, когда ты всю логику программируешь в классе окна, ждешь всяких событий и как-то на них реагируешь." извините, но я не понимаю - а что - логику обработки UI окна надо рассредотачивать во вне класса окна? Не, в Делфи отличный подход - рекомендую. либо я чего-то не понимаю, либо звиняйте речь идет об обрабоке события нажатия на кнопку в окне в совсем другом классе ... но это-ж маразм? ЗАЧЕМ растаскивать обработку кнопки в окне в совсем други классы, когда это с удовольствием делается в классе окна с вызовом прочей сторонней бизнес-логики. ну не понимаю я ... |