Stxx and Multiple Presentation Engines in General (Re: Struts 2.0 Ideas)
Hmmm...that's a good question. I think there are pieces of stxx it would be good to provide with Struts for the casual user who wants to take an existing Struts action, and render content via XSLT/XSL-FO with little effort. To truely do XML processing right, however, I think a stronger solution of Struts and Cocoon integregated together is the answer. This, of course, would fall outside the scope of Struts core. Could stxx's XML processing features be put into Struts 1.x? Yes, but before that happens, I think some sort of url feature for forwarded paths should be put in first. This would allow a request to easily be forwarded to a different presentation system without modifying or overriding the request processor. For example, a forward to a jsp page could look like: "jsp://Foo.jsp", for tiles: "tiles://Foo.jsp", and for stxx: "stxx://Foo.xsl". This feature would make it easy to have multiple presentation engines, a feature we say Struts supports, but it doesn't really. Don On Fri, 19 Dec 2003, Ted Husted wrote: > Do we still want to integrate stxx into Struts 1.x? > > Don Brown wrote: > > Using JXPath is exactly what XMLForms (http://www.xmlforms.org) does to > > allow the form model to be anything from a DOM to a JavaBean or even a > > DynaBean. XMLForms came out of Cocoon, but I believe they still use > > something simliar. In stxx (http://stxx.sf.net), a Struts extension, I > > have been experimenting using XML as the data model for a form. It is > > particuarly useful as it allows forms to be simultaneously exposed via > > Struts and SOAP. > > > > Don > > > > > - > 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]
Re: Stxx and Multiple Presentation Engines in General (Re: Struts 2.0 Ideas)
Could stxx's XML processing features be put into Struts 1.x? Yes, but before that happens, I think some sort of url feature for forwarded paths should be put in first. This would allow a request to easily be forwarded to a different presentation system without modifying or overriding the request processor. For example, a forward to a jsp page could look like: "jsp://Foo.jsp", for tiles: "tiles://Foo.jsp", and for stxx: "stxx://Foo.xsl". This feature would make it easy to have multiple presentation engines, a feature we say Struts supports, but it doesn't really. I'm still uncomfortable with minting new URL schemes. Couldn't this be solved by deploying an additional servlet mapped to handle other extensions? This is how JSPs work as it is; if your deployment descriptor gave *.xsl to the STXX servlet, then requestDispatcher.forward() would give control to STXX just to do the view rendering. I thought this was how the Velocity/Struts integration stuff worked already. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "We want beef in dessert if we can get it there." -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stxx and Multiple Presentation Engines in General (Re: Struts 2.0 Ideas)
Yes, that is another way to handle it. I never liked that approach since it meant those urls could be accessed directly and I feel everything should be behind Struts and its security. Besides, that approach ties your app to the Servlet API. Don On Fri, 19 Dec 2003, Joe Germuska wrote: > >Could stxx's XML processing features be put into Struts 1.x? Yes, but > >before that happens, I think some sort of url feature for forwarded paths > >should be put in first. This would allow a request to easily be forwarded > >to a different presentation system without modifying or overriding the > >request processor. For example, a forward to a jsp page could look like: > >"jsp://Foo.jsp", for tiles: "tiles://Foo.jsp", and for stxx: > >"stxx://Foo.xsl". This feature would make it easy to have multiple > >presentation engines, a feature we say Struts supports, but it doesn't > >really. > > I'm still uncomfortable with minting new URL schemes. Couldn't this > be solved by deploying an additional servlet mapped to handle other > extensions? This is how JSPs work as it is; if your deployment > descriptor gave *.xsl to the STXX servlet, then > requestDispatcher.forward() would give control to STXX just to do the > view rendering. > > I thought this was how the Velocity/Struts integration stuff worked already. > > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "We want beef in dessert if we can get it there." >-- Betty Hogan, Director of New Product Development, National > Cattlemen's Beef Association > > > - > 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]
Re: Stxx and Multiple Presentation Engines in General (Re: Struts 2.0 Ideas)
Joe Germuska said: > >Could stxx's XML processing features be put into Struts 1.x? Yes, but > >before that happens, I think some sort of url feature for forwarded paths > >should be put in first. This would allow a request to easily be forwarded > >to a different presentation system without modifying or overriding the > >request processor. For example, a forward to a jsp page could look like: > >"jsp://Foo.jsp", for tiles: "tiles://Foo.jsp", and for stxx: > >"stxx://Foo.xsl". This feature would make it easy to have multiple > >presentation engines, a feature we say Struts supports, but it doesn't > >really. > > I'm still uncomfortable with minting new URL schemes. Couldn't this > be solved by deploying an additional servlet mapped to handle other > extensions? This is how JSPs work as it is; if your deployment > descriptor gave *.xsl to the STXX servlet, then > requestDispatcher.forward() would give control to STXX just to do the > view rendering. > > I thought this was how the Velocity/Struts integration stuff worked already. that's precisely how we do it, and everything works just fine. i too think new URL schemes are a redundant complexity. Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stxx and Multiple Presentation Engines in General (Re: Struts 2.0 Ideas)
At 10:55 AM -1000 12/19/03, Don Brown wrote: Yes, that is another way to handle it. I never liked that approach since it meant those urls could be accessed directly and I feel everything should be behind Struts and its security. Besides, that approach ties your app to the Servlet API. Touché... but I thought we were talking about STXX in Struts 1.x now. Besides, you could but the pages behind WEB-INF just like JSPs and avoid the direct access. A few compromises: a different, unique syntax that doesn't look like a URL: [jsp[Foo.jsp]] jsp or some other... or a two-part naming scheme like although more likely for backwards compatibility the "handler" part would default to requestDispatcher. In fact, maybe you could just treat "handler" as the application-scoped name of a processor adhering to some interface that would do the processing... then you don't even have to parse the path; just pass it as is to the named handler if it's not the request processor. Joe Don On Fri, 19 Dec 2003, Joe Germuska wrote: >Could stxx's XML processing features be put into Struts 1.x? Yes, but >before that happens, I think some sort of url feature for forwarded paths >should be put in first. This would allow a request to easily be forwarded >to a different presentation system without modifying or overriding the >request processor. For example, a forward to a jsp page could look like: >"jsp://Foo.jsp", for tiles: "tiles://Foo.jsp", and for stxx: >"stxx://Foo.xsl". This feature would make it easy to have multiple >presentation engines, a feature we say Struts supports, but it doesn't >really. I'm still uncomfortable with minting new URL schemes. Couldn't this be solved by deploying an additional servlet mapped to handle other extensions? This is how JSPs work as it is; if your deployment descriptor gave *.xsl to the STXX servlet, then requestDispatcher.forward() would give control to STXX just to do the view rendering. > I thought this was how the Velocity/Struts integration stuff worked already. > -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "We want beef in dessert if we can get it there." -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stxx and Multiple Presentation Engines in General (Re: Struts 2.0 Ideas)
Don Brown wrote: Yes, that is another way to handle it. I never liked that approach since it meant those urls could be accessed directly and I feel everything should be behind Struts and its security. Besides, that approach ties your app to the Servlet API. What's the Servlet API got to do with it? Instead of a .xls or .jsp reference, you could just as easily reference a .html or .php or .pdf resource. Of course, the others wouldn't have access to the Java contexts (at least not this side of JSR 223). But, mapping presentation engines to extensions is the de jure approach. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stxx and Multiple Presentation Engines in General (Re: Struts 2.0 Ideas)
Relying on the request dispatcher ties you to the Servlet API. Furthermore, extensions are inadequate as more than one "handler", to use Joe's terminology, might be interested in a particular extension. If the URL idea is collectively shot down, I vote for Joe's idea of adding an attribute the the forward element. In either case, 100% backwards compatibility should be maintained. Don On Fri, 19 Dec 2003, Ted Husted wrote: > Don Brown wrote: > > Yes, that is another way to handle it. I never liked that approach since > > it meant those urls could be accessed directly and I feel everything > > should be behind Struts and its security. Besides, that approach ties > > your app to the Servlet API. > > What's the Servlet API got to do with it? > > Instead of a .xls or .jsp reference, you could just as easily reference > a .html or .php or .pdf resource. > > Of course, the others wouldn't have access to the Java contexts (at > least not this side of JSR 223). > > But, mapping presentation engines to extensions is the de jure approach. > > -Ted. > > > > > - > 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]
Re: Stxx and Multiple Presentation Engines in General (Re: Struts 2.0 Ideas)
At 12:14 PM -1000 12/19/03, Don Brown wrote: Relying on the request dispatcher ties you to the Servlet API. Furthermore, extensions are inadequate as more than one "handler", to use Joe's terminology, might be interested in a particular extension. If the URL idea is collectively shot down, I vote for Joe's idea of adding an attribute the the forward element. In either case, 100% backwards compatibility should be maintained. Although now that we talk about it, I'm hesitant to put this in the forward config -- I'm afraid it would lead to people writing actions that were too conscious of the view handling. I imagine something like this, which I would not want to see: Of course people can always do things the wrong ways... Is this better? That is, multiple forwards with the same name, distinguished by their handlers? I don't like that much either, since it puts a lot of responsibility on mapping.findForward() So then it seems that a Tiles-ish solution might be better, where the path is another symbolic name, each kind of handler could potentially be configured with a way to dereference that symbolic name. What's the use case? Using one action to respond to HTTP, Portlet and SOAP, assuming that the control is the same but the view is different?Or is it using different view handlers in the same request domain -- that is some times you want to use JSP to respond to an HTTP request, and sometimes STXX or Velocity? If it's the first, you could expect the part of the request processor before the action is invoked to be able to leave a mark as to its ID, so that the corresponding view handler could take over after the action finishes. If it's the second, I'm having a hard time thinking of a clean way to organize that. I should be careful here, because I haven't had need for either of those cases myself. But in all my thinking about this, I wish it didn't have to be implemented using the current monolithic RequestProcessor -- do you guys still think we're on a "1.4 time frame" for switching to a chain-based version? (as noted in the "roadmap"). Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "We want beef in dessert if we can get it there." -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stxx and Multiple Presentation Engines in General (Re: Struts 2.0 Ideas)
Lets start at the possible Use Cases. I see a web application wanting to have some actions be displayed as PDF's, others with a simple JSP page, still others with Tiles. I don't see the same action needing multiple forwards for each of the presentation types. If you are going to simultaneously expose an action via two different environments, say HTTP and SOAP, you will probably, in the SOAP case, have specific deployment configuration specific to SOAP and probably won't even be using struts-config.xml. If you are, I'd image you'd have one for HTTP and the other for SOAP, each with their respective view technologies. Currently, with stxx and I believe with tiles, you, as you said, put in a symbolic name that gets processed by the request processor. In stxx's case, it might look like: where the "dox" extension lets the stxx request processor know to send it to stxx, where it will probably be converted to "success.xsl" at some point. Yes, one solution could be to simply allow presentation engines to "register" extensions they want to handle and let them convert the string into a useful path of some sort. The advantage of the symbolic name is you can possibly encode more information to pass to the presentation tech, like "simple/success.dox", which in the case of stxx, might be telling stxx to use the "simple" pipeline to process success.xsl. The disadvantage is it is kinda a hack and not particularly elegant. By explicitly specifying the presentation tech in either a separate attribute or the scheme of a URI, it is more clear. Taking into account the ability to pass "parameters" to the presentation engine either by encoding the info in a symbolic name or as part of a URI, perhaps another attribute wouldn't be adequate. In my stxx app, I make liberal use of encoding info in the symbolic name, using wildcards to extract that info within stxx pipelines. I originally suggested URI's to more standardize how info was encoded, but perhaps the symbolic name way would be more acceptable to some. Don On Fri, 19 Dec 2003, Joe Germuska wrote: > At 12:14 PM -1000 12/19/03, Don Brown wrote: > >Relying on the request dispatcher ties you to the Servlet API. > >Furthermore, extensions are inadequate as more than one "handler", to use > >Joe's terminology, might be interested in a particular extension. If the > >URL idea is collectively shot down, I vote for Joe's idea of adding an > >attribute the the forward element. In either case, 100% backwards > >compatibility should be maintained. > > Although now that we talk about it, I'm hesitant to put this in the > forward config -- I'm afraid it would lead to people writing actions > that were too conscious of the view handling. I imagine something > like this, which I would not want to see: > > > > > > > > > Of course people can always do things the wrong ways... > > Is this better? > > > > > > > > > That is, multiple forwards with the same name, distinguished by their > handlers? I don't like that much either, since it puts a lot of > responsibility on mapping.findForward() > > So then it seems that a Tiles-ish solution might be better, where the > path is another symbolic name, each kind of handler could potentially > be configured with a way to dereference that symbolic name. > > What's the use case? Using one action to respond to HTTP, Portlet > and SOAP, assuming that the control is the same but the view is > different?Or is it using different view handlers in the same > request domain -- that is some times you want to use JSP to respond > to an HTTP request, and sometimes STXX or Velocity? > > If it's the first, you could expect the part of the request processor > before the action is invoked to be able to leave a mark as to its ID, > so that the corresponding view handler could take over after the > action finishes. If it's the second, I'm having a hard time thinking > of a clean way to organize that. > > I should be careful here, because I haven't had need for either of > those cases myself. But in all my thinking about this, I wish it > didn't have to be implemented using the current monolithic > RequestProcessor -- do you guys still think we're on a "1.4 time > frame" for switching to a chain-based version? (as noted in the > "roadmap"). > > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "We want beef in dessert if we can get it there." >-- Betty Hogan, Director of New Product Development, National > Cattlemen's Beef Association > > > - > 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]
Re: Stxx and Multiple Presentation Engines in General (Re: Struts 2.0 Ideas)
Joe Germuska wrote: So then it seems that a Tiles-ish solution might be better, where the path is another symbolic name, each kind of handler could potentially be configured with a way to dereference that symbolic name. Right now, Tiles checks to see if the path is the name of a definition, and if not, it passes it through as a normal URI. In a sense, this is a mini Chain of Responsibility. When the Chain Request Processor is in place, we'd be able to have both a Tiles handler and a Stxx handler in the chain. Tiles could check to see if the path was a definition, and if it wasn't, it passes it along (to the Stxx handler). What's the use case? Using one action to respond to HTTP, Portlet and SOAP, assuming that the control is the same but the view is different?Or is it using different view handlers in the same request domain -- that is some times you want to use JSP to respond to an HTTP request, and sometimes STXX or Velocity? Here's where adding a Java class to the ActionForward could be useful. The ActionForward could examine the context and decide what to do, which could even be render the response directly. We've made that the Action's job before, but I'm leaning toward enhancing the ActionForward so that it can take greater responsibility for rendering the Response. Right now, I think a lot of are writing two sets of Actions. One to handle the business case and another to handle the presentation case. When we discusses this before, we came down to wait and see if a Command would work here, which I agree is a good idea. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]