Well thats the thing. The action already gets the request and response passed to its execute method. My actual rendering classes are _conceptually_ independent of the response and request. <details> I have a 'rendering pipeline' which is just a collection of 'IDocumentRenderer'. These each have a render() method that takes a Document as input and returns (usually the same but modified) Document. The pipeline is a collection of these which feed the output of one to the input of the next, and IRenderingPipeline has a method which implements this. Documents are obtained by some magic code in an object that implements IDocumentManager - this has the imaginatively named method 'getDocument()' (which takes a string key). The document manager makes use of an object that implements IDocumentFinder (I just love interfaces ;->) which will obtain an InputStream based on the key. In a web application this means making use of the servlet context getResourceStream() method. Some renderers , such as the template renderer need several other documents to do their thing. (The template renderer grabs node trees from several documents and inserts them into several places in the document._ - As the document being rendered to is usually the actual template document the template renderer is almost always first in the pipeline - since it gets the actual content out of another document and slaps it into the template. Once that content is there other renderers that follow can do their thing - ie: render field values, i18n text etc... </details> <but> Now while I said the rendering classes were _conceptually_ independent of response and request, in practice its not always so (The interfaces know nothing of servlets but the implementing classes often have to). For example one of the renderers will set the href for the base tag. To do this it needs the request in order to get path information. Another class I have that is used by a lot of renderers is (an implementation of) IURLRewriter. This object needs the response in order to call the encodeURL() method... Now one of the duties of the controller (action classes) is to select which view to use, and in my case they do this by selecting which renderers to use. This involves instantiating the renderers and putting them into an IRenderingPipeline and then forwarding to THE view servlet. Instantiating these renderers also means instantiating quite a few objects they need that cache request or response. As the view servlet just calls the pipelines render() method and outputs the resulting document as xhtml to the output it seems like a bit of overkill to give it a whole servlet (I mean - hey its doubling the number of servlets in my app!) Furthermore, the rendering implementation is actually making use of requests and responses and contexts etc... that were cached by code in the action (and thus actionServlet) before forwarding to the view servlet, and Im not sure if thats ok or if its a naughty thing to do. Im thinking that instead of forwarding the request from my action, I pass the rendering pipepline to a class that outputs the xhtml to the response, and return null from the action. </but>
<ohwaitaminute> I wonder if my issue is that I instantiate the renderers in the action as my way of selecting the view. Perhaps I should instead have a renderParameters object (or something like that) that gathers the data model value objects and other such objects needed BY the renderers as well as a key identifying which renderer to use, and pass THAT instead of the actual renderer objects to the view servlet which would then use a factory to instantiate the appropriate renderers? </ohwaitaminute> <help> any advice? </help> -----Original Message----- From: Richard Yee [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 12:29 To: Struts Users Mailing List Subject: RE: Advice: how strutty should I be?? Andrew, To address your question, ><question> >While Im on the subject, Ive got a generic servlet that does 'rendering' (or >more precicely invokes the render() method on a bunch of objects that the >action selects and forwards to it). However in this case , having a servlet >to do it seems a bit redundant, as an action already has access to all the >goodies a servlet gets - the most important of course being the response >object. Is there any particular reason I shouldnt simply invoke the >rendering code that is in my rendering class straight from my action and >write to the response there instead of forwarding to a servlet? >Or to rephrase it, - do we forward to a jsp or servlet from our action >because the action(s helper classes) are unable to execute the rendering >code (such as in the case of a jsp implemented view) or because its good >design to do it this way or becuase of some other gotcha I havent noticed >yet? ></question> it is because of both of the reasons you mentioned. The action classes shouldn't write the response b/c then they must rely on having access to the HttpServletResponse object. It is also good practice to cleanly separate the View from the Model code. Check out the Velocity template engine. Regards, Richard At 11:56 AM 5/31/2002 +0800, you wrote: ><soapbox> >Nah. JSPs are definately evil. They arent real (x)html, and they arent real >Java. (And of course as anything that isnt Java is by definition evil , so >it follows that jsps... heheh) >My main objection to JSPs is that they are inelegant (yes - I know thats >strong language , but its true!). The struts taglibs make them a lot less >inelegant and make developing apps with them a lot more straightforward, but >they remain ugly. I have a strong distaste for the idea of mixing the code >and layout like that. html, scriptlets, tags that you have to rtfm before >you know what they do..., all very messy and most it definately offends my >artistic appreciation of the code. >I feel it is much better to have the dynamic rendering be done using proper >clean java code, and the layout be done using good pure xhtml (with no non >xhtml tags! (not that notepad really cares about tags anyhow hehe ;-> )) ></soapbox> > >We were making use of XMLC to achieve this, however Ive had to ditch it as >the DOMs it creates have a very dodgy structure and dont even maintain the >original nesting of elements correctly (not to mention still being glued to >a hacked version of xerces1.2 !). (I suppose this is what one gets for >making use of stuff from Barracuda. At this point Im very glad I only >decided to use the xmlc stuff, and stuck to good ol' struts for my >controller framework!) >Ive now written my own (well its not actually mine - the company owns >everything we write) code which does lots of fun stuff to allow me to obtain >an org.w3c.Document (without having to type too much code or for the user to >wait forever for the parser to do its thing) and by manipulating this dom I >can insert the dynamic content in much the same way as one does it using >XMLC. > >Its actually quite a good way to learn the inner workings of struts, as >since Im not using jsps, Im finding myself taking lots of looks at the way >the taglib source is coded so I can get similar functionality in my code. >;-) > ><question> >While Im on the subject, Ive got a generic servlet that does 'rendering' (or >more precicely invokes the render() method on a bunch of objects that the >action selects and forwards to it). However in this case , having a servlet >to do it seems a bit redundant, as an action already has access to all the >goodies a servlet gets - the most important of course being the response >object. Is there any particular reason I shouldnt simply invoke the >rendering code that is in my rendering class straight from my action and >write to the response there instead of forwarding to a servlet? >Or to rephrase it, - do we forward to a jsp or servlet from our action >because the action(s helper classes) are unable to execute the rendering >code (such as in the case of a jsp implemented view) or because its good >design to do it this way or becuase of some other gotcha I havent noticed >yet? ></question> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
