[alg] codegeneratie + klein beetje ejb/xml

[Alarmnummer]

Ik zit op dit moment met een paar problemen bij het genereren van code.

1) Als je code gaat genereren, hoe ga je om met reeds bestaande code? In java is het wel mogelijk om mbv extenden van classes gebruik te maken van een gegenereerde class en een class die extra functionaliteit nodig heeft. Maar met XML? Ik wil oa de deployment descriptor (EJB) gebruiken om java classes te genereren en om nog een handje vol files te genereren die in 1e instantie vrij voor de hand liggend zijn. Maar uiteindelijk zal ook in die files ge-edit worden (bv de vendor specifieke cmp-jdbc koppeling). Hoe kan ik hier het beste mee omgaan?

2) foutmelding. Als je bv een superformaat gaat maken vanuit waar je bv de deployment-descriptor en alle java bestanden gaat genereren, dan is het heel lastig om foutmeldingen bij bv het verwerken van de deployment descriptor weer terug te koppelen naar het superbestand. Moet ik dan nog de moeite nemen om zo`n super bestand aan te maken? Of moet ik toch eisen dat ze meteen maar met de deployment descriptor en alle extra configuratie bestanden aan de slag gaan?

[Bobco]

Misschien kun je eens kijken naar de manier waarop JAXB Java classes genereert.

[Alarmnummer]

Ik wist niet dat bestond Thanx, ik zal de documentatie even downloaden en meenemen naar huis.

[mbravenboer]

Gegenereerde code moet nooit geedit worden. Het is dan op termijn onmogelijk om de code opnieuw te genereren, waardoor het voordeel van code generatie verloren gaat. Wel is het inderdaad een probleem hoe je gegenereerde code toch graag aan zou willen passen en uit zou kunnen breiden. Ik heb daarvoor eigenlijk nog maar weinig goede oplossingen gezien.

De beste oplossing die ik ken is mijn eigen oplossing: een gescheiden specificatie die samengevoegd worden met de gegenereerde code. Het idee is dat uit de code generator een AST komt (Java bijvoorbeeld). In een gewone source file kan je deze genereerde code aanpassen door gewone Java code te schrijven.

Bijvoorbeeld een include file Customer.java:

code:

public interface Customer extends Person { 
}

Als uit de gegenereerde code een interface Customer komt, zal die uitgebreid worden met de "extends Person" declaratie. Je kan natuurlijk ook methoden, variabelen, imports, statische initializers en dergelijke opnemen. Deze worden ook allemaal gemerged met de genegeerde code. Uiteraard zijn er wel beperkingen: een klasse een andere klasse laten extenden is alleen mogelijk als de gegenereerde code nog geen klasse extend.

Deze methode is met name nuttig voor een code generator die code genereert die eigenlijk niet echt een black box is met maar 1 of 2 entry points. Je hebt dan vaak weinig inzicht (nodig) in de gegenereerde code, waardoor die code ook lastig op deze manier uit te breiden is. Als de code generator meer 'skeletten' genereert, is deze aanpak zeer nuttig.

[mbravenboer]

JAXB is xml data binding: zie ook Castor: http://www.castor.org/

[EfBe]

In LLBLGen Pro gebruik ik het strategy pattern om uitbreidbaarheid te bewerkstelligen plus ik genereer middels templates code die gebaseerd is op een core library. Je kunt dmv het strategy pattern bv property validation rules toevoegen aan bv een customer object wanneer je deze instantieert. Zodoende hoef je de code niet aan te passen maar kun je wel de code uitbreiden.

Dit is IMHO de enige manier om flexibel gegenereerde code uit te breiden. Inheritence is een andere maar je gegenereerde code kent de inherited class niet, dus de extra functionaliteit wordt dan niet benut binnen je gegenereerde code. Ik zou dus kijken naar het strategy pattern.

[Alarmnummer]

mbravenboer schreef op 09 July 2003 @ 10:08:
Gegenereerde code moet nooit geedit worden. Het is dan op termijn onmogelijk om de code opnieuw te genereren, waardoor het voordeel van code generatie verloren gaat. Wel is het inderdaad een probleem hoe je gegenereerde code toch graag aan zou willen passen en uit zou kunnen breiden. Ik heb daarvoor eigenlijk nog maar weinig goede oplossingen gezien.

Een passieve code-generator kan ook handig zijn, zie Code Generator - The Pragmatic Programmer, from Journeyman to Master

De beste oplossing die ik ken is mijn eigen oplossing: een gescheiden specificatie die samengevoegd worden met de gegenereerde code.

Ik weet het nog

Op dit moment zit ik vooral eigelijk met XML files. Aan de gegenereerde javasources voor EJB hoeft niet zoveel veranderd te worden. Het zijn gewoon 'domme' entitybeans met hun getters/setters en create methodes. En verder nog een local-home interface.

Mijn probleem zit hem op dit moment vooral bij het XML gedeelte. Ga ik een superformaat maken vanuit waar ik oa de deployment-descriptor ga genereren en alle andere configbestanden en sources? Of moet er rechtstreeks gewerkt worden in de deployment-descriptor en de andere configbestanden (die in 99% van de tijd geen extra informatie bezitten die ik niet kan afleiden aan de hand van de deploymentdescriptor). En hoe ga je met foutmeldingen om? Zo nu en dan krijg ik al een rolberoerte van de foutmeldingen van EJB (waarom in godsnaam reflectie gebruiken!!!), maar hoe krijg ik die foutmeldingen terug naar zo`n super bestand? Veel fouten kan ik er zelf wel uitpakken, maar queries ga ik echt niet parsen.

[EfBe]

Nog even wat specifiekere antwoorden

Alarmnummer schreef op 09 July 2003 @ 09:43:
1) Als je code gaat genereren, hoe ga je om met reeds bestaande code? In java is het wel mogelijk om mbv extenden van classes gebruik te maken van een gegenereerde class en een class die extra functionaliteit nodig heeft. Maar met XML? Ik wil oa de deployment descriptor (EJB) gebruiken om java classes te genereren en om nog een handje vol files te genereren die in 1e instantie vrij voor de hand liggend zijn. Maar uiteindelijk zal ook in die files ge-edit worden (bv de vendor specifieke cmp-jdbc koppeling). Hoe kan ik hier het beste mee omgaan?

Gebruik config files en cache de results. Alles wat specifiek is moet pluggable zijn, dus dat je het middels generieke interfaces of config files kunt inpluggen in je framework. Dit is jou wel toevertrouwd denk ik . (In .NET gebruik je bv de .config file voor stuurparameters, eventueel om custom assemblies te laden die een generieke interface implementeren. Je app laadt dan de juiste, 'vendor specific' assembly gebaseerd op config parameters, en omdat het een generieke interface is, ziet je code geen verschil).

[Alarmnummer]

EfBe schreef op 09 July 2003 @ 10:24:
In LLBLGen Pro gebruik ik het strategy pattern om uitbreidbaarheid te bewerkstelligen plus ik genereer middels templates code die gebaseerd is op een core library. Je kunt dmv het strategy pattern bv property validation rules toevoegen aan bv een customer object wanneer je deze instantieert. Zodoende hoef je de code niet aan te passen maar kun je wel de code uitbreiden.

Dit is IMHO de enige manier om flexibel gegenereerde code uit te breiden. Inheritence is een andere maar je gegenereerde code kent de inherited class niet, dus de extra functionaliteit wordt dan niet benut binnen je gegenereerde code. Ik zou dus kijken naar het strategy pattern.

Daar zijn wel oplossingen voor te bedenken, SableCC heeft bv een oplossing om een soortement van factory te overriden waar jij je ge-extende classes aan het systeem kan toevoegen ipv de oude.

http://www.sablecc.org/thesis/thesis.html pag 37

[ Voor 4% gewijzigd door Alarmnummer op 09-07-2003 10:31 ]

[Alarmnummer]

EfBe schreef op 09 July 2003 @ 10:29:
Nog even wat specifiekere antwoorden

[...]

Gebruik config files en cache de results. Alles wat specifiek is moet pluggable zijn, dus dat je het middels generieke interfaces of config files kunt inpluggen in je framework. Dit is jou wel toevertrouwd denk ik . (In .NET gebruik je bv de .config file voor stuurparameters, eventueel om custom assemblies te laden die een generieke interface implementeren. Je app laadt dan de juiste, 'vendor specific' assembly gebaseerd op config parameters, en omdat het een generieke interface is, ziet je code geen verschil).

Helaas is de EJB-server degene die alles inleest.

[PommeFritz]

Ik begrijp niet goed wat je aan het doen bent, maar heb je al eens naar XDoclet gekeken?

XDoclet is a code generation engine. It enables Attribute-Oriented Programming for java. In short, this means that you can add more significance to your code by adding meta data (attributes) to your java sources. This is done in special JavaDoc tags.

XDoclet will parse your source files and generate many artifacts such as XML descriptors and/or source code from it. These files are generated from templates that use the information provided in the source code and its JavaDoc tags.

[Alarmnummer]

Met XDoclet kun je van code de deploymentdescriptors en andere configbestanden maken, maar ik wil de andere kant op gaan. Aan de hand van de deploymentdescriptor wil ik alle andere bestanden genereren (en dus ook de sources). Het is uiteindelijk de bedoeling dat iemand (een kennis ingenieur ) een model maakt van een bepaald domein, dat is bij ons altijd iets met recht, bv erfrecht. Aan de hand van dat model, wil ik dan alle EJB sources genereren zodat het expertsysteem wat ik nu aan het ontwikkelen ben, automatisch gekoppeld is aan EJB zonder dat daar nog een programmeur aan te pas hoeft te komen.

[Alarmnummer]

Maar kan iemand me wat advies geven over het verwerken van fouten bij gegenereerde code? Het gaat me voornamelijk om een super-deployment descriptor die alle sources en de normale deployment-descriptor genereerd. Als zich een fout voordoet bij bv het verwerken van een query, hoe krijg ik die foutmelding ooit terug naar zo`n super-deployment descriptor? Volgens mij gaat dat echt een onmogelijke zaak worden. ->

[edit]
*is alleen des morgens aanwezig op zijn werk om mail te checken*

[ Voor 10% gewijzigd door Alarmnummer op 10-07-2003 10:07 ]

[Alarmnummer]

[half-offtopic]
Ik zit er trouwens aan te denken om JDO te gebruiken ipv entitybeans. Mbv de transactie die gedeeld wordt tussen JDO en EJB kan ik alle concurrency zaken oplossen (alhoewel een JDO transactie niet dezelfde mogelijkheden heeft als een EJB transactie) en JDO zorgt voor de rest (oa dat er geen duplicaten van dezelfde entiteiten ontstaan.

[edit]
leuke link

JDO or CMP?

[ Voor 20% gewijzigd door Alarmnummer op 11-07-2003 11:47 ]