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.
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
