[Java/Struts] Dynaforms of gewone forms?

[ACM]

Ik heb uiteenlopende meningen over het nut van dynaforms gezien, enerzijds zou het handig zijn om de boel in je xml te specificeren, maar anderzijds heeft dat weer enkele nadelen.

Op het moment heb ik een vrij eenvoudige classboom van forms, die globaal de structuur van de (data)klassen volgt waar de bewerkingen op plaatsvinden. Hierin kan je allerlei werk in superklassen laten uitvoeren en andere controles in utility-methoden. Toch is het niet helemaal ideaal (hoewel zeker niet onwerkbaar).

Ik zie in globaal drie mogelijkheden voor forms in Struts en vraag me nu af welke de beste is:

1. Doorgaan met wat ik nu heb, gewone ActionForms en daarin gewoon een validate-methode (die o.a. super.validate() aanroept).
2. Doorgaan met wat ik nu heb, maar de validate-methoden vervangen door het validator-framework.
3. Alles overboord gooien en de boel vervangen door DynaValidatorForms

A. heeft als voordeel dat alles compile-time te controleren valt en het nadeel dat het vrij veel declaratief werk is, hoewel dat met een fatsoenlijke IDE best meevalt, door het automatisch aanmaken van getters/setters en code-completion.

B. heeft als voordeel dat het gros compile-time gecontroleerd wordt, maar het rotwerk (het valideren) wat vereenvoudigd kan worden (is dat eigenlijk zo?).

C. Zou als voordeel moeten hebben dat je alles in xml definieert en je dus helemaal niks hoeft te programmeren. Eerlijk gezegd heb ik niet het idee dat het dan ook minder (tik)werk is dan een klasse maken, nu moet je alle losse velden specificeren in je xml, anders doe je dat in een java-klasse en gebruik je de code-completion om het gros van je werk te doen. En een ander voordeel dat er zou bestaan is dat je de boel niet hoeft te recompilen als je wat wijzigt... Meestal wijzig ik een form pas als ik een andere klasse wijzig, dus dan moet ik toch compilen en voor een wijziging aan de xml moet de webapp ook herstart worden (sterker nog, dan moet ie eerder herstart worden dan voor een klasse-wijziging).
Verder heeft het als nadeel dat je overal .get("bladiebla") aanroept, wat niet tijdens het het intikken van je code of het compileren gecontroleerd kan worden en meer werk is dan get{evt eerste paar letters}{evt pijltjes}( in je IDE intikken En je hebt ook weer het probleem dat je de boel op drie plaatsen, ipv slechts twee synchroon moet houden (in je jsp, in je xml en in je code).

Eigenlijk zie ik dus niet zo goed waarom men zo enthousiast over C is. De validatiecode overhevelen naar (kortere) xml-code zie ik wel het nut van in, denk ik, vandaar dat voorlopig mijn voorkeur naar B uitgaat.

Maar mijn vraag is natuurlijk: heb ik het mis? Is C toch beter en zie ik het gewoon niet goed?

[CubicQ]

Persoonlijk heb ik alleen met A gewerkt. Maar ik heb ook niet echt het idee gehad dat het inkloppen van de Forms nou zo'n probleem was. Het in een .java bestand intypen van de variabelen en de IDE je getters en setters laten genereren is net zo snel als het intypen van je variabelen in een .xml bestand lijkt me. (En bovendien: je Forms kosten misschien 5% van je programmeertijd, het echte werk zit (hopelijk ) ergens anders)

C (en in mindere mate) B heeft ook als nadeel dat je een stuk flexibiliteit inlevert. Wanneer je iets wilt doen met Forms dat niet standaard door Struts ondersteund wordt, zit je meteen met een probleem.

[momania]

CubicQ schreef op 14 juli 2004 @ 21:16:
C (en in mindere mate) B heeft ook als nadeel dat je een stuk flexibiliteit inlevert. Wanneer je iets wilt doen met Forms dat niet standaard door Struts ondersteund wordt, zit je meteen met een probleem.

Daarvoor kan je toch nog altijd je eigen afgeleide maken van een dynaform of validatorform?
Dus qua flexibiliteit inleveren zal het wel meevallen denk ik.

In princiepe ben je met variant C het meest flexibel, omdat je geen geen tot weinig code aanpassingen hoeft te doen als een form wijzigd.

Zelf gebruik in nu variant B. Daarbij heb je niet alleen het gemak dat de validatie makkelijk aan te passen is, maar ook dat het gelijk allemaal geinternationaliseerd is wat je gewoon een hoop extra programmeer werk scheelt als je dat allemaal zelf moet doen in variant A.

Variant C heb ik zelf nog niet echt goed bekeken en geprobeerd, maar ik ben bang dat het voor sommige net zo veel werk zal zijn als variant B en misschien zelfs wel meer.
De C variant is nml. erg typfout gevoelig, waarbij je denk ik soms uren kan lopen zoeken naar een klein foutje in het begin.

[machiel]

Ik vind de dynaforms moeilijker in het gebruik, als er wat fout gaat dan is soms niet duidelijk waarom en waar. Variant B lijkt me de beste voor hergebruik en leesbaarheid van je code.

[ACM]

Zijn er zo weinig mensen die Struts gebruiken hier?
Nahja, op Janoz na is iedereen het hier met mij eens, lijkt het. Dus ik wacht met smart op Janoz' uitleg waarom C zoveel beter is

[misfire]

Variant B is de beste oplossing binnen Struts. Het validator framework geeft een aantal standaard validaties out of the box en je kunt er ook client side javascript validation mee aansturen.

Variant C, de dyna-actionforms hebben alleen maar nadelen en zijn op geen enkele wijze beter dan hun Java tegenhangers. Zoals je zelf al beredeneert levert het geen onderhoudsvoordeel op, en mis je features van Java (IDE's) in het controleren en koppelen van de forms aan de rest van de code. Het is bovendien trager, foutgevoeliger en je kunt het niet uitbreiden met eventuele eigen logica. Ik snap eerlijk gezegd niet waarom ze uberhaupt de moeite hebben genomen om die dingen te maken.

Een ander anti-pattern wat vaak op internet wordt geprezen is het gebruik van 1 uber-formbean waar alle velden voor alle forms in zitten. Dit is ook helemaal niet handig, het is veel beter om de FormBean als een contract tussen je Action en je input te zien. Als je een veldje weghaalt/toevoegd heb je in je Java code meteen een veel beter beeld waar dingen aangepast moeten worden.

[djengizz]

Ik zelf gebruik de DynaValidatorForm i.v.m. met de client side validatie. Voordeel: ik hoef zelf de javascript niet te schrijven. In de StrutsConfig.xml verwijs ik verder naar mijn eigen class die weer erft van DynaValidatorForm (deze class doet tevens de server side validatie). Ik hoef dus in de Struts config geen attributen te specificeren. Uiteraard moet ik wel die velden opgeven waarvoor gevalideerd moet worden in validator.xml. Dit zou ik ook moeten doen als ik de javascript zelf schrijf.
Grootste argument is de client side validatie: dit scheelt toch een call naar de server. Alternatief zou zijn om zelf de javascript te schrijven wat net zo (of meer) fout gevoelig is en moeilijk te debuggen.

[momania]

djengizz schreef op 19 juli 2004 @ 18:07:
Ik zelf gebruik de DynaValidatorForm i.v.m. met de client side validatie. Voordeel: ik hoef zelf de javascript niet te schrijven. In de StrutsConfig.xml verwijs ik verder naar mijn eigen class die weer erft van DynaValidatorForm (deze class doet tevens de server side validatie). Ik hoef dus in de Struts config geen attributen te specificeren. Uiteraard moet ik wel die velden opgeven waarvoor gevalideerd moet worden in validator.xml. Dit zou ik ook moeten doen als ik de javascript zelf schrijf.
Grootste argument is de client side validatie: dit scheelt toch een call naar de server. Alternatief zou zijn om zelf de javascript te schrijven wat net zo (of meer) fout gevoelig is en moeilijk te debuggen.

Als het puur alleen om de clientside validatie gaat dan kan je net zo goed de ValidatorForm gebruiken.

De DynaValidatorForm zou je nodig hebben als je én gebruik wilt maken van het validator framework én van het Dyna gedeelte.

Als je het Dyna gedeelte niet gebruikt, bied de ValidatorForm net zo veel mogenlijkheden als de DynaValidatorForm