Хороша доповідь. Є пара дрібних доповнень, а так кльово дуже навіть. Обома руками за Spring ROO - виглядає дуже цікаво, принаймні в якості побудови початкового "каркасу" для проекту.
Зауваження: Ті фреймворки, які названі доповідачем "Action/Request", хороші не тим що "прості", а тим що максимально наближені до реальності, тобто до HTTP request/response. Компонентні фреймворки складніші не тому що компонентні, а тому що намагаються відійти від request/response і якось мейнтейнити стан кожного компонента, що в умовах вебу часто не дуже працює, і звідси виникають всілякі ускладнення. ...
... "Action/Request" фреймворки не є "стандартний/типовий MVC", чи в більшій мірі MVC ніж все інше - це розповсюджена серед веб девелоперів хибна думка (-: Насправді ті хто писали UI десктопних аплікейшнів мабуть в курсі, що кожен компонент на зразок інпат філда чи дроп даун бокса вже написаний з застосуванням MVC, де модель це текст в інпат філді, контролер це логіка яка текст цей міняє на keypres, т.п. ...
... Суть MVC в Action/Request фреймворках в тому що він добре накладається на HTTP request/response цикл, і тому view це не view одного компонента, а цілої сторінки, controller це по суті сервлет чи його аналогія, бо приймає ріквест (в тій чи іншій формі) і віддає ріспонс.
... Плюс ще можна було трошки сильніше підкреслити що компонентні фреймворки добре підходять для того, що нагадує Веб Аплікейшн, тобто такий собі аплікейшн в браузері, аля Гугл Докс, Веб-інтерфейс MS Exchange і т.п. Тоді як "action/request" більше підходять по логіці для традиційних веб-сайтів, тобто сторінок з інформацією, не "програм в браузері".
... І ще деякі дрібниці: - Наскільки я знаю, проблема для повністью генерованого client side UI (JavaScript-ового або Flex-ового тобто) - SEO. Гугл не індексує флексові сайти, і не проіндексує мабуть сайти де UI повністью наповнюється javascrip-ом. А це totally unacceptable для багатьох сайтів, для котрих SEO "во главе угла"!
Це знову ж якраз acceptable скоріше для браузер-бейз аплікейшнів аля Гугл Докс, які індексувати як правило не треба. ...
- NetBeans хитається через те, що в Оракла є така IDE JDeveloper, і якраз цей JDeveloper включений в склад Oracle WebCenter, і в ньому (і лише в ньому) нормально і відосно зручно (наскільки це взагалі можливо) працювати з Оракловським ADF (візуальні редактори і т.п.) Сам ADF, доречі, це так би мовити "enhanced" версія JSF, тобто JSF + дописані згори речі (розширений lifecycle etc).
Сорі що в декілька коментів - блогспот схоже має обмеження на довжину комента, і видає дивні ерори коли багато букв (-:
Хороша доповідь.
ВідповістиВидалитиЄ пара дрібних доповнень, а так кльово дуже навіть.
Обома руками за Spring ROO - виглядає дуже цікаво, принаймні в якості побудови початкового "каркасу" для проекту.
Зауваження:
Ті фреймворки, які названі доповідачем "Action/Request", хороші не тим що "прості", а тим що максимально наближені до реальності, тобто до HTTP request/response.
Компонентні фреймворки складніші не тому що компонентні, а тому що намагаються відійти від request/response і якось мейнтейнити стан кожного компонента, що в умовах вебу часто не дуже працює, і звідси виникають всілякі ускладнення.
...
...
ВідповістиВидалити"Action/Request" фреймворки не є "стандартний/типовий MVC", чи в більшій мірі MVC ніж все інше - це розповсюджена серед веб девелоперів хибна думка (-:
Насправді ті хто писали UI десктопних аплікейшнів мабуть в курсі, що кожен компонент на зразок інпат філда чи дроп даун бокса вже написаний з застосуванням MVC, де модель це текст в інпат філді, контролер це логіка яка текст цей міняє на keypres, т.п.
...
...
ВідповістиВидалитиСуть MVC в Action/Request фреймворках в тому що він добре накладається на HTTP request/response цикл, і тому view це не view одного компонента, а цілої сторінки, controller це по суті сервлет чи його аналогія, бо приймає ріквест (в тій чи іншій формі) і віддає ріспонс.
Це таке "ідеологічне".
...
...
ВідповістиВидалитиПлюс ще можна було трошки сильніше підкреслити що компонентні фреймворки добре підходять для того, що нагадує Веб Аплікейшн, тобто такий собі аплікейшн в браузері, аля Гугл Докс, Веб-інтерфейс MS Exchange і т.п.
Тоді як "action/request" більше підходять по логіці для традиційних веб-сайтів, тобто сторінок з інформацією, не "програм в браузері".
Хоча в принципі це було вцілому зрозуміло.
...
...
ВідповістиВидалитиІ ще деякі дрібниці:
- Наскільки я знаю, проблема для повністью генерованого client side UI (JavaScript-ового або Flex-ового тобто) - SEO. Гугл не індексує флексові сайти, і не проіндексує мабуть сайти де UI повністью наповнюється javascrip-ом.
А це totally unacceptable для багатьох сайтів, для котрих SEO "во главе угла"!
Це знову ж якраз acceptable скоріше для браузер-бейз аплікейшнів аля Гугл Докс, які індексувати як правило не треба.
...
...
ВідповістиВидалити- NetBeans хитається через те, що в Оракла є така IDE JDeveloper, і якраз цей JDeveloper включений в склад Oracle WebCenter, і в ньому (і лише в ньому) нормально і відосно зручно (наскільки це взагалі можливо) працювати з Оракловським ADF (візуальні редактори і т.п.)
Сам ADF, доречі, це так би мовити "enhanced" версія JSF, тобто JSF + дописані згори речі (розширений lifecycle etc).
Сорі що в декілька коментів - блогспот схоже має обмеження на довжину комента, і видає дивні ерори коли багато букв (-:
Дякую, дуже гарна доповідь
ВідповістиВидалити