Patrick Lightbody wrote:
You're right, I'm not giving concrete examples. They are there, trust me, I
just haven't written them down. I'd like for this issue to be kept open
until I get a chance to give you some real examples. In fact, I'll even
write some code in the sandbox/xwork module that is a working example.
Or you could fix those bugs introduced with the GenericDispatcher.
-Maurice
Until I get some examples and code in place, I'll not bring this up again.
-Pat
----- Original Message -----
From: "Maurice Parker" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 04, 2002 12:45 PM
Subject: Re: [OS-webwork] Re: Configuration
Patrick Lightbody wrote:
Well partly. The thing is that when you do Foo.success=Bar.action, it is
ambiguous and confusing. Half the people might expect a chain to happen,
while the other half might expect a new Http request to be made to
Bar.action. So at least some people are going to be surprised.
Actions by definition should not know about their environment.
Foo.success=Bar.action means to chain to the next action. Period. The
mechanism whether it be by doing HTTP forwards or by going through an
internal loop is an implementation detail that should be hidden from the
end user.
Look, I don't see you proposing any functionality that hasn't existed in
a different form for a long time. Functionality BTW, that didn't
require any special effort on the part of the end user (i.e. extra
configuration).
Actually, my proposal adds a large ammount of functionality while still
keeping configuration simple for the newbie or anyone else who wants
things
as simple as possible. The primary change I'm suggesting is that the
internal configuration architecture be reworked to be specific to actions
(currently it is a generic Object get(String) method) and that complete
support for action configuration be built in to the configuration
archicture. Sure, I can do
"jasperTest.success=orderList.jasper?dataSource=orders" (as you mentioned
in
your last email), but that is nothing but a hack. What it is doing is
taking
advantage of Http-specific features (parameters in the GET string) and
jamming it in to the configuration.
The point behind giving this example was to show you that you haven't
any new funtionality.
As to using HTTP specific features, all actions have parameters if in a
Servlet container or not. If you specify them via an HTTP query string
or with a special XML tag is irrelevant. They're still parameters. If
we need syntactic sugar, we can add a param XML tag to actions.xml.
And just to be perfectly clear, this change would have _zero_ effect on
anyone.
I fail to see how it would benifit anyone either. Show me how to do
something with your new configuration scheme that I can't already do
today.
-Maurice
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
