Ajax за Java разработчици, част 2
В първата статия от тази поредица представих Ajax block building:
* Как да използвате обекта XMLHttpRequest за изпращане на асинхронна заявка до сървъра от уеб страница * Как да обработите и отговорите на заявка с Java сървлет, връщайки XML документ на клиента * Как да използвате документ с отговор на клиентска заявка, за да актуализирате външния вид на вашата страница
Засега ще продължа да обсъждам основите на разработката на Ajax, но ще се съсредоточа върху това, за което много Java Web разработчици се интересуват най-много: създаване на данни за клиента.
Ще използвам едно илюстративно приложение и няколко случая на употреба, за да илюстрирам характеристиките на технологията и техниката, които ще бъдат обсъдени тук. Фигура 1 показва изключително прост модел на данни, който илюстрира случаите на използване на примера. Моделът представлява акаунт на клиент във функциониращ онлайн магазин. Клиентът разполага с набор от предишния ред покупки, всяка от които се състои от няколко продукта.
Фигура 1. Прост обектен модел
Въпреки че XMLHttpRequest не налага ограничения върху формата, използван за изпращане на данните за заявката, в повечето случаи е за предпочитане да се изпращат само нормални параметри на формуляра, така че ще се съсредоточим върху заявката на сървъра в тази дискусия. Заявката може също да бъде във всеки текстов формат, но поради конвенцията за именуване, XMLHttpRequest има вградени възможности за работа с XML данни за заявка. Това прави XML добър избор за Ajax заявки по подразбиране, тъй като е доста удобно да започнете.
XML от Java класове
Има много причини да разгледате заявките за AjaxXML представяне: Всеки браузър, който поддържа Ajax, има методи за навигиране на XML документи и има много технологии за работа с XML данни на сървъра. Много е лесно да разберете връзката между вашия Ajax клиент и сървър, като използвате схемата на типа документ, която се променя, и ако възприемете удобен за услугата подход към архитектурата на сървъра, използването на XML ще позволи на клиентите, които не са Ajax, да разберат вашите данни перфектно.
Ще разгледам три начина, които можете да използвате за генериране на XML данни от Java обекти, и ще разгледам плюсовете и минусите на всеки от тях.
Изпълнете своя собствена сериализация
На първо място, можете да генерирате XML директно от вашата обектна графика. Този подход може да бъде толкова прост, колкото метода toXml() във всеки от вашите JavaBean класове. След това можете да изберете подходящ XML API и да направите изглед за всеки излъчван bean и рекурсивно да извикате компонентите на обектната графика. Ясно е, че такъв метод няма да се справи с голям брой класове, тъй като всеки клас ще трябва да напише свой собствен XML-генериращ код. От друга страна, това е доста прост метод за внедряване, който не се претоварва с допълнителна конфигурация или все по-сложен процес на изграждане и не изисква друга схема, съставена от вашите JavaBeans, която може да бъде превърната в XML документ с няколко извиквания.
В примерния код на предишната статия от тази поредица внедрих методите toXml() чрез добавяне на XML низове. Както споменах по-рано, това е ограничен метод, защото въвежда много код за валидиране на предвидени връзки, криптирани данни и т.н. за всеки метод toXml(). Няколко XML API са налични в Javaплатформа, която да върши цялата тази работа вместо вас, като ви позволява да се концентрирате върху XML съдържанието. Списък 1 използва toXml() за внедряване на класа, който представлява опашката в примерната база данни (вижте Фигура 1).
Листинг 1. JDOM реализация на toXml() за класа Order
Сега виждате колко лесно е да създавате елементи, да задавате атрибути и да добавяте съдържание на елементи с помощта на JDOM. Рекурсивните извиквания за съставяне на методите toXml() на JavaBeans са за представяния на елементи на техните подсхеми. Например, съдържанието на елемента items се генерира тук чрез извикване на toXml() на всеки обект Item, който се брои като поръчка.
След като всички ваши JavaBeans са изпълнили метода toXml(), ще бъде лесно да сериализирате произволна обектна схема в XML документ и да я върнете на Ajax клиента, както е показано в листинг 2.
Листинг 2. Генериране на XML заявка от JDOM елемент
JDOM ще направи живота ви по-лесен отново. Просто трябва да създадете документ за XML елемента, върнат от обектната схема, и след това да използвате XMLOutputter, за да пренапишете сървъра на заявката. Листинг 3 показва примерен XML, направен по този начин, форматиран чрез инициализиране на XMLOutputter с Format.getPrettyFormat() JDOM. В този случай купувачът е направил единствената възможна поръчка, състояща се от две неща.
Листинг 3. Примерен XML документ, представящ клиент
Недостатъци на стартирането на собствена реализация
Интересното е, че кодът в листинг 7 показва един от основните недостатъци на ръчното сериализиране на JavaBeans в XML. Представете си, ако този документ се използва за представяне на историята на поръчките на клиента. В този случай вероятно не искате екранът да има пълно описание на всеки елемент, преминал опашката, или дана потребителя беше казано пълното му име. Но ако приложението имаше клас ProductSearch, който връща резултатите от търсенето като списък от компоненти Item, би било много полезно описанията да са включени в Item, представящи текущото ниво на склад, което може да бъде полезна информация за показване в списъка Product Search. След това обаче това поле може да бъде сериализирано от друга обектна схема, която включва артикул, въпреки неуместността на текущото ниво на наличност за хронологията на поръчките на купувача.
От гледна точка на разработката това е класически проблем с модела на данни, съчетан с генерирането на изгледи. Всеки bean може да се сериализира само по един начин и общият метод означава, че взаимодействията на Ajax ще завършат с обмен на данни, от който не се нуждаят, което затруднява клиентския код да локализира информацията, която изисква от документа, и увеличава количеството обработка и времето за анализ на XML на клиентската машина. Друго следствие от тази връзка е, че XML не може да бъде създаден независимо от Java класовете. Например, за да направите промени в документ за клиентска схема, може да е необходима група от няколко Java класа, които след това си струва да бъдат модифицирани и повторно компилирани.
Ще навляза в тези подробности малко по-късно, но засега нека да разгледаме решението за разширяване на вашите собствени програми за стартиране на сериализация: XML свързващата структура.
Обвързваща XML структура
Наскоро бяха разработени няколко Java интерфейса (API), за да се опрости процеса на свързване на XML документи и представяния на схема на Java обект. В повечето случаи XML маршрутизирането се поддържа и не се поддържа: и в двата случая се извършват двупосочни преобразувания на Java схеми.обекти в XML представяне. Тези структури обхващат цялата работа по поддръжката на XML, което означава, че кодът на приложението сега трябва да бъде написан само за обикновени Java обекти. По-скоро те също са предназначени да осигурят полезни функции на приложението, като валидиране. Най-общо казано, тези структури съдържат два различни подхода: генериране на код и картографиране на "XML обект". Ще обясня и двата подхода.
Метод за генериране на код
Схемите за свързване, които включват генериране на код, се изпълняват с помощта на програми като XMLBeans, JAXB, Zeus и Jbind. Кастор също може да приложи тази техника. Началото на всяка структура е XML схема, която описва типовете данни на вашите документи. Като използвате възможностите, предоставени от структурата, вие след това генерирате Java класове, които представляват тези дефинирани от схема типове. И накрая, вие пишете вашето приложение, като използвате тези генерирани класове, за да представите данните на вашия модел и да го сериализирате в XML, като използвате удобен механизъм, управляван от структура.
Подходът за генериране на код е много добър, когато вашето приложение обработва голямо количество XML данни. Съществува определен проблем с писането на нормална XML сериализация на методи за десетки класове. От друга страна, вече не е необходимо да дефинирате свои собствени JavaBeans. Генерираните от структури Java класове обикновено следват XML структури, което може да ги направи изключително тромави за кодиране. Генерираните класове понякога се превръщат в боклук, тъй като не можете просто да добавите тип към тях. Образно казано, ще трябва да правите компромиси в кода на вашето приложение, за да си играете с типовете, генерирани от struct, до насита. Друг "клопка" е, че промяната в схемата ще доведе домодификации на генерирани класове, което може да причини голяма вреда на приложения, написани с такива класове.
Тези видове XML обвързващи структури са най-полезни при локализиране на данни (т.е. използване на XML документи и конвертирането им в Java обекти). Докато нямате голям модел на данни и искате да се възползвате от използването на класове, генерирани за вас, структурите, базирани на генериране на код, може да са излишни за Ajax приложения.
Дисплеи
Структурите, които създават съпоставяния, са включени в програми като Castor и Apache Commons Betwixt. Картографирането обикновено е по-гъвкаво и леко от генерирането на код. Първо, вие кодирате своите JavaBeans по начина, по който бихте го направили обикновено, включително всякакви типове и всякакви методи, които са удобни за вас. Второ, по време на изпълнение вие извиквате рутера за интроспекция на структурата и той създава XML документ въз основа на типовете, имената и стойностите на компонентите на вашите класове. След като дефинирате съпоставянето на файлове във вашите класове, можете да замените стратегията за свързване по подразбиране и да декларирате рутера, за да съответства на начина, по който вашите класове ще бъдат представени в XML.
Този метод е най-добрият компромис между мащабируемост и гъвкавост. Можете да пишете вашите Java класове, както искате, и рутерът ще ви спести неприятностите при работа с XML. Въпреки това, докато дефиницията на файловете за картографиране е лесна за писане и доста последователна в картографирането, правилата за картографиране могат да се променят само според стандартното поведение на свързване и винаги ще остане известна степен на сплотеност между структурата на вашия обект и неговото XML представяне. В крайна сметка трябва да можете да намерите компромисили във вашите Java изгледи, или във вашия XML формат за това как работи методът на картографиране.
Резюме на обвързването на данните
Денис Сосновски е написал доста статии по темата за интерфейсите за свързване на XML данни (API) както за генериране на код, така и за показване на код. Бих препоръчал да прочетете отличните му статии за Castor и рамки за генериране на код, ако искате да напреднете допълнително в тази област (вижте Ресурси за връзки).
Като цяло, подходът за генериране на код няма достатъчно гъвкавост и удобство, за да бъде полезен в типичните Ajax приложения. От друга страна, структурите, базирани на картографиране, могат да ви служат доста добре, ако можете да приспособите стратегии за картографиране, за да произвеждате XML от вашите обекти.
Всички интерфейси за обвързване на XML страдат от един основен недостатък на техниката за ръчна сериализация: обвързване на модел и изглед. Поради ограничението до едно XML представяне за всеки тип обект, големи количества ненужни данни преминават през мрежата. По-сериозен проблем е неспособността на клиентския код да поддържа персонализирано представяне, когато ситуацията го изисква, и евентуално загуба на време в опити за намиране на общо представяне на схемата за данни на обекта.
В традиционното разработване на уеб приложения системите за шаблони на страници се използват за ясно разделяне на изгледа за генериране от алгоритъма на контролера и моделните данни. Това е техника, която може да помогне и при работа в Ajax скриптове.
Системи за шаблони на страници
Всяка широко използвана технология за шаблон на страница може да се използва за генериране на XML, позволявайки на приложенията на Ajax да създават XML документ с произволна заявка от неговия модел на данни. Плюс това, мостри могат да бъдат написани с помощта напрост и изразителен език, за разлика от редове код, написани на Java. Списък 4 е JSP страница, която декларира Customer bean и връща нормално XML представяне, подходящо за клиентски код за създаване на компоненти за история на поръчките.
Листинг 4. JSP страница, която създава компонента за история на поръчките
Този много кратък шаблон извежда само данните, необходими за изгледа Хронология на поръчките и не съдържа данни като описание на всеки продукт. И това може да се направи толкова лесно, колкото създаването на обикновен XML за представяне на търсене на продукти, което включва пълно описание и ниво на наличност за всеки артикул.
Проблеми при използване на шаблони
Недостатъкът е, че трябва да създадем нов JSP за всеки отделен изглед, от който се нуждаем, вместо да съставяме необходимите схеми на обекти и да ги сериализираме. От гледна точка на разработката мнозина биха казали, че това така или иначе би било изходът, тъй като означава формално боравене с типовете документи, които сървърът ще произвежда. Освен това, тъй като сега работим главно със средата на шаблона, а не в специфични интерфейси (XML API), ще бъде моя отговорност да се уверя, че препратките са дефинирани, елементите и редът на атрибутите са правилни и всички грешки (например,