Re: [VOTE] Retain the "!" idiom but disable it by default
I'd prefer it to be turn off by default. I normally use an extra action alias instead of "foo!bar". As for cancel action, I'd normally use and have an action alias "purchaseCancel" which could be using the same action class but with a different method defined in the struts xml file. instead of So, i guess the overall impact isn't significant to me. The overall sturts config file could get more verbose, but i guess we could separate them out using . regards - Original Message From: Ted Husted <[EMAIL PROTECTED]> To: Struts Developers List Sent: Saturday, 26 August, 2006 8:35:31 AM Subject: Re: [VOTE] Retain the "!" idiom but disable it by default On 8/25/06, Don Brown <[EMAIL PROTECTED]> wrote: > What were you meaning by removing the deprecation? Deprecation means that we may remove the behavior in favor of a preferred alternative. That's very different from making the behavior switchable. Right now, we don't have a preferred alternative, so it was wrong to ever refer to the behavior as "deprecated" in the first place. The original notion was that wildcards could be a dropin replacement for hardwiring the "!" syntax, and in my experience, we are already 98% there, but it's hard to test wilcard replacements with the hardwired code switched on, since the special-casde code hijacks the processing of any action name with an embedded "!". The builtin, hardwired, non-configurable behavior It is also arguably a security flaw, and since we already have code that can switch it off, there is no reason not to provide the switch, even if the default is to enable the behavior. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [jira] Updated: (STR-2864) Add actionId attribute to action mapping]
Wendy Smoak wrote: OK, then the only other thing I'd suggest is to work this into one of the example apps, and update the relevant part of the website documentation, before closing the issue. Sure; I have one half-baked already and will finish that up. When do you think it is appropriate then to commit the code to struts-core? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [jira] Updated: (STR-2864) Add actionId attribute to action mapping]
On 8/26/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: OK, then the only other thing I'd suggest is to work this into one of the example apps, and update the relevant part of the website documentation, before closing the issue. I'd suggest adding something to the new cookbook application that demonstrates the utility. The virtue of the cookbook is that you don' have to "work something in". You can create a miniature use case that demonstrates the original motivation and put it into it's own module. At some point, it might be helpful if the elder example applications were rolled into the cookbook, so that there woud not be so many artifiacts to maintain. I'd advise against "hacking" the MailReader to demonstrate a feature, unless the change actually improves the MailReader's design. (Would I do it this way in my own applications?) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [jira] Updated: (STR-2864) Add actionId attribute to action mapping]
On 8/26/06, Paul Benedict <[EMAIL PROTECTED]> wrote: Sure; I have one half-baked already and will finish that up. As Ted mentioned, a module in the Cookbook app would be great... does that work with what you have? When do you think it is appropriate then to commit the code to struts-core? When you're finished with it? As far as I can tell, you've addressed the concerns that were raised, so... go ahead, and see what happens. :) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SVN access question
I tried to connect via HTTPS and got this message. (I omitted some parts.) Is it normal? Error validating server certificate for https://svn.apache.org:443: - Unknown certificate issuer Fingerprint: 19:51: Distinguished name: http://..., Scottsdale, Arizona, US Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN access question
On 8/26/06, Paul Benedict <[EMAIL PROTECTED]> wrote: I tried to connect via HTTPS and got this message. (I omitted some parts.) Is it normal? Error validating server certificate for https://svn.apache.org:443: - Unknown certificate issuer Fingerprint: 19:51: Distinguished name: http://..., Scottsdale, Arizona, US See: http://www.apache.org/dev/version-control.html#https-svn Make sure the fingerprint matches, then you can accept it and you won't see the message again. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Patch all or individual commits?
I hope everyone doesn't mind putting up with my newbie committer questions. They will hopefully come to the end soon :-) I committed one file and that turned out fine. So now my question is: when you have X files you want to check-in, do we have any policy here on the expected way of doing it? Do we create a patch for the whole darn thing and apply the patch? Or do we just individually check-in files? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch all or individual commits?
On 8/26/06, Paul Benedict <[EMAIL PROTECTED]> wrote: I hope everyone doesn't mind putting up with my newbie committer questions. They will hopefully come to the end soon :-) I committed one file and that turned out fine. So now my question is: when you have X files you want to check-in, do we have any policy here on the expected way of doing it? Do we create a patch for the whole darn thing and apply the patch? Or do we just individually check-in files? Please try to check in all of the files for a particular issue in a single commit. That way, it's easy to point to all of the changes, since they're marked with a single SVN revision number, and it's also easy to back out the change, if that ever becomes necessary, for the same reason. Checking in the files individually really defeats the advantages of our source control system. -- Martin Cooper Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch all or individual commits?
On 8/26/06, Paul Benedict <[EMAIL PROTECTED]> wrote: I hope everyone doesn't mind putting up with my newbie committer questions. They will hopefully come to the end soon :-) I committed one file and that turned out fine. So now my question is: when you have X files you want to check-in, do we have any policy here on the expected way of doing it? Do we create a patch for the whole darn thing and apply the patch? Or do we just individually check-in files? As much as possible, commit everything related to a particular issue at once. Also, remember to refer to the issue number in the commit message so it will automatically show up on the 'Subversion Commits' tab in JIRA, and provide enough information so that someone looking at _only_ the svn logs can figure out what happened. JIRA is great, but the commit logs will probably outlive it. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch all or individual commits?
Wendy Smoak wrote: Also, remember to refer to the issue number in the commit message so it will automatically show up on the 'Subversion Commits' tab in JIRA Do you have an example commit message? If there's a special format, please let me know. PS: When this is all done, I should probably collect all these tips and add them to our home page. Unless I missed all these guidelines (it is quite possible!), it's worth documenting. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [jira] Updated: (STR-2864) Add actionId attribute to action mapping]
To employ uniqueness checking of an actionId, I added to addActionConfig. That method currently overwrites any actionConfigs that are duplicate -- the last one is the winner. Should I take the same approach for duplicate ids? Or should I throw an exception on duplication? I'd like some guidance here because I don't know which makes more sense; I tend towards throwing an error (duplicate ids smell), but history allows the last one win. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch all or individual commits?
On 8/26/06, Paul Benedict <[EMAIL PROTECTED]> wrote: Wendy Smoak wrote: > Also, remember to refer to the issue number in the commit message so > it will automatically show up on the 'Subversion Commits' tab in JIRA Do you have an example commit message? If there's a special format, please let me know. Any of the recent commits, but you're probably already getting them: http://mail-archives.apache.org/mod_mbox/struts-commits/ We don't have a template. As long as you mention the issue number somewhere in the commit message, JIRA will find it. Some people lead off the commit message with it, some put it on a separate line below, some just mention it in a sentence. If you're applying someone else's patch, put 'Submitted By: ...' on a separate line. PS: When this is all done, I should probably collect all these tips and add them to our home page. Unless I missed all these guidelines (it is quite possible!), it's worth documenting. It's probably not documented, just things we've discussed on [EMAIL PROTECTED] This page might work: http://wiki.apache.org/struts/StrutsMaintenanceSvn HTH, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Duplicate action ids - how to handle?
I will add this to the comments of STR-2864 when finished. Please answer the following question if you have opinion about this: To employ uniqueness checking of an actionId, I added to ModuleConfigImpl.addActionConfig. That method currently overwrites any action configs that are duplicate -- the last one is the winner. Should I take the same approach for duplicate ids? Or should I throw an exception on duplication? I'd like some guidance here because I don't know which makes more sense; I tend towards throwing an error (duplicate ids smell), but history allows the last one win. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
