Just another quick point I'd like to make:
Currently the WebWork code makes no difference between configuration for
dispatchers (think of the temporary file location for file uploads), general
webwork config (think of of webwork.action.packags config), view
configurations (think of the velocity configs), and action configurations
(think of views.properties).
Also, i'd like to point out that webwork.config.Configuration looks for the
property "webwork.configuration" which is set as a class name (in most
cases, webwork.config.DefaultConfiguration). So what I've proposed is merely
reworking the internals so that it makes more sense in a generic usage
(which is what we all want WebWork 2.0 to do).
I envision (and am writing right now) an ActionConfig object that is
returned by the Configuration method: getActionConfg(String actionName).
This ActionConfig would have three attributes: Class actionClass, Map
parameters (added immediately before executing), and Map results (a mapping
of {String -> Action or View}). A View interface would contain a single
method, executeView(). A subclass, such a JSPView, could then examine the
ActionContext and do the appropriate redirect as needed by grabbing the Http
specific stuff. An action in the results Map would indicate chaining.
Anyway, I got a bit ahead of myself. I'll get the examples in the sandbox
(as well as the GD bug fixes, of course). My main point is that this
configuration complexity which I've suggested has actually already been
there for a while. All I'm suggesting is an ActionConfig class that makes it
very clear in the code what configuration abilities there are for an action
(specifically, a Map of parameters and a Map of results).
-Pat
-Pat
----- Original Message -----
From: "Patrick Lightbody" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 04, 2002 12:50 PM
Subject: Re: [OS-webwork] Re: Configuration
> 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
-------------------------------------------------------
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
