Hmm. Interesting, saw pajes mentioned on the barracuda list as well. Flavour of the week? ;-)
Struts doesnt force you to use JSPs, but it does provide a bunch of JSP tags that make it a very nice fit to use JSP with struts, and of course the majority of strutters are using JSP. The Tiles library is a very big argument in favour of JSPs too. Ok. Enough of the balanced reporting... I have a 'distinct dislike' of JSP, and personally prefer a DOM based approach such as used in XMLC etc... (Im actually using my own home grown method for managing the pages and their DOMs and rendering the dynamic content and doing templating and the like. <vanity>Its pretty cool</vanity>). I havent played with pajes so dont know all that much about it. Looks rather like XMLC at first glance. As you mentioned, it can be annoying getting hold of the the various struts 'things' when doing a non-JSP approach - but they are all there and can be got at, and its not hard. btw: When working with beans (incl actionform) you will find that the stuff in BeanUtils is really useful for playing with properties whose name you only have at runtime. Heres some code that may help you get a handle on the essential struts objects: (I pasted straight from my StrutsHelper code and ripped out the irrelavent lines in case your wondering why everything has 'return' in front of it!) As you can see, pretty much everything has a key in the struts Globals interface. Chack the javadocs for this interface for more info. (The examples below are not fully module sensitive I think. (ie I havent tested it using modules)) ActionServlet: return (ActionServlet) servletContext.getAttribute(Globals.ACTION_SERVLET_KEY); ActionErrors: return (ActionErrors) request.getAttribute(Globals.ERROR_KEY); Locale: (hmmm. Not sure if using the default like that is std struts!) Locale locale = (Locale) session.getAttribute(Globals.LOCALE_KEY); return locale == null ? Locale.getDefault() : locale; ActionMapping: return (ActionMapping) request.getAttribute(Globals.MAPPING_KEY); ActionMessages: return (ActionMessages) request.getAttribute(Globals.MESSAGE_KEY); MessageResources: return (MessageResources) request.getAttribute(Globals.MESSAGES_KEY); ModuleConfig: return (ModuleConfig) request.getAttribute(Globals.MODULE_KEY); ActionForm: String scope = mapping.getScope(); //you need to get the mapping (see above) String attribute = mapping.getAttribute(); attribute = attribute == null ? mapping.getName() : attribute; return (ActionForm) viewContext.lookup(attribute, scope); hth Andrew -----Original Message----- From: Villalba Arias, Fredy [BILBOMATICA] [mailto:[EMAIL PROTECTED] Sent: Wednesday, 4 February 2004 20:40 To: Struts Users Mailing List Subject: RE: Struts and Pajes Ok. I'll try to be more clear: - I don't want to use JSPs when working with Struts, neither the Taglibs. Instead, I want to be able to delegate the presentation on an external component. - In order to do that, I must be able to access the data to be presented (i.e. access the appropriate ActionForm) from that external component, in consistency with Struts handlign of scope and other concepts. - It seems like Struts would expect you to (finally surrender and) use JSP + JSP tags, although it does not formally obliges you to do so. I've been checking both the source code for the tag libs and the .java-s generated by them and I get this strong impression that there is happening a lot more "behind the scenes" that one would suppose (and Struts would recognize). This would not worry me if there were Java classes that, not being "JSP-oriented", still allowed me to do everything (or even 50%) Struts' JSP-tags do. I don’t say they don't exist. I just have not found them. - I don't see why you say I'm conflating those 2 issues (please, explain it to me :) ). I'm not introducing anything new inside the framework, nor am I changing its normal behaviour. I'm respecting the roles assigned to each component. I believe what I'm doing is - precisely - prevent (or, at least, make it more difficult to) the developer from mixing control and presentation (on a JSP); moreover, I'm allowing the TOTAL separation of HTML and Java by encapsulating the dynamic generation of the view in a Java object especially designed for that purpose (for good). Anyway, I'm absolutely open to any comments / opinnions you can provide in this regard. IMPORTANTE NOTICE: I don't want start a discussion here about how good or bad Struts is: - I don't have time for that, - I don't have yet the required level of knowledge and expertise (on Struts, that is) to make such judgement, - That's not the point for this posting. This said, I'll be really looking forward to anything anybody is willing to collaborate with. Thanx again! Freddy. -----Mensaje original----- De: Michael McGrady [mailto:[EMAIL PROTECTED] Enviado el: martes, 03 de febrero de 2004 19:41 Para: Struts Users Mailing List; [EMAIL PROTECTED] Asunto: Re: Struts and Pajes Struts is not the "presentation tools" so you are fine. You can use any presentation, or even none. I do a lot of tunneling things with struts, including serving images with Action classes. Your question is not clear to me? You seem to be conflating mapping (control) and view (presentation) issues. But, I am not sure. Anyway, if you are not clear, they are distinct. I don't know how much you know, so let me stress that the web "MVC" pattern is really not the classic MVC pattern. Rather, our own beloved Ted Husted has nailed the real pattern, which is to keep the connections of each of the MVC to only one of the other three on each side (incoming and out going). It's more of a circle. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/2003 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
