Hi Woulter, Are you going to repeat the getters and setters on the form implementation class ? It seens a bit confusing in case of refactoring...
I know I'm insisting, but what do you think about using XDoclets tags, like the hibernate cartridge ? I like this way very much because, despite formal discussions, we can improve the generated code using "tagged values" to create XDoclets tags/parameters... Just as an example, I changed the hibernate cartridge the following way: - if you insert the tagged value "@hibernate.column.unique=true", the Java/XDoclet code is generated with "* unique = true" to that property. - if you insert the tagged value "@property.validation.maxIntValue = 5" the template generates validation code inside the java class that raises an exception avoiding the save/update in case that property has a value above 5. In struts case I think it could be used in many ways, primary in validations (java and struts) and completing the struts-config.xml, inserting plug-ins (I have this trouble now), external forms, actions and so on... If you use the XDoclets I will make the improvements. Regards, Walter --------------------------------------------------------------------------- Walter Itamar Mourão - Diretor de Tecnologia e Projetos - Arcadian S/A www.arcadian.com.br "Wouter Zoons" <[EMAIL PROTECTED]> grava: >hello everybody, > >this weekend I will continue to work on the struts cartridge, there are >some important changes but I would like this opportunity to collect the >final details of the changes that will go into the next release > >1. generation of compilable JSPs >2. no more tagged values on dynamic model, only in static model >3. form beans will also have an abstract parent class > > I have been working like a madman lately, also on a personal project, I >am using this cartridge and I found some interesting issues with the >current cartridge, they have been resolved in CVS (I think, not sure) but >I now have the feeling that the next release will be quite stable and >intuitive ... user-friendlyness, right ? > > > >1. generation of compilable JSPs > > > >this allows a generate and deploy strategy, although action classes still >need to be implemented manually >the idea is to allow the user to change as little as possible > > > > > >2. no more tagged values on dynamic model, only in static model > > > >reason being the static model is closest to the implementation anyway, I >like to keep the modeling of dynamic processes clean > > > > > >3. form beans will also have an abstract parent class > > > >this allows to add optional XDoclet tags into the implementation class, >eg. for validation > > > > > > > > >Please add your comments to this mail or something, or simply reply ... I >will collect all feedback and take them into account during development > >bye > >Wouter. ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Andromda-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-user
