> Frank Lawlor wrote: > > Because this needs to be open-ended and > > dynamic, my project managers can easily > > define a new 'page type' and define the beans > > they will provide to these client pages. To make this > > easy to use yet flexible, they use JSPs to define > > the beans to be passed for any page type. E.g.: > > Ted Husted wrote > > The project managers would define ActionForm beans, and map these to > Action in the Struts-config. You would then not need to > define the beans > in the JSP. The Struts html:form tag takes care of this. It sees where > you are submitting the form, and then looks for or creates the > appropriate bean. No scriptlets needed. > ...
Thanks for the response. My concern with this is that it means deploying new classes, updating the config, possibly restarting the app, etc. With my current approach it usually just means the definition of a simple JSP (understood technology) and uploading the file to a directory. Then there is still the issue of dynamically invoking a client-defined JSP. Currently I use an XML file to define the dynamic JSPs. There is an easy client interface to pick the desired 'style' for any page type. Using the struts approach would mean some kind of dynamic generation of the forwards and reprocessing. I guess I'll have to see if I can integrate my current design w/struts, but I hate having multiple ways of doing the same sort of thing. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
