Технології для користувача інтерфейсів Web 2.0, HTML, XML, DHTML, Інтернет-технології, статті

Уявіть собі, що вам поставили завдання створити новий додаток, що буде існувати в світі Web 2.0. Деяких з ваших користувачів повністю влаштовують HTML-засновані користувальницькі інтерфейси, в той час як інші очікують, що кожен додаток, яке вони використовують, буде вести себе як Excel. Ваш бізнес-спонсор хоче зручний в користуванні, ефективний і продуктивний інтерфейс, а керівник інформаційної служби не дозволяє вам розробляти що б там не було, якщо воно вимагає ручного розгортання користувачем. Ви знаєте, що HTML з цим не впорається, але що ж є ще? У статті досліджується набір технологій для користувача інтерфейсу Web 2.0, що дозволяють вам створювати зручні для користувачів програми, що виходять за рамки можливостей звичайного браузера. В результаті ви можете централізовано розгортати програми та керувати ними, як і будь-якими іншими додатками Java 2 Enterprise Edition (Java EE).

В даний час розробник корпоративних додатків відчуває тиск як з боку користувачів, так і з боку фахівців, коли мова заходить про користувальницьких інтерфейсів. В одному таборі знаходяться бізнес-підрозділу, що представляють користувачів. Вони хочуть, щоб їх застосування мали багатий користувальницький інтерфейс, що сприяє збільшенню продуктивності праці користувачів. Представники цієї групи вважають за краще, щоб всі їхні програми вели себе як Microsoft Excel або інші подібні програми, що встановлюються на клієнтах. Вони бажають, щоб програми забезпечували їм миттєве час відгуку. Якщо є декілька подань одних і тих же даних (наприклад таблиця і графік), і одне з них змінюється, вони хочуть, щоб і інше відображається уявлення миттєво відображало б зміни.


Представники ж IT-фахівців люблять чисту, сервер-засновану модель доставки. Визнаючи, що працювати користувачам з HTML менш зручно, ніж з рідним інтерфейсом операційної системи, вони вважають вартість установки, настройки і управління кодом на клієнтських машинах занадто високою, незважаючи на більш зручну роботу для користувачів, яку дає це рішення.


Багато хто з IT-фахівців в 1990-х рр.. пережили клієнт / серверну модель розгортання і не хочуть знову мати з нею справу. У дійсності, багато додатків Java 2 Enterprise Edition (Java EE), можливо, так і не були б створені, якби в них існував клієнтський компонент, так як його вартість звела б нанівець комерційну вигідність програми. Модель серверного розгортання дає IT-підрозділам бажаний простір і свободу дій в плані економічної ефективності, про яку можна було тільки мріяти в дев’яностих. Більшість організацій, що стикалися з економічними характеристиками розгортається на сервері додатка Java EE, ніколи не будуть розглядати можливість розгортання коду, який вони повинні будуть встановити на окремі клієнтські машини, якщо тільки не виникне гостра необхідність.


Так що ж робити бідним корпоративним розробникам? Користувачі не хочуть втрачати продуктивність через многосекундних затримок відгуку від сервера, а групи IT-фахівців не хочуть повертатися до старих способам розгортання і управління кодом на клієнтських машинах. Як примирити ці, здавалося б, суперечать один одному вимоги таким чином, щоб обидва табори залишилися задоволені?


На щастя, існують технології, що дозволяють вам досягти зручності користувача при роботі з функціями, що перевищують можливості звичайного браузера, і при цьому не вимагають від вас ручної установки коду на клієнтських машинах. Додатки, створювані за допомогою цих технологій, іноді називають додатками Web 2.0. У своїй статті, “Що таке Web 2.0? Конструктивні шаблони і бізнес-моделі наступного покоління ПО “, Тім О” Рейлі заявляє:


Ми вступаємо в безпрецедентний період інновацій в області для користувача інтерфейсу, так як Web-розробники нарешті отримали можливість створювати Web-додатки, так само багаті функціонально, як і локальні PC-додатки.

Додатки Web 2.0 беруть все найкраще з обох світів: економічно ефективна сервер-заснована модель розгортання поєднується з високим зручністю роботи користувачів, в основному порівнянної з комфортністю роботи в установлених на клієнті додатках.


Нижче перераховані різні технології, які ви можете вибрати для створення привабливою і зручною для користувачів середовища в сьогоднішніх додатках Java EE:



Flex і OpenLaszlo


Flex і OpenLaszlo – схожі декларативні походи до створення перевищують можливості браузерів інтерфейсів для додатків Java EE. Flex пропонується Adobe / Macromedia, а OpenLaszlo – ПЗ з відкритим вихідним кодом, спочатку створене Laszlo Systems Inc. В обох середовищах для проектування і створення користувальницького інтерфейсу ви використовуєте унікальну, прив’язану до конкретної технології граматику на основі XML.


Наприклад, щоб використовувати кнопку під Flex, ви можете написати наступний код на MXML (Multimedia XML): <a name=”code-text”><mx:Button label=”Submit”</mx:Button></a>


А в OpenLaszlo ви пишете наступне на LZX (LasZlo XML): <a name=”code-text”><button<Submit</ button></a>


Щоб дозволити різним елемента інтерфейсу взаємодіяти і підтримувати зв’язок з сервером, ви пишете скрипт або на ActionScript (Flex), або на JavaScript (OpenLaszlo).


Хоча обидві технології багато в чому подібні, є і ключова відмінність – їм потрібна різна інфраструктура виконання. Щоб клієнт обмінявся даними з сервером, для Flex необхідний Flex Data Services Server, який встановлює зв’язок з клієнтом, що працюють в плагіні Flash Player. Сервер в значній мірі служить посередником для будь-якого обміну даними між клієнтом і серверним компонентом програми.


В останній версії OpenLaszlo є деякі зміни в області виконання, які можуть зробити її більш привабливою для розробників. Одним із змін є те, що в Версії 3 з’явився режим розгортання SOLO, що виключає необхідність в Laszlo Presentation Server в деяких конфігураціях. Ще одне важливе вдосконалення – це середа виконання клієнта. Новітній реліз, OpenLazlo 4 (в даний час бета-версія), дозволяє заснованим на Laszlo додаткам виконуватися без плагіна Adobe / Macromedia Flash Player. Багатьом компаніям, стурбованим тим, що їм доводиться використовувати пропріетарний плагін кшталт Flash Player, ця зміна буде до смаку.


Як визначити, що краще для вашої організації? У разі Flex, ключовим перевагою є те, що ви маєте повну підтримку від Adobe / Macromedia, але ви понесете витрати на придбання ліцензії на Flex Data Services Server. Для деяких компаній вартість ліцензії не так важлива, як повна підтримка продукту. Додатків Adobe Flex 2 також потрібно плагін Flash Player V9. Незважаючи на те, що Flex може допомогти створити привабливу для користувача середовище, його вартість, а також той факт, що йому потрібно плагін, може відлякати деякі компанії.


Технологія OpenLaszlo спочатку випускалася як комерційний продукт, але в 2004 р. Laszlo Systems вирішила перевести її на опенсорсние рейки, ліцензуваливідповідну її під Common Public License (V1.0). Laszlo Systems не пропонує підтримки за передплатою, і так як це відкритий проект, ви можете здійснювати підтримку через вільно доступні джерела. У разі OpenLaszlo, вартість, як очевидно, не є проблемою, проте в багатьох компаніях проводиться досить жорстка політика проти використання ПЗ з відкритим вихідним кодом, тому OpenLaszlo не є для них альтернативою.


IBM Workplace Managed Client і Lotus Expeditor


І IBM Workplace Managed Client, і Lotus Expeditor побудовані на основі відкритого коду EclipseRPC. В основі технології EclipseRPC лежить робоча середу інструментів розробки Eclipse, загальна платформа, керована і контрольована eclipse.org. Якщо відповідно до вашого бізнес-вимогами необхідні від’єднані операції і ви можете встановлювати компоненти на клієнтській машині, Workplace Managed Client та / або Lotus Expeditor – кращі технології для створення і розгортання додатків.


IBM Workplace Managed Client є компонентом сімейства продуктів IBM Workplace. Воно об’єднує різні сервіси для спільної роботи в одну інтегровану середу, або середу робочого столу. У ній є такі можливості як управління документообігом, робота з повідомленнями (в тому числі і миттєвими), Web-браузинг, прямий інтерфейс до Notes ® 7, eLearning, підтримка team spaces, Web-конференції, а також функція activity explorer для відстеження потоків, пов’язаними з робочими завданнями. Lotus Expeditor надає розширену клієнтську платформу, яка підтримує корпоративні додатки, транзакції, управління пристроями і Web-сервіси. Є багато причин вибрати Workplace Managed Client або Lotus Expeditor. Workplace Managed Client зазвичай є кращим вибором в тому випадку, якщо ваш додаток за природою своєю коллаборатівно. Якщо ж додаток більше призначено для роботи з транзакціями, зазвичай рекомендують Lotus Expeditor.


І Workplace Managed Client, і Lotus Expeditor дозволяють розробникам створювати розширені клієнтські програми, що встановлюються на клієнтській машині, а також додавати в них підтримку від’єднаних операцій. Оскільки додаток встановлюється на клієнта, клієнт може найбільш повним чином використовувати потужності робочої станції, на якій він працює, що дозволяє вам створювати привабливу і зручне середовище для користувачів. Загальна і для Workplace Managed Client, і для Lotus Expeditor основа Eclipse надає незалежну від ОС платформу, яка приховує від вас нюанси операційної системи, в той же час застосовуючи рідні служби ОС, де це можливо. Це дозволяє вам розробляти загальний основний Java-код, що виконується і в Linux ™, і в Windows ™, а в майбутньому і на Macintosh.


Щоб отримати максимальну вигоду від цієї технології, вам потрібно проектувати ваші програми таким чином, щоб задіяти архітектуру плагінів Eclipse. Компоненти для користувача інтерфейсу створюються за допомогою віджетів SWT (Standard Widget Toolkit) або компонентів jFace. SWT – це набір віджетів та графічна бібліотека, інтегрована в рідну віконну систему, але з ОС-незалежним API, а jFace – інструментарій для користувача інтерфейсу, реалізований за допомогою SWT, який спрощує багато типові задачі з програмування користувальницького інтерфейсу. jFace не залежить від віконного менеджера ні в плані API, ні в плані реалізації, і призначається для роботи з SWT, не приховуючи останній. Кінцевим результатом є більш висока інтерактивність і зручність користувача, відчуття нагадують роботу зі знайомими користувачеві додатками операційної системи.


Нарешті, той факт, що заснованими на Workplace Managed Client або Lotus Expeditor додатками можна управляти через сервер, відрізняє їх від рідних Windows-додатків. Ця ключова можливість зводить до мінімуму, якщо повністю не ліквідує всі витрати на системне адміністрування, пов’язане з розміщеним на клієнтах кодом додатків. В результаті, підприємство, розгортає додаток отримує все переваги володіння розгорнутих на сервері додатком Java EE, а користувач – зручне у користуванні, “заточене” під конкретну ОС і встановлюється на клієнті додаток; це виграшне рішення для більшості організацій.


Faces Client Components


JavaServer Faces (JSF) – це компонент Java EE 1.4, спочатку розробляється як JSR 127. Ключовою метою даної технології було знизити рівень кваліфікації Java-розробників, необхідний для розробки користувальницьких інтерфейсів для своїх додатків Java EE. Так як JSF є робочим середовищем, в ній є багато готових можливостей, які в минулому розробникам доводилося програмувати вручну при створенні такого ж інтерфейсу за допомогою JavaServer Pages (JSPs).


Наприклад, припустимо, що у вас є великий набір результатів JDBC ™, який необхідно відобразити для користувача. Робоча середу JSF надає віджет DataTable, який можна використовувати для відображення даних. Якщо ви вже створили користувальницький інтерфейс за допомогою простих JSP, вам доведеться керувати взаємодією користувача з таблицею і визначити, які рядки даних повинні виводитися користувачеві.


В JSF DataTable, коли користувач натискає Next, щоб відобразити наступні x рядків даних у таблиці, робоча середу JSF буде обробляти запит Next, і вам нічого не потрібно кодувати самостійно. Поряд з тим, що JSF полегшує вам створення розширених HTML-заснованих користувальницьких інтерфейсів, JSF навмисно зроблено серверної технологією. Запит наступних x рядків даних йде від браузера на сервер, де код робочого середовища JSF обробляє його. JSF вимагає двосторонньої взаємодії з сервером.


Для поліпшення базових JSF-віджетів в IBM Rational ® Application Developer V6 введені Faces Client Components. Faces Client Components – це розширення технології JavaServer Faces, що дозволяє вам виконувати деякі сервіси робочого середовища JSF на стороні клієнта. Наприклад, якщо ви використовували компонент DataGrid Faces в наведеному вище прикладі, відображення наступних x рядків даних не буде вимагати двостороннього взаємодії з сервером.


Використання Faces Client Components природним чином приведе до JSF-розробнику з Rational Application Developer. Щоб використовувати Faces Client Components, ви повинні створити сторінку Faces JSP і вибрати “Basic with client-side data caching (Базовий, з кешуванням даних на стороні клієнта)” в якості моделі. Потім, коли ви конструюєте користувальницький інтерфейс в Rational Application Developer, просто виберіть відповідні елементи управління UI з секції Faces Client Components палітри інструментів в Rational Application Developer.


Багато що відбувається під прикриттям Faces Client Component. Ви завантажуєте JavaScript-реалізації елементів управління JSF в браузер і використовуєте знаходиться на стадії становлення промисловий стандарт Service Data Objects для зв’язку між браузером і сервером. Однак, як це і повинно бути, все протікає непомітно для користувача, він просто зауважує, що додаток реагує набагато швидше, ніж типове браузер-засноване додаток.


Ajax


Ajax (Asynchronous JavaScript and XML), термін, складений Джессі Джеймсом Гарреттом (Jesse James Garrett), є заснованої на стандартах методикою (і конструктивним шаблоном) для розробки перевищують можливості браузерів користувальницьких інтерфейсів для розгорнутих на сервері додатків. Ajax не залежить від використовуваної серверної технології і може працювати з додатками Java EE,. Net та іншими. З Ajax ви пишете код JavaScript на додаток до стандартного HTML і створюєте багатий, інтерактивний користувальницький інтерфейс. Наприклад, JavaScript може виконувати перевірку введення локального користувача, надавати різні режими відображення одних і тих же даних (лінійний графік – таблиця – кругова діаграма), або асинхронно взаємодіяти з серверним компонентом програми через об’єкт XMLHTTPRequest браузера.


Відповідно до звіту Gartner Group під назвою Цикл ажіотажу навколо нових технологій (Hype Cycle for Emerging Technologies 2000, 18 липня 2006 р.), Ajax вже досяг “Піка завищених очікувань” і тепер знаходиться на стадії “Улоговина розчарувань.” Ви також можете оцінити ажіотаж навколо Ajax за кількістю продаваних в магазинах книг. На мою думку, три речі допомогли Ajax подолати технологічну прірву Джеффрі Мура:



  1. Сучасні браузери. У минулому, розробникам JavaScript доводилося справлятися з численними несумісності між Netscape, Internet Explorer і іншими браузерами. В деяких випадках навіть різні версії одного браузера були несумісні. Хоча деякі з цих несумісності як і раніше існують, більшість інтранет-додатків зазвичай вимагають Internet Explorer 5.5 і вище і / або Firefox 1.0 і вище, де більшість цих раніше існуючих проблем з несумісністю були вирішені. Недавно був також утворений відкритий промисловий консорціум, OpenAjax, який повинен займатися проблемами несумісності в Ajax, як та іншими пов’язаними з Ajax питаннями.
  2. Інструментарії Ajax. У минулому, більшості розробників, які хотіли працювати з Ajax, доводилося починати практично з нуля, виконуючи велику кількість рутинних операцій, які тепер можуть виконувати інструментарії Ajax. Інструментарії забезпечують різні вбудовані JavaScript-засновані елементи управління користувальницького інтерфейсу (віджети), щоб полегшити розробникам створення заснованих на Ajax інтерфейсів. Інструментарії також звичайно надають більш високий рівень абстракції, приховуючи від розробника вищезгадану несумісність браузерів.
  3. Інструменти. До недавнього часу, більшість розробників JavaScript практично не мали інструментів розробки, які могли б їм допомогти при налагодженні і взагалі полегшити їм життя. З моменту виходу браузера Firefox, в ньому були деякі корисні плагіни для розробників Ajax, а IBM недавно інтегрувала набір корисних технологій в Ajax Toolkit Framework з метою допомогу у вирішенні цієї проблеми. В ATF (Ajax Toolkit Framework), який можна завантажити безкоштовно з сайту Apache, є заснована на Eclipse Ajax середу розробки. В ATF також є такі інструменти, як чутливий до синтаксису редактор JavaScript, консоль JavaScript і просмотровщик об’єктів XMLHTTPRequest . Крім того, в ATF вже вбудовані Dojo, Zimbra і Rico.

Нарешті, на мою думку, зоряний час Ajax настав, коли Google випустив бета-версію свого заснованого на Ajax додатки Google Maps. Будь-яка людина, який раніше працював з картографічним Web-сайтом, швидко помітив перевагу ПО Google над іншим подібними інтернет-сайтами. Поки неспеціалісти дивувалися і гадали, як же Google зробив це, програмісти, які дивилися глибше, виявили там Ajax, і почали міркувати, як би і їм використовувати технології на його основі для поліпшення зручності користування і швидкості реакції власних додатків.


Чистий HTML


Хоча багато розробників і вважають, що у всіх користувачів, як і у них самих, варто останній Firefox з десятьма найпопулярнішими плагінами, насправді на багатьох машинах для доступу в інтернет як і раніше використовуються Netscape 3.x або Internet Explorer 4.x. Браузери цього рівня можуть застосовуватися з метою доступу до певної програми (вихідні коди якого втрачено і його не можна змінити), або ж вони можуть просто бути встановлені вдома у консервативного користувача, продовжує використовувати Internet Explorer 4.0, лише тому, що він дотримується принципу “працює – не чини” відносно поновлення браузера.


Хоча цілком очевидно, що HTML не може забезпечити такої зручності користувача, як будь-яка з перерахованих вище технологій, засновані на HTML інтерфейси в довгостроковій перспективі як і раніше будуть відігравати важливу роль. Ніяка інша технологія не дозволить додатком бути доступним для такого великого числа користувачів, як чистий HTML. В результаті багато додатків, як і раніше будуть надавати такі інтерфейси ще багато років.


На закінчення


У загальному і цілому, основним напрямком в промисловості сьогодні є поліпшення зручності роботи користувача з серверними додатками. Ajax, хоча й ще не зовсім зрілий, уже набрав більших обертів, і багато підприємств, великі і малі, починають використовувати його у виробництві. Інші згадані у статті технології мають мало шанувальників, але на даний момент жодна з них ще не розкрутилася по справжньому.


Існують і інші технології для користувача інтерфейсу, як комерційні, так і вільні (наприклад Nexaweb, Backbase і JackBE), але в статті про них мова не йшла з метою стислості. Важливо те, що не одна з цих технологій не є універсальною і всеохоплюючою, отже, ні одна не підходить повністю у всіх ситуаціях. Кожна з перерахованих вище технологій має свої переваги і може бути хорошим вибором в залежності від обставин.


Так як же робити вибір? Для початківців немає нічого краще старого доброго HTML, якщо вибір технології мотивується максимальної користувальницької аудиторією. З іншого боку, якщо вам потрібні від’єднані операції, і ви можете встановлювати ваш додаток на машини користувачів, найкращим вибором буде одна з альтернатив на основі EclipseRPC, Workplace Managed Client або Lotus Expeditor.


Якщо вам потрібно багатий користувальницький інтерфейс, що володіє точністю і надійністю Flash Player, можливо, буде виправданий вибір Flex або OpenLaszlo. Якщо ви створюєте додатки з допомогою JavaServer Faces, краще вдатися до Faces Client Components.


Нарешті, якщо ваша мета – просто заткнути дірки в існуючому HTML-інтерфейсі або розробити заснований на стандартах, не вимагає плагінів користувальницький інтерфейс з функціональністю, краще ніж у браузерів, ваш вибір – Ajax. В даний момент “циклу ажіотажу”, Ajax, здається, стає найпопулярнішою технологією Web 2.0, але я б не став списувати з рахунків інші технології – вони візьмуть своє, коли змужніють.


Ключем до правильного вибору є вимоги до додатка, якими слід керуватися при виборі технології створення користувальницького інтерфейсу. Хоча ця рекомендація здається простою і очевидною, в багатьох випадках розробники роблять якраз все навпаки, що може привести до багатьох проблем при реалізації і розгортання (що в свою чергу викликає значні затримки та ускладнення при розробці проекту). Не допускайте, щоб це відбувалося і з вами.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*