Re: Resource Bundle Prototyping
On Wed, 6 Aug 2003, Joe Germuska wrote: I'm pretty sure this was an explicit design intention, although the main reason may have been to make backwards compatibility more manageable (or maybe not -- I can't cite any place where this was discussed; I just have vague recollections). From reading the lists, it's clear that many people intuitively expect modules to be less walled off from each other. Maybe a smarter Modularization, but one which might break some compatibility, could be targetted for a 1.5 release, or some mid-point between 2.0, which has a lot of bigger changes marked for it. I am going to make an effort to look through the archives and find the reasoning behind the design of the current modules (unless someone out there can enlighten us all). And explore the code and docs to come up with some ideas for application-wide module features that won't break struts conventions, etc... The modules would be much more useful to me if they had a concept of application and module. -adam k. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22231] - the logic:present and bean:write will not display all of the HttpServletRequest attributes.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22231. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22231 the logic:present and bean:write will not display all of the HttpServletRequest attributes. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|the logic:present and |the logic:present and |bean:write will not |bean:write will not |display all of the |display all of the |HttpServletRequest |HttpServletRequest |attributes. |attributes. --- Additional Comments From [EMAIL PROTECTED] 2003-08-08 13:41 --- CLOSING THIS BUG. Apparently there is a difference between request attributes and request parameters. when using request.setAttribute(xyz,my message), you can display it on a jsp with logic:present name=xyz bean:write name=xyz / /logic:present while this will not work logic:present parameter=xyz bean:write name=xyz / /logic:present Does anyone have a good explanation of the difference between an 'attribute' and a 'parameter' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resource Bundle Prototyping
I don't think it would be necessary to break backward compatibility. One approach that maintains backward compatability is to define a new child element directly off the root struts-config element in the struts-config file. Here is an example: struts-config parent-modules parent-module name=module1 !-- beans 1 and 2 from module1 -- form-beans form-bean name=bean1/ form-bean name=bean2/ /form-beans !-- all forwards from module1 -- global-forwards/ !-- all exceptions from module2 -- global-exceptions/ message-resources/ /parent-module parent-module name=module2 !-- all beans from module2 -- form-beans/ global-forwards/ message-resources/ /parent-module /parent-modules !-- rest of config follows -- /struts-config This would allow me to define the application notion I want for my project by using a single parent-module element. It would also be flexible enough to accomodate users with different needs. Matt - Original Message - From: Joe Germuska [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 12:36 PM Subject: Re: Resource Bundle Prototyping At 12:30 -0400 8/6/03, Sgarlata Matt wrote: Or did you mean I'm not modularizing my app well? Maybe so, but I still think a notion of a Struts application could be beneficial. No, I meant nothing like that. IMHO, the conceptual issue is that there seems to be no notion of a Struts application reflected in the code because all the modules are peers with equal status. I'm pretty sure this was an explicit design intention, although the main reason may have been to make backwards compatibility more manageable (or maybe not -- I can't cite any place where this was discussed; I just have vague recollections). From reading the lists, it's clear that many people intuitively expect modules to be less walled off from each other. Maybe a smarter Modularization, but one which might break some compatibility, could be targetted for a 1.5 release, or some mid-point between 2.0, which has a lot of bigger changes marked for it. Or maybe compatibility can be preserved anyway. Joe -- -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com If nature worked that way, the universe would crash all the time. --Jaron Lanier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22228] New: - The Action.saveErrors() method won't save an empty ActionErrors object
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8 The Action.saveErrors() method won't save an empty ActionErrors object Summary: The Action.saveErrors() method won't save an empty ActionErrors object Product: Struts Version: 1.1 RC1 Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Standard Actions AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Which makes things a bit inconvenient. Imagine this scenario: You create an ActionErrors object in your action, but as the action progresses you want to add ActionError objects to it if an error condition occurs. Once an error occurs, you might return a forward to your error page. Since you can't call saveErrors() until you've added at least one error to ActionErrors, you have to saveErrors() at each point (not knowing in advance which one will execute. Since the rendering tags are smart enough to deal with an empty ActionErrors object, why not avoid the test for emptiness in saveErrors()? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)
--- Steve Raeburn [EMAIL PROTECTED] wrote: I *think* we agreed to add this action. Pick a name. [ ] ParameterDispatchAction [X] MappingDispatchAction [ ] ConfigDispatchAction I agree with Martin that Parameter implies request parameter and I think Config is overly general so I chose Mapping. David Steve -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: August 4, 2003 1:25 PM To: Struts Developers List Subject: RE: Addition of two new actions In an ideal world, DispatchAction should probably become ParameterDispatchAction and this could be plain old DispatchAction. Is Anthony's original suggestion of ConfigDispatchAction any better? I can't think of a name that I *really* like so I'm +0 on Mapping or Config. Steve -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper Sent: August 4, 2003 10:15 AM To: [EMAIL PROTECTED] Subject: Re: Addition of two new actions I'm +1 on this, other than on naming. I think ParameterDispatchAction is definitely the wrong name for the last of these. People are *far* more likely to think of the Parameter in the name as meaning a request parameter than they are to think of the parameter action mapping attribute. Perhaps MappingDispatchAction instead? I am -0 on combining all of this into one action. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17259] - o.a.s.validator.DynaValidatorForm logging
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17259. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17259 o.a.s.validator.DynaValidatorForm logging [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionForwards.java
dgraham 2003/08/08 16:27:27 Removed: src/share/org/apache/struts/action ActionForwards.java Log: Removed references to ActionMappings, ActionFormBeans, and ActionForwards. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SuccessAction (was RE: Addition of two new actions)
I don't think that you could rely on the ActionForwards being returned in the same order each time, so forwarding to the first one found would not be guaranteed to work. If we allowed anonymous or default ActionForwards would that work? action path=/myAction type=o.a.s.actions.SuccessAction forward path=/myPage.jsp /action Any forward without a name, would be stored under a default key (defined in Globals). You could use null here, but I think it would be better to use an actual value. You'd probably need to add a method such as getDefaultForward() to retrieve it. I could see this being of use in more than just SuccessAction (or equivalent). Quite often you're either forwarding to a success destination or returning to the input destination, so anonymous forwards would save a bit of work. I'll go have a play with this and see what I come up with. Steve -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: August 8, 2003 4:51 PM To: Struts Developers List Subject: Re: SuccessAction (was RE: Addition of two new actions) --- Steve Raeburn [EMAIL PROTECTED] wrote: OK, I'm back. Now where were we... What you're suggesting is this? action path=/myAction type=o.a.s.actions.SuccessAction forward name=success path=/myPage.jsp /action action path=/myOtherAction type=o.a.s.actions.SuccessAction parameter=oops forward name=oops path=/myPage.jsp /action I honestly don't see the value in the second method. You've just added a parameter to tell the action which forward to select when there is only one possible choice. You've also got two actions which do exactly the same thing, but are configured differently. That's a good point which raises another question. If the goal of SuccessAction is to forward to the one defined forward instance, why must we name it success or oops? Why can't SuccessAction call mapping.findForwards() and return the first forward it finds? Then we don't need to use the parameter attribute nor do we need to declare that success is the one right name for the forward. However, that makes SuccessAction a bit silly. If it's just going to forward to the first forward it finds, why not change the way we define forwards to be more natural and flexible? What I think we're seeing here is that we've outgrown our ActionForward declarations and need some new ones. I'm fine with adding a SuccessAction but would really like to see us discuss future possibilities in this area. My concern is that adding the parameter makes the use of the action a little less of a no-brainer (sometimes a *little* more complexity is all it takes). In its proposed default state SuccessAction would still be a complete no-brainer. I would be grateful if you could give an illustration of an example where success couldn't be used. Most other actions can be identified as having a success or fail outcome (or something in between). To my mind this is an action where the only possible outcome is success, so I can't see why the name would cause you so much trouble. Even if you're forwarding to an error page, the *action* is still successful. I've never said that success is a poor term or isn't used in most cases. I just don't think Struts should dictate the names of forwards to users. That is there choice and should be configurable. We all know that Action chaining isn't generally a smart move but sometimes it works out ok. Consider a RegisterAction that forwards to a LoginAction to login a user immediately after they register. RegisterAction might want to name its success forward login. Admittedly, this isn't directly applicable to our SuccessAction situation but it does show that success isn't *always* the correct term. Also, not every Struts developer speaks english and may choose forward names in their native language. Please reconsider whether having the flexibility of adding the parameter is really necessary. I think that in the vast majority of cases it isn't and for the minority a custom action would be an option. However, if you're *really* set on having the parameter option then let's go with SuccessAction, with the forward name being supplied by the parameter and defaulting to success if none is supplied. Ok? But, only if you really, really, really insist ;-) I'd like to get your thoughts (and others) on my proposal at the beginning of this message. In short, we wouldn't use the parameter attribute nor would we define success as the only correct forward name. SuccessAction would forward to the first forward that's defined for it. I believe SuccessAction fills a current gap but is probably a temporary solution until we have a more unified/flexible forward declaration syntax. How temporary it is depends on how motivated we are to change it :-). David Steve
