Yup... summed up perfectly. When work on www.openysmphony.com starts (Justin Stepka has volunteered to help out here) I'll make sure situations that demonstrate a need for all this are made clear. Until then, I'm find to table this (and Ognl) for a post-1.3 release.
-Pat ----- Original Message ----- From: "Maurice C. Parker" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 05, 2002 6:25 AM Subject: Re: [OS-webwork] More thoughts on Configuration > 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 ------------------------------------------------------- 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
