• No results found

XMLHelper 31

In document PTM, the next iteration (pagina 42-45)

9   ARCHITECTUUR & TECHNIEK 26

9.3   DATA OVERDRACHT 28

9.3.4   XMLHelper 31

Tijdens het ontwikkelen van de applicatie werd snel duidelijk dat er generieke code opgezet moest worden voor het afhandelen van de encodering van en naar XML van de Entity Beans.

In de oude code werd voor elke Entity Bean die gebruikt werd aparte code geschreven voor het coderen en decoderen naar XML. Samen met het afvangen van alle uitzonderingen levert dit veel code op die niet goed te onderhouden was en zeer bewerkelijk en tijdsconsumerend is om op te zetten.

Hier is toen een oplossing voor geschreven met behulp van Java Reflection. Reflection is een binnen Java beschikbare functionaliteit om van een object de klassen, interfaces, methodes, variabelen, etc op te vragen. Alle in de broncode omschreven informatie is via Reflection opvraagbaar en aan te passen. Omdat er een groot verschil bestaat tussen het decoderen van XML en het encoderen naar XML worden deze twee processen los van elkaar behandelt in “Encoding” en “Decoding”

Encoding

De Entity Bean Project bestaat uit verschillende publiek beschikbare “get”, “set” en “is” methodes, met een bepaald type voor invoer of uitvoer. Voor het Encoderen van een project naar XML worden de publieke “get” en “is” methoden gebruikt.

Van elk van zo’n aangetroffen methode wordt de naam, min “get” of “is”, gebruikt voor het aanmaken van een XML tag. De methode wordt vervolgens aangeroepen om de gegevens die deze methode teruggeeft op te vragen en als tekst op te slaan in de tag. Dit levert dus de volgende XML op: <methodenaam>data</methodenaam>

Voor het toevoegen van data aan een XML tag moet deze van het type String zijn. Omdat een “get” een breed scala aan typen kan teruggeven wordt door de XMLHelper gekeken welk type teruggeven wordt en aan de hand van het type wordt dan de benodigde converteer methode aangeroepen.

Op het moment kan de XMLHelper alle types omzetten die een toString methode hebben, JodaTime datums en tijden, en Entity Beans.

JodaTime wordt apart gecodeerd omdat de standaard toString methode geen bruikbare of eenvoudig te converteren String voor de Flex Applicatie oplevert. Aan de hand van de methodenaam wordt daarom ook een JodaTime DateTime object omgezet naar een tijd, dag of een dag en tijd String.

Een methode met de naam getDate met als returntype een JodaTime DateTime object wordt omgezet naar het formaat DD-MM-JJJJ, wat bijvoorbeeld de datum 12-03-2008 kan opleveren. Een zelfde soort conversie wordt uitgevoerd met methodes met in de naam “datetime”, “date”, “day”, “deadline” of “tijd”. Als de XMLHelper geen van de eerder genoemde woorden in de methodenaam vindt dan converteert hij standaard een DateTime naar een string met datum en tijd.

Voor Entity Beans is aparte encodering code geschreven omdat het in bijna alle gevallen alleen nodig is om een ID mee te geven. Bijvoorbeeld het Entity Bean Project heeft een relatie met de Entity Bean Customer. Het coderen van deze Customer Entity Bean is niet nodig omdat deze Customer bijgehouden wordt door andere managers in de Flex Applicatie en op de server andere servlets en facades

verantwoordelijk zijn voor deze Entity Bean. De klant is daarom al beschikbaar binnen de Flex Applicatie of opvraagbaar indien nodig.

Alle tags die genegeerd worden aan de hand van de methode namen worden geplaatst in een tag die gemaakt wordt aan de hand van de klasse naam. In het geval van een Project Entity Bean levert dit de XML tag <project> op. Dit is dan ook de naam die ingesteld wordt in de “nameOfClass” variabele in de ValueObjects die de Flex Applicatie gebruikt.

Decoding

Voor het decoderen van XML data wordt een niet met data gevulde, en niet aan een record in de database gekoppelde Entity Bean doorgegeven met de ontvangen XML data.

De XMLHelper voert vervolgens het tegenovergesteld uit van het in “Encodering” omschreven proces. Als eerste controleert de XMLHelper of de hoofdtag van de doorgegeven XML data overeenstemt met de klasse naam van het doorgegeven object en decodeert de XML data alleen als deze twee overeenkomen. Deze controle wordt uitgevoerd omdat Reflection een vrij kostbaar proces is qua CPU verbruik en door deze controle onnodig decoderen wordt voorkomen.

Vervolgens worden alle “set” methodes afgelopen en gevuld met de gegevens die in XML tags staan met dezelfde naam.

Tijdens het decoderen van een tag met als tegenhanger een methode die een Entity Bean accepteert wordt deze Entity Bean opgezocht in de database en doorgegeven aan de setter. De XMLHelper is zo opgezet dat deze elk willekeurige Entity Bean kan opvragen en invoeren in een “set” methode.

Voor JodaTime wordt alleen gekeken naar de naam om een correcte conversie van String naar DateTime object te faciliteren. Omdat een XML tag een tijd, datum of beide kan bevatten is er verschillende logica nodig om dit correct om te zetten naar een JodaTime DateTime object dat altijd een datum en tijd verwacht.

Voor alle overige methodes wordt gekeken of deze een valueOf methode hebben of van het type String zijn. Alleen deze kunnen generiek afgehandeld worden door de XMLHelper.

Aan het einde van het decoderen zorgt EJB 3.0 er zelf voor dat niet ingevulde gegevens opgehaald worden uit de database. Als er opdracht voor wordt gegeven, worden de nieuwe gegevens opgeslagen in de database.

In document PTM, the next iteration (pagina 42-45)