I agree that is the first priority ... normally the JSP input fields will not take a lot of time to do, I was thinking of using tagged values for that feature. Although I try to avoid them as much as possible I see no alternative unless I rework the complete cartridge, as you know I wrote the cartridge while having in mind that generating these input fields are not top priority, to me it was more important to have something easy to use and intuitive to model in a CASE tool
anyway, the solution I have does not impose any constraints on the modelling and is fully optional (users may choose not to specify the input field names): you select an ActionState in the model (JSP) and add a tagged value for each input field you want to have rendered into it
currently (as in CVS) the cartridge generates /all /known input fields into the form, since the JSP will surely by edited manually by the user I think it is no problem to just select the ones you need and remove the others (I you would need to)
to give you an idea of the 'problems' I was facing, here are some things to consider:
1. we model FormBeans and JSPs, we need a way to minimize the need to
synchronize between the two (when a field name changes in the bean
you need to update the JSP also = undesired & error prone), so I
wanted to avoid modeling the same things twice... especially
methods (methods in form beans, what do you think about that ?
personally I don't like them, but if there are some arguments pro
I would like to hear them)
2. what if a JSP has no associated form ? /[easy]/
3. what if the user wishes not to post a form, but use a hyperlink
instead (using a query construct like this:
?key=value&key2=value2&...) ?
4. it is desired to generate a JSP that deploys right-away ? /[I
guess so]/
5. /.../when I wrote the current version of the cartridge I considered these points and made a trade-off between flexibility, user-friendlyness and time-to-implement, but the time has indeed come to revise these points; therefore I would like a second opinion on how such a cartridge ought to work with AndroMDA, maybe some feedback could be incorporated into the alpha release
about the metamodel decorators, I did not have the time yet to take a look at them, but I suppose I will be able to adapt the current code without to much hassle
can we schedule the release for mid-january ? can someone help me test the cartridge for bugs (it always works on my machine :-) )
b-bye Wouter.
Matthias Bohlen wrote:
Hi Wouter,
I'd like to come out with an alpha release of the cartridge as quickly as possible. Therefor, I'd like to see JSPs with input fields and the conversion to metamodel decorators before we tackle a new feature like the use of XDoclet. I think, that way, we'll maximize the benefit for our users.
Ideas? Matthias
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wouter Zoons
Sent: Wednesday, December 10, 2003 4:33 PM
To: AndroMDA Devel
Cc: [EMAIL PROTECTED]
Subject: Re: [Andromda-devel] bpm4strus X xdoclets
hello AndroMDA Devel,
I have already been thinking about this and we should go for it... currently I only have had a little time to assess the current situation with the cartridge and foresee any possible issues, one of the main reasons I want to go for it is the ability to generate code for the Validator plugin, but since that framework is relatively new to me I have not implemented anything yet
if you have any ideas feel free to let me know here on the andromda-devel mailing list, if we agree we can add a feature request (RFE) and get the ball rolling
regards Wouter
AndroMDA Devel wrote:
Hi developers,bpm4struts doesn't
I have being working with AndroMDA, mainly with bpm4struts and hibernate cartridges, and I could not understand why
use xDoclets... Is there some issue with xDoclets I shouldknow before
start writing cartridges ?
Walter
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
