Our debate both raging through email and irc, is in a much different place than it started from for both of us. I'll state both mine and Patrick's current point of view as I see them.

Correct me in the right places Pat.


Pat:
Wants to be able to pass parameters to Actions as well as Views.

Maurice:
Pat has been unable to come up with a real world example of why this an absolute necessity for him, so I'm having a problem getting a real sense of urgency for this feature. But adding it fits symmetrically with passing parameters to Views so I'm cool with it.

Pat:
The internals of the config package could be more elegant. All the View and Action information are Strings internally and should broken out into a set of Classes.

Maurice:
I agree. But the current config code works fine today. Any refactoring for the sake of esthetics happens after we get the next release out.

Pat:
No changes will happen to either the views.properties configuration or the actions.xml configuration that will impact the enduser. This includes new tags or attributes for those tags. HTTP query style parameter passing (like used with redirect.action in views.properties) will still work.

Maurice:
Great. I do think a param tag in actions.xml would be useful to add to a distant future release.

Pat:
The command XML tag clutters up the actions.xml namespace.

Maurice:
I agree, but people rely on it being there, so even if there is an alternative (like a param tag) it has to stay. It's not a perfect world, and this is only a minor esthetic inconvenience for those of us who don't use CommandDriven.


Anyway, I think we're in the same place now. Can we table this discussion until after 1.3 now?

-Maurice


On Tuesday, November 5, 2002, at 12:14 AM, Patrick Lightbody wrote:

Maurice and I talked some more on IRC (#java on EFnet, where a lot of us
hang out) and I think he started to see what Mike and I both see as a
potential target for using WebWork in many non-web places. We agreed, and
correct me if I'm wrong Maurice, that this level of configuration could be
addressed in 2.0. Maybe if Maurice or Mike gets a chance, he can try to sum
up what we went over in #java.

-Pat

----- Original Message -----
From: "Maurice C. Parker" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 04, 2002 7:40 PM
Subject: Re: [OS-webwork] More thoughts on Configuration


On Monday, November 4, 2002, at 06:45 PM, Patrick Lightbody wrote:

I believe I've nailed down, in words, why the current configuration is
sub-optimal. The Configuration object uses a single method:
I disagree.  You have yet to ask for any functionality that can't be
handled by the current configuration formats, either actions.xml or
views.properties.


As you can see, not only is the view mapping but also the CommandAware
stuff
(something inherently built in to ActionSupport only, meaning it
shouldn't
be in core configuration stuff). This is a very flat structure. It also
doesn't leave room for allowing us to specify parameters for our
actions. An
example of this is:
Could the configuration be more graceful internally?  Sure.  So what?
It works right now (or used to) and all the implementation details are
hidden from the enduser.  Why are you fixating on this when we have
stuff that's actually broken?


Say I have a SendEmail action. I want to be able to use the aciton in
various places. It sends generic emails out, so I want to re-use it. A
parameters to be passed in would be the "subject", as well as the
"message"
body. I'd be very nice to be able able to alias SendConfirmationEmail
and
also SendPasswordEmail:

SendConfirmationEmail would be mapped to SendEmail but would have two
paramters auto set (as in my code doesn't need to do this): subject and
message. Same goes for SendPasswordEmail.
You may know your ass from an Action, but you sure don't know a View
from an Action. You model (Action) doesn't know it's being displayed
right? It could be in an email or a webpage or whatever, so SendEmail
is a view technology. This is no different than JSP, Velocity, or
Jasper. So you should be passing parameters to a View, not an Action.

(If this really is a single Action, and you haven't separated your
View, just use inheritance to change your subject.)

Let's say for the sake of argument that you have configured SendMail to
function as a View and are going to do this by returning a result that
points to it. I.E. it's logically functioning as your View technology
and sending out emails. Here's your configuration:

<action alias ="sendPasswordEmail" name ="GetUserInfo">
<view name="success"> SendEmail.action?subject=Your
Password</view>
</action>

<action alias ="sendConfirmationEmail" name ="GetUserInfo">
<view name="success"> SendEmail.action?subject=Confirmed</view>
</action>

This you can do today. We can put sugar on it in the next major
release.

<action alias ="sendPasswordEmail" name ="GetUserInfo">
<view name="success" target="SendEmail.action">
<param name="subject" value="Your Password/>
</view>
</action>

Explain to me again, what new functionality are you bringing to the
table?

-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: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork




-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Reply via email to