You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2003/12/19 21:43:00 UTC
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
Joe@Germuska.com
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Stxx and Multiple Presentation Engines in General (Re: Struts 2.0
Ideas)
Posted by Nathan Bubna <na...@esha.com>.
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
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Stxx and Multiple Presentation Engines in General (Re: Struts
2.0 Ideas)
Posted by Ted Husted <hu...@apache.org>.
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Stxx and Multiple Presentation Engines in General (Re: Struts
2.0 Ideas)
Posted by Don Brown <mr...@twdata.org>.
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:
<forward name="success" path="success.dox" />
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:
>
> <action type="MyAction"....>
> <forward name="httpSuccess" path="success.jsp" />
> <forward name="httpFailure" path="failure.jsp" />
> <forward name="soapSuccess" path="success.xsl" handler="stxx" />
> <forward name="soapFailure" path="failure.xsl" handler="stxx" />
> </action>
>
> Of course people can always do things the wrong ways...
>
> Is this better?
>
> <action type="MyAction"....>
> <forward name="success" path="success.jsp" />
> <forward name="failure" path="failure.jsp" />
> <forward name="success" handler="stxx" path="success.xsl" />
> <forward name="failure" handler="stxx" path="failure.xsl" />
> </action>
>
> 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
> Joe@Germuska.com
> 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: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Stxx and Multiple Presentation Engines in General (Re: Struts
2.0 Ideas)
Posted by Joe Germuska <Jo...@Germuska.com>.
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:
<action type="MyAction"....>
<forward name="httpSuccess" path="success.jsp" />
<forward name="httpFailure" path="failure.jsp" />
<forward name="soapSuccess" path="success.xsl" handler="stxx" />
<forward name="soapFailure" path="failure.xsl" handler="stxx" />
</action>
Of course people can always do things the wrong ways...
Is this better?
<action type="MyAction"....>
<forward name="success" path="success.jsp" />
<forward name="failure" path="failure.jsp" />
<forward name="success" handler="stxx" path="success.xsl" />
<forward name="failure" handler="stxx" path="failure.xsl" />
</action>
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
Joe@Germuska.com
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Stxx and Multiple Presentation Engines in General (Re: Struts
2.0 Ideas)
Posted by Don Brown <mr...@twdata.org>.
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: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Stxx and Multiple Presentation Engines in General (Re: Struts
2.0 Ideas)
Posted by Ted Husted <hu...@apache.org>.
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Stxx and Multiple Presentation Engines in General (Re: Struts
2.0 Ideas)
Posted by Joe Germuska <Jo...@Germuska.com>.
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<Foo.jsp>
or some other...
or a two-part naming scheme like
<forward path="Foo.jsp" handler="requestDispatcher" />
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
Joe@Germuska.com
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Stxx and Multiple Presentation Engines in General (Re: Struts
2.0 Ideas)
Posted by Don Brown <mr...@twdata.org>.
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
> Joe@Germuska.com
> 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: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org