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

Уявіть собі, що вам поставили завдання створити новий додаток, що буде існувати в світі 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>

*

*