Re: Help on ApplicationResources
Struts is designed to do eactly this. You can provide your own implementations of the MessageResources and MessageResourcesFactory classes and plug them in. Look at the javadoc for the org.apache.struts.util package - it has a good section on Message Resources telling you what you need to know. http://jakarta.apache.org/struts/api/index.html Niall - Original Message - From: Prasad, Kamakshya [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 04, 2004 5:22 AM Subject: Help on ApplicationResources Hi All, We are using struts framework for building an application for a client. In the system, the client wants to have all the error messages, labels etc in the database instead of having them in a properties file. Please let me know that how can we extend the necessary packages provided by struts with a minimal changes and with the ability to continue using the normal functionalities provided by struts like bean:message, errors, ActionErrors etc. Thanks and Regards, Kamakshya - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help on ApplicationResources
Struts is designed to do eactly this. You can provide your own implementations of the MessageResources and MessageResourcesFactory classes and plug them in. Look at the javadoc for the org.apache.struts.util package - it has a good section on Message Resources telling you what you need to know. http://jakarta.apache.org/struts/api/index.html Niall - Original Message - From: Prasad, Kamakshya [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 04, 2004 5:22 AM Subject: Help on ApplicationResources Hi All, We are using struts framework for building an application for a client. In the system, the client wants to have all the error messages, labels etc in the database instead of having them in a properties file. Please let me know that how can we extend the necessary packages provided by struts with a minimal changes and with the ability to continue using the normal functionalities provided by struts like bean:message, errors, ActionErrors etc. Thanks and Regards, Kamakshya - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help on ApplicationResources
Apologies for these - I hadn't noticed that the message I was replying to had been cross-posted and I didn't check the reply address - I meant to send to struts-user list Niall - Original Message - From: Niall Pemberton [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, March 04, 2004 9:39 AM Subject: Re: Help on ApplicationResources Struts is designed to do eactly this. You can provide your own implementations of the MessageResources and MessageResourcesFactory classes and plug them in. Look at the javadoc for the org.apache.struts.util package - it has a good section on Message Resources telling you what you need to know. http://jakarta.apache.org/struts/api/index.html Niall - Original Message - From: Prasad, Kamakshya [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 04, 2004 5:22 AM Subject: Help on ApplicationResources Hi All, We are using struts framework for building an application for a client. In the system, the client wants to have all the error messages, labels etc in the database instead of having them in a properties file. Please let me know that how can we extend the necessary packages provided by struts with a minimal changes and with the ability to continue using the normal functionalities provided by struts like bean:message, errors, ActionErrors etc. Thanks and Regards, Kamakshya - 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]
Re: Bug 17667 - Client-side validation with multi-form page
OK sorry. No I haven't tried it - I only use server side validation. I was just following a message on the user list, found myself reading that bug and saw your note asking for a reminder after 1.2 was out - so I sent you one. - Original Message - From: Robert Leland [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 6:01 AM Subject: Re: Bug 17667 - Client-side validation with multi-form page Thanks, you do want to remind me via the struts-dev list. That way if someone else gets free time first to apply the patch, or disagres with it they can object. I'll make time this weekend to reapply it. Have you tried the patch ? -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 3, 2004 12:45 AM To: [EMAIL PROTECTED] Subject: Bug 17667 - Client-side validation with multi-form page Rob, http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17667 I was just following a thread from the user list and came accross this bug with a request to remind you when Struts 1.2.0 was out (so that you could apply a patch). Niall - 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]
Re: 1.2.x and beyond (was Tagging and Freezing)
Ted, Whats happening with your Jericho proposal - I looked in the cvs/contrib and just saw the overview - is there anything more concrete anywhere else and are you still looking at pursuing this 'struts revolution'? Niall - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Sunday, February 29, 2004 2:12 PM Subject: Re: 1.2.x and beyond (was Tagging and Freezing) On Fri, 27 Feb 2004 23:27:35 -0800, Craig R. McClanahan wrote: * Create a CVS branch for this release, which starts as a snapshot of the development tree when the release candidate is initially created, and allows the RM to incorporate whatever subsequent HEAD branch commits make sense (by either doing a CVS join or manually interpoLating the fixes). I'd be in favor of creating a branch for 1.2.x, so that we could finishing mavenising the HEAD, and be able to fixes to 1.2.x in the meantime. I believe that, as a result of the Maven initiative, we will also have multiple products/artifacts to distribute (struts-core, struts-opt-taglib, et cetera). If so, we could start each of these out at version 1.3.0, and then proceed from there with more aggressive enhancements (like Struts-Chain). So, the 1.2.x series (out there) is mainly about removing deprecations and refactoring existing features (like modules). Release 1.3.0 could be about repackaging the build for Maven and also doing the release subdividing that we've been talking about for some time now. Releases 1.3.1+ could then get back to the business of creating Struts [rather than just maintaining it] :) -Ted. - 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]
Why is TagUtils instance final?
I don't understand why the instance of TagUtils has been made final: private static final TagUtils instance = new TagUtils(); Isn't the logic behind having an 'instance' of TagUtils so that if someone want to change an aspect of TagUtils behaviour they can extend it and override a particular method? Otherwise why not just have a bunch of static methods in TagUtils? Does anyone have opinions on changing this so that TagUtils implementation could be customized? Niall
Re: 1.2.0 is tagged and frozen
Struts is a community and as such its important to know the roles people play in that community - people need to know or be able to find out who the comitters are and, just as importantly, who they are not. If I'm discussing submitting a change to struts - knowing whether people encourging/discouraging you are committers or not makes a difference when deciding if its worth trying or not. Also, since committers have only get to that status by proving their value to this community, their opinions get more respect. I also think acknowledgement of contributors is a positive thing - it is also good for the community and encourages participation. We can spend our lives in fear of what might happen but it has to be balanced with what is good for the struts community. I say keep the Who We Are and Contributors pages. Niall - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, February 24, 2004 11:46 AM Subject: Re: 1.2.0 is tagged and frozen On Mon, 23 Feb 2004 11:23:08 -0800, Paul Sundling wrote: I should probably still remove author tags from the docs and consolidate those into the volunteers page also. I'm afraid that our volunteers page is subject to the same considerations as the author tags. :( * Low hanging suit. In the unlikely event of a law suit, this is a (very) convenient list of parties to join to the action. We may think it's silly, but it is what an attorney would do. Each of these people would then be responsible for having themselves severed from the suit. (Guilty until proven innocent, I'm afraid.) The ASF would do what they could, but resources are limited; we shouldn't tempt fate. * No strings attached. An important ASF principle is that all the code and documentation belong to the Foundation and its Community. Tags and other credits tend to imply some people own more of the resources than others. When a resource is donated to the foundation, we need to emphasize that it belongs to the Foundation, free and clear. * Duty now for the future. ASF projects are meant to live for decades. The current list is already lengthy. What will it look like ten years from now? How much of the contributions of those we list today will really be part of the product then? Tags and lists like these cannot be sustained for the full life of an Apache product. Sadly, we should probably trim the Who We Are page down to the list of Struts Committers who are members of the Jakarta PMC, since these individuals are the legal representatives of the Foundation. In this context, the Struts Committee Members would be presented as the decision-makers rather than the authors. (Technically, what we do is a work for hire, even though we are all unpaid volunteers.) Of course, we'd still give credit where credit is due via the CVS commits, if for no other reason than to retain an audit trail. Of course, a very ambitious attorney could still try to join everyone cited in the CVS log, but the CVS events are shielded by the Committers being the actors, and so it's a horse of a different color. -Ted. - 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]
Re: string concatenation
I agree. I seem to recall there were problems releasing Struts 1.1 because of a hold up getting a commons component released that struts was depending on. That was understandable as various bits of struts were being moved over to commons at the time. Maybe now thats been done there should be a policy of only developing against release versions of commons code. That way commons doesn't become something Struts has to wait on and its being developed against stable fully tested commons components. Niall - Original Message - From: Hablutzel, Robert [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED]; Struts Developers List [EMAIL PROTECTED] Sent: Monday, February 16, 2004 12:32 AM Subject: RE: string concatenation So I'm a bit of a lurker here, but I wanted to put in my $.02. I'd rather see a dependency on efficiently implemented code in a single place than either replicating the code or using a less efficient algorithm. Replication just means that bugs in the code aren't fixed in all places, adds confusion to users as to which version to leverage, and makes it harder to introduce possible future code improvements. Trading memory for speed can be a meaningless tradeoff in high-volume applications where the number of GCs visibly impacts overall system performance. My preference would be for leveraging code that is in a logical place (ala commons-lang) and documenting the dependencies. hab -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Sun 2/15/2004 4:21 PM To: Struts Developers List Cc: Subject: RE: string concatenation -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Sunday, February 15, 2004 1:01 PM To: Struts Developers List Subject: RE: string concatenation Struts has many dependencies already and I'd like to avoid adding one with lang. Why not just size a large StringBuffer and trade memory for speed? We already have a dependency on Lang, albeit indirectly, so why not take advantage of it? Frankly, I disagree with the push I see from some folks (including Craig on commons-dev recently) to reduce dependencies between components by duplicating functionality. The whole point of Commons is to avoid duplication, so why are people pushing back against using the successful components that we helped create here in Struts? -- Martin Cooper David --- Martin Cooper [EMAIL PROTECTED] wrote: Rather than add a new string utility class to Struts, which isn't really where it should belong, I think we'd be better off just using this: http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang /StringUti ls.html#join(java.lang.Object[]) Alternatively, you could suggest (on the commons-dev list) adding a variation of your StringHolder class, based on the join() method above, to Commons Lang. -- Martin Cooper -Original Message- From: nishant kumar [mailto:[EMAIL PROTECTED] Sent: Saturday, February 14, 2004 5:46 PM To: [EMAIL PROTECTED] Subject: string concatenation hi, I have a performance tuning suggestion which i think will greatly impact the performance of struts html tags. String concatenation using StringBuffer is definitely much better than using the plus operator but there are scenarios where there are much better ways than using StringBuffers. Actually struts html tags fall in those scenarios. So let me give you an example. this is the code from renderFormStartElement method of FormTag. StringBuffer results = new StringBuffer(); results.append(form); results.append( name=\); results.append(beanName); results.append(\); results.append( method=\); results.append(method == null ? post : method); results.append(\ action=\); str = results.toString(); pageContext.getOut().write(str); Now lets list the issues with this. 1. first presizing this buffer is quite difficult (avoided in this case). here the buffer starts with size 16 and doubles each time the size is exceeded. This causes unnecessary creation of new char arrays and redundant copy of data whenever resizing happens. 2. whenever append is called data is copied from the passed string to the end of stringbuffer. 3. finally the whole concatenated data is again copied into another string. 4. and then in the end this string is written to a writer, another copy, which is the only copy required. so even if you had presized the stringbuffer correctly, you have copied the same data thrice instead of just once. And you also create two NOT needed objects. so here is the solution i propose. have a class holding an array of Strings and keep appending strings to this array and finally print this array to the writer. something like this.
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
Graham OK, I decided to look further into your suggestion, but didn't get very far and I think its because mask doesn't work. I started with a simple expression of [\d,]* to validate that the input only contains numbers or a comma. Whatever I input though validator always passed it as valid. Looking into validator it uses Perl5Util.match(pattern, value) This utility uses the Perl5Matcher.contains(value, pattern) method which only checks that the value contains the pattern - not that matches (it says so in the Perl5Util documentation). Isn't this the wrong thing to do - shouldn't validator be using the Perl5Matcher.matches(value, pattern) method. I had a look at commons validator test thinking this must be tested for and I must be mis-understanding it - but mask seems to be the one thing there are no tests for - and there don't seem to be any in struts either for FieldChecks.validateMask()) Anyway, am I right - is this a bug, or am I just using it wrongly? Niall P.S. If I am right, then it implies no one is using mask and I think thats an argument for my simpler number validation. - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 Thanks Niall Robert Leland wrote: So using mask won't work ? (my syntax below is probably not correct) field property=amount depends=required,mask arg0 key=sale.amount / var var-namemask/var-name var-value\d,\d\d0\:\(\d,\d\d0\)/var-value /var /field I need to validate numbers which are formatted and have posted a patch to bugzilla which enhances validator the existing number validations to do this. This patch allows an optional numberPattern variable to be specified for the existing byte, short, integer, long, float and double validations. For Example: field property=amount depends=required,integer arg0 key=sale.amount / var var-namenumberPattern/var-name var-value#,##0:(#,##0)/var-value /var /field If the pattern is specified, then java.text.DecimalFormat is used to parse the number and check if it is valid (catering for Locale). I have also posted a patch to add a new section the Validator User Guide which describes all the standard suppiled validations and shows examples of usage, including using the new numberPattern variable. Thanks in advance for any feedback. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - 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]
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
I agree with both of you! Not having JavaScript implementation shouldn't be an issue - if people want it then someone would come up with it. However, because the approach I took was to modify the exiting number validations (byte, short, long, integer, float, double) then it means that where there is JavaScript validation (not all of them seem to have) these will now fail if a pattern is used, because they don't take into account the pattern. I would put some additional time on this, if a committer was willing to implement it. But since David Graham has said he is -1 on this, doesn't that effectively make this enhacement request dead? Niall Richard Hightower wrote ... I agree about that sticky wicket, but There are already validation rules that do not have client-side support (via JavaScript). At least this type of stuff would be nice in the contrib area. Ted Husted wrote ... In principle, I'd agree with Rick, since these type of patterns are the standard way of doing this sort of thing on the Java platform. But, the sticky wicket is lack of a JavaScript implementation. People would expect an implementation like this to include client-side support, as the other validations do. -Ted. On Thu, 15 Jan 2004 20:54:17 -0700, Richard Hightower wrote: Niall, I don't get a vote. I am not a committer. But if I did I would vote +1 on the idea (I have not studied your implementation). I can write regular expressions in a pinch, but why not support all of the java.text.* in the validator rules (including currencey). I like the idea. Rick Hightower Developer Struts/J2EE training -- http://www.arc-mind.com/strutsCourse.htm Struts/J2EE consulting -- http://www.arc- mind.com/consulting.htm#StrutsMentoring -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 5:38 PM To: Struts Developers List Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] OK so how can it be done with mask? also, it doesn't get more basic than numbers...if it can be done with mask, but its complicated, doesn't ease of use cut any ice? Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 Thanks Niall Robert Leland wrote: So using mask won't work ? (my syntax below is probably not correct) field property=amount depends=required,mask arg0 key=sale.amount / var var-namemask/var-name var-value\d,\d\d0\:\(\d,\d\d0\)/var-value /var /field I need to validate numbers which are formatted and have posted a patch to bugzilla which enhances validator the existing number validations to do this. This patch allows an optional numberPattern variable to be specified for the existing byte, short, integer, long, float and double validations. For Example: field property=amount depends=required,integer arg0 key=sale.amount / var var-namenumberPattern/var-name var-value#,##0:(#,##0)/var-value /var /field If the pattern is specified, then java.text.DecimalFormat is used to parse the number and check if it is valid (catering for Locale). I have also posted a patch to add a new section the Validator User Guide which describes all the standard suppiled validations and shows examples of usage, including using the new numberPattern variable. Thanks in advance for any feedback. Niall - To unsubscribe, e-mail: struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
Hey thanks for your help - what you suggested worked (i.e. using ^[\d,]*$) - I was using the ORO demo, but if you don't put the right stuff in:-) OK, I'm picking up regex slowly - so this works because ^ is for the beginning of a line and % is for the end of a line. Apologies for the doesn't work slander then - but wouldn't it be better to use Perl5Matcher.matches(value, pattern) and then there would be no need to specify the ^ and $ characters at the start and end - simpler and less confusing? This could be done and would be backward compatible. Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 1:39 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] --- Niall Pemberton [EMAIL PROTECTED] wrote: Graham OK, I decided to look further into your suggestion, but didn't get very far and I think its because mask doesn't work. I know it works because I use it in my apps :-). I started with a simple expression of [\d,]* to validate that the input only contains numbers or a comma. Whatever I input though validator always passed it as valid. ORO's test applet is really helpful when testing regexs. Try putting ^ at the front and $ at the end of the pattern. ORO seems to need these to work properly unlike Java 1.4 regexs. David Looking into validator it uses Perl5Util.match(pattern, value) This utility uses the Perl5Matcher.contains(value, pattern) method which only checks that the value contains the pattern - not that matches (it says so in the Perl5Util documentation). Isn't this the wrong thing to do - shouldn't validator be using the Perl5Matcher.matches(value, pattern) method. I had a look at commons validator test thinking this must be tested for and I must be mis-understanding it - but mask seems to be the one thing there are no tests for - and there don't seem to be any in struts either for FieldChecks.validateMask()) Anyway, am I right - is this a bug, or am I just using it wrongly? Niall P.S. If I am right, then it implies no one is using mask and I think thats an argument for my simpler number validation. - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 Thanks Niall Robert Leland wrote: So using mask won't work ? (my syntax below is probably not correct) field property=amount depends=required,mask arg0 key=sale.amount / var var-namemask/var-name var-value\d,\d\d0\:\(\d,\d\d0\)/var-value /var /field I need to validate numbers which are formatted and have posted a patch to bugzilla which enhances validator the existing number validations to do this. This patch allows an optional numberPattern variable to be specified for the existing byte, short, integer, long, float and double validations. For Example: field property=amount depends=required,integer arg0 key=sale.amount / var var-namenumberPattern/var-name var-value#,##0:(#,##0)/var-value /var /field If the pattern is specified, then java.text.DecimalFormat is used to parse the number and check if it is valid (catering for Locale). I have also posted a patch to add a new section the Validator User Guide which describes all the standard suppiled validations and shows examples of usage, including using the new numberPattern variable. Thanks in advance for any feedback. Niall
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
OK hey, appreciate your feedback - and the mask/regexp gives me another string to my bow! I do think using the DecimalFormat style patterns is much easier and intuitive, but there is the issue over JavaScript and there are issues with the DecimalFormat parse() method. I think I need to re-think this enhacement request so I'll drop it for the moment and perhaps submit something different at a later date. Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 1:46 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] --- Niall Pemberton [EMAIL PROTECTED] wrote: I agree with both of you! Not having JavaScript implementation shouldn't be an issue - if people want it then someone would come up with it. However, because the approach I took was to modify the exiting number validations (byte, short, long, integer, float, double) then it means that where there is JavaScript validation (not all of them seem to have) these will now fail if a pattern is used, because they don't take into account the pattern. I would put some additional time on this, if a committer was willing to implement it. But since David Graham has said he is -1 on this, doesn't that effectively make this enhacement request dead? There wasn't a vote so my -1 is more of an indication that I don't like the idea. Mask is the most flexible validation that allows many things like formatted number validations. If you can't get your regex to work you might try writing a custom validation action that uses DecimalFormat. If that works you could post a patch to bugzilla. I encourage you to get the regex to work though because it will make life easier in the long run :-). David Niall Richard Hightower wrote ... I agree about that sticky wicket, but There are already validation rules that do not have client-side support (via JavaScript). At least this type of stuff would be nice in the contrib area. Ted Husted wrote ... In principle, I'd agree with Rick, since these type of patterns are the standard way of doing this sort of thing on the Java platform. But, the sticky wicket is lack of a JavaScript implementation. People would expect an implementation like this to include client-side support, as the other validations do. -Ted. On Thu, 15 Jan 2004 20:54:17 -0700, Richard Hightower wrote: Niall, I don't get a vote. I am not a committer. But if I did I would vote +1 on the idea (I have not studied your implementation). I can write regular expressions in a pinch, but why not support all of the java.text.* in the validator rules (including currencey). I like the idea. Rick Hightower Developer Struts/J2EE training -- http://www.arc-mind.com/strutsCourse.htm Struts/J2EE consulting -- http://www.arc- mind.com/consulting.htm#StrutsMentoring -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 5:38 PM To: Struts Developers List Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] OK so how can it be done with mask? also, it doesn't get more basic than numbers...if it can be done with mask, but its complicated, doesn't ease of use cut any ice? Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 Thanks Niall Robert Leland wrote: So using mask won't work ? (my syntax below is probably not correct
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
I already tried it, and it is backward compatible. The thing about Perl5Util is it provides a convinience method of match(value, pattern) which creates a Perl5Compiler, builds a cache of compiled patterns and calls the Perl5Matcher.contains() method. There isn't an equivalent convinience method that calls the Perl5Matcher.matches() method. Replacing: boolean match = Perl5Util.match(value, pattern) requires: Perl5Compiler compiler = new Perl5Compiler(); Pattern compiledPattern = compiler.compile(pattern); Perl5Matcher matcher = new Perl5Matcher(); boolean match = matcher.matches(value, compiledPattern); But then, it would be less efficient as the pattern is being compiled every time. It would be straight forward to do the equivalent of Perl5Util and create a cache. I might have a look at this later and submit a patch to Commons. Niall - Original Message - David Graham [EMAIL PROTECTED] wrote: --- Niall Pemberton [EMAIL PROTECTED] wrote: Hey thanks for your help - what you suggested worked (i.e. using ^[\d,]*$) - I was using the ORO demo, but if you don't put the right stuff in:-) OK, I'm picking up regex slowly - so this works because ^ is for the beginning of a line and % is for the end of a line. I think you meant $ instead of % but yes that's correct. Apologies for the doesn't work slander then - but wouldn't it be better to use Perl5Matcher.matches(value, pattern) and then there would be no need to specify the ^ and $ characters at the start and end - simpler and less confusing? This could be done and would be backward compatible. I really haven't looked at the differences between matches() and contains() so I don't know if it's backwards compatible. You could try changing it and let us know what happens. David Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 1:39 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] --- Niall Pemberton [EMAIL PROTECTED] wrote: Graham OK, I decided to look further into your suggestion, but didn't get very far and I think its because mask doesn't work. I know it works because I use it in my apps :-). I started with a simple expression of [\d,]* to validate that the input only contains numbers or a comma. Whatever I input though validator always passed it as valid. ORO's test applet is really helpful when testing regexs. Try putting ^ at the front and $ at the end of the pattern. ORO seems to need these to work properly unlike Java 1.4 regexs. David Looking into validator it uses Perl5Util.match(pattern, value) This utility uses the Perl5Matcher.contains(value, pattern) method which only checks that the value contains the pattern - not that matches (it says so in the Perl5Util documentation). Isn't this the wrong thing to do - shouldn't validator be using the Perl5Matcher.matches(value, pattern) method. I had a look at commons validator test thinking this must be tested for and I must be mis-understanding it - but mask seems to be the one thing there are no tests for - and there don't seem to be any in struts either for FieldChecks.validateMask()) Anyway, am I right - is this a bug, or am I just using it wrongly? Niall P.S. If I am right, then it implies no one is using mask and I think thats an argument for my simpler number validation. - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request
Re: OT RE: Validating Formatted Numbers Patch [Bugzilla 26151]
Heres to lots more grief in the future hey lol! - Original Message - From: Richard Hightower [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 10:42 PM Subject: OT RE: Validating Formatted Numbers Patch [Bugzilla 26151] Grief imparts the most knowledge. What would joy mean if we did not have agony?! I've learned a few things from you grief. You contributed a patch, and found another bug with the mask rule. Your grief has benefitted the group. Thanks for sharing your grief. Rick Hightower Developer Struts/J2EE training -- http://www.arc-mind.com/strutsCourse.htm Struts/J2EE consulting -- http://www.arc-mind.com/consulting.htm#StrutsMentoring -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Friday, January 16, 2004 11:23 AM To: Struts Developers List Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] Caused me some griefplus a complete lack knowledge of RegExp until yesterday. Anyway, thanks to everyone for the help and input - I know more today than I did yesterday. I've put a enhancement request into Bugzilla with patch on Commons to change this - fingers crossed it will be approved. Niall - Original Message - From: Richard Hightower [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 6:00 PM Subject: RE: Validating Formatted Numbers Patch [Bugzilla 26151] Niall, Good catch! I was wondering why I had to always specify ^ and $. I wrote a few of my own validator rules (e.g., zip code and phone number), and I used regex from java. I used the match function. This explains some mysteries in my head. -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Friday, January 16, 2004 8:30 AM To: Struts Developers List Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] I already tried it, and it is backward compatible. The thing about Perl5Util is it provides a convinience method of match(value, pattern) which creates a Perl5Compiler, builds a cache of compiled patterns and calls the Perl5Matcher.contains() method. There isn't an equivalent convinience method that calls the Perl5Matcher.matches() method. Replacing: boolean match = Perl5Util.match(value, pattern) requires: Perl5Compiler compiler = new Perl5Compiler(); Pattern compiledPattern = compiler.compile(pattern); Perl5Matcher matcher = new Perl5Matcher(); boolean match = matcher.matches(value, compiledPattern); But then, it would be less efficient as the pattern is being compiled every time. It would be straight forward to do the equivalent of Perl5Util and create a cache. I might have a look at this later and submit a patch to Commons. Niall - Original Message - David Graham [EMAIL PROTECTED] wrote: --- Niall Pemberton [EMAIL PROTECTED] wrote: Hey thanks for your help - what you suggested worked (i.e. using ^[\d,]*$) - I was using the ORO demo, but if you don't put the right stuff in:-) OK, I'm picking up regex slowly - so this works because ^ is for the beginning of a line and % is for the end of a line. I think you meant $ instead of % but yes that's correct. Apologies for the doesn't work slander then - but wouldn't it be better to use Perl5Matcher.matches(value, pattern) and then there would be no need to specify the ^ and $ characters at the start and end - simpler and less confusing? This could be done and would be backward compatible. I really haven't looked at the differences between matches() and contains() so I don't know if it's backwards compatible. You could try changing it and let us know what happens. David Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 1:39 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] --- Niall Pemberton [EMAIL PROTECTED] wrote: Graham OK, I decided to look further into your suggestion, but didn't get very far and I think its because mask doesn't work. I know it works because I use it in my apps :-). I started with a simple expression of [\d,]* to validate that the input only contains numbers or a comma. Whatever I input though validator always passed it as valid. ORO's test applet is really helpful when testing regexs. Try putting ^ at the front and $ at the end of the pattern. ORO seems to need these to work properly unlike Java 1.4 regexs. David Looking into validator it uses Perl5Util.match(pattern, value) This utility uses the Perl5Matcher.contains
Validating Formatted Numbers Patch [Bugzilla 26151]
I need to validate numbers which are formatted and have posted a patch to bugzilla which enhances validator the existing number validations to do this. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 This patch allows an optional numberPattern variable to be specified for the existing byte, short, integer, long, float and double validations. For Example: field property=amount depends=required,integer arg0 key=sale.amount / var var-namenumberPattern/var-name var-value#,##0:(#,##0)/var-value /var /field If the pattern is specified, then java.text.DecimalFormat is used to parse the number and check if it is valid (catering for Locale). I have also posted a patch to add a new section the Validator User Guide which describes all the standard suppiled validations and shows examples of usage, including using the new numberPattern variable. Thanks in advance for any feedback. Niall
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
OK so how can it be done with mask? also, it doesn't get more basic than numbers...if it can be done with mask, but its complicated, doesn't ease of use cut any ice? Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 Thanks Niall Robert Leland wrote: So using mask won't work ? (my syntax below is probably not correct) field property=amount depends=required,mask arg0 key=sale.amount / var var-namemask/var-name var-value\d,\d\d0\:\(\d,\d\d0\)/var-value /var /field I need to validate numbers which are formatted and have posted a patch to bugzilla which enhances validator the existing number validations to do this. This patch allows an optional numberPattern variable to be specified for the existing byte, short, integer, long, float and double validations. For Example: field property=amount depends=required,integer arg0 key=sale.amount / var var-namenumberPattern/var-name var-value#,##0:(#,##0)/var-value /var /field If the pattern is specified, then java.text.DecimalFormat is used to parse the number and check if it is valid (catering for Locale). I have also posted a patch to add a new section the Validator User Guide which describes all the standard suppiled validations and shows examples of usage, including using the new numberPattern variable. Thanks in advance for any feedback. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - 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]
Re: Editable Fields V/S Static Text
I submitted a PATCH in May 2001, but it wasn't applied. http://www.mail-archive.com/[EMAIL PROTECTED]/msg01450.html http://issues.apache.org/bugzilla/show_bug.cgi?id=1683 I haven't looked at them for a while but the issue was with the big chunks of code in the doStartTag()/doEndTag() - refactoring attributes out of those makes life much easier and I think was a good idea. I would do it again for the current Struts except that I don't want to botther putting the effort in for it to be ignored a second time. Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 9:39 PM Subject: RE: Editable Fields V/S Static Text Whenever tag extendability enhancements are discussed, we always hear complaints from a vocal minority but no tested working patches show up. I haven't heard any good suggestions that would make the tags easier to subclass. If the current factoring isn't good enough, provide patches for something better. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Editable Fields V/S Static Text
Sounds good. I'll put some thought into it. Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, September 26, 2003 2:09 AM Subject: Re: Editable Fields V/S Static Text --- Niall Pemberton [EMAIL PROTECTED] wrote: I submitted a PATCH in May 2001, but it wasn't applied. http://www.mail-archive.com/[EMAIL PROTECTED]/msg01450.html http://issues.apache.org/bugzilla/show_bug.cgi?id=1683 That bug is marked fixed but there are no patches attached to it. This is a perfect example of why we ask patches to not be sent via email and prefer them to be attached to the bugzilla ticket. I haven't looked at them for a while but the issue was with the big chunks of code in the doStartTag()/doEndTag() - refactoring attributes out of those makes life much easier and I think was a good idea. I would do it again for the current Struts except that I don't want to botther putting the effort in for it to be ignored a second time. I'm willing to work with you on this if you have the time to test and submit patches. Let's start with one tag and discuss the needed changes on struts-dev before coding anything. When we decide on the right changes to make we can open a bugzilla ticket to track things. My main area of interest is in the html taglib because it offers functionality not provided by the JSTL; however, if other tags need refactoring I'm willing to work on those as well. Does this sound reasonable? David Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 9:39 PM Subject: RE: Editable Fields V/S Static Text Whenever tag extendability enhancements are discussed, we always hear complaints from a vocal minority but no tested working patches show up. I haven't heard any good suggestions that would make the tags easier to subclass. If the current factoring isn't good enough, provide patches for something better. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - 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]
Re: Where is Struts 2 going?
- Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Saturday, September 13, 2003 11:38 PM Subject: Re: Where is Struts 2 going? side-noteIt's been quite interesting to watch how the term reference implementation has been morphed from a pejorative complaint several years ago -- an implied it's *only* the reference implementation -- into a perception of high quality :-)/side-note Craig Ha, well depends on who is doing the implementation! If you take something like tomcat, then yes, fantastic - jakarta open source RI, coluldn't be better. On the other hand I've seen some SIP RI's from commercial companies that really are there only for reference. The question then is what's the future for the Faces RI? Is it going to be a proper product that Sun supports and develops like any of its other java products, or is it there really just as a proof of concept or reference for other implementors? Will Sun be promoting people to go implement real systems based on the RI when its released? Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where is Struts 2 going?
I may have got the wrong end of the stick, but doesn't Struts overlap to some degree with JavaServer Faces and wasn't there talk of perhaps Struts evolving to be a implementation of JavaServer Faces? Is this way off base or is this one possible direction for Struts2? Niall - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, September 12, 2003 7:28 PM Subject: Re: Where is Struts 2 going? Personally, I'd like to start the work on 2.x by defining the use-cases or stories that we'd like the framework to realize. Ideally, we should be able to trace each feature back to its use-case. Then, I'd suggest we build the framework up, story by story, test by test. Here's some early work along those lines: http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsUseCases Of all possible *features*, the one I would emphasize the most is testability. The second, which is a corollary to the first, would be decoupling the core framework from http, while allowing direct access to the underlying protocol when needed. Though, if we base the core around Commons Chain of Responsibility, both should follow naturally. If every controller function can be done in Faces or other frameworks, what do we gain by using Struts 2? Using Struts 2, our applications can cruise across modules built from different vendors or teams. And we could also develop modules for others. Could we realize this dream? I know there are many challenging problems there. Could we think about it in terms of defining characteristics of Struts 2? Personally, I'm uncomfortable defining an open source product in these terms. We're not a retail product looking for a market. We're a community of developers building the everyday tools we each need to use. If the Java platform did ship with everything everyone needed, then it's true that we'd have nothing to do here, and we could all focus on our paying jobs. hurrah!/ But it is unlikely that such a day will ever come sigh/. In all likelihood, there are always going to be vacuums for open source to fill. If people need Struts to be an integrator, then people will contribute integration code. Of course, that's already true. Stxx integrates Struts with XLST. The Velocity Tools integrate Struts with Velocity. Some of Don's packages integrate Struts with Cocoon and BSF. And so on. But people didn't do this because we put it on a whiteboard. People did this because it is functionality they needed to do their jobs. IMHO, the role of the Struts Committers is to ensure that generally accepted best practices are followed, so that the codebase remains easy to maintain and improve. For new development, especially, that means using techniques like test-driven development and technologies like Maven and IDEs that help us write cleaner code. For frameworks, it also means using patterns like Context and Chain of Responsibility to loosen coupling. But as to where the specifics of development take us, IMHO, it should be from each according to their need. Now we have the Struts chain. I like the ideas of the chain. Amen to that brother. =:0) But, it's not *Struts* chain -- it's the *Commons* Chain. The true power of this package is that it gives us common ground upon with to build *business layer* frameworks. Right now, many of us are abusing Actions because Strut is the only controller framework we got. :( But Chain is opening the door to another framework -- one that lives below Struts and manages all that nasty business logic -- the way Struts (and friends) now helps us with all the nasty presentation logic. :) -Ted. Jing Zhou wrote: I believe this topic has been discussed hundreds of times in different subjects. One of important tasks for a new version is to identify concept leaps. This is the place I would like to entertain your brain - hope everyone to have a brainstorm on what are really the innovative ideas to be built in Struts 2. To start, let's review what the innovative ideas are in Struts 1.0. Struts is called a MVC framework. But that is not enough, actually there are many other frameworks also called MVC ones. What made Struts unique at its early time is its defining characteristics between form beans and web forms. They are symmetrical entities. In Struts 1.1, another concept leap is introduced, we called it application module. With this concept, the developments of Struts applications scale up. There are some other concept leaps, someone could add more. Struts 1.0/1.1 is recognized as a Controller in general. Now we have the Struts chain. I like the ideas of the chain. In particular, I see the possibility we could transform the Controller into an Integrator based on the chain and the application module. Integrator is a higher concept than Controller in my opinion. Struts 2, as an Integrator, should be
Re: [PROPOSAL] Wildcard-matched actions
I like it.
Perhaps you should create an enhancement request in bugzilla and attach a
patch with your code.
Niall
- Original Message -
From: Don Brown [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 30, 2003 11:18 PM
Subject: [PROPOSAL] Wildcard-matched actions
Perhaps now that 1.1 is final, this would be a good time to bring this up.
I've written a small extension to Struts that allows action mappings to
use wildcards in matching URIs. The matched values can then be
substituted anywhere in the action mapping - similar to how Cocoon
operates (in fact the wildcard code was copied from Cocoon). The code
only affects the processActionMapping method of the RequestProcessor.
Why you ask?
- Much smaller config files
- Use of wildcards encourages more consistency of naming action forms,
actions, and jsp files.
- Allows for noun-based URLs in addition to current verb-based URLS,
particularly useful in REST-style web services
- No performance loss: wildcard matching only occurs when a direct
mapping for the URI cannot be found
For example:
!-- Matches all edit forms --
actionpath=/edit*
type=org.apache.struts.webapp.example.Edit{1}Action
attribute={1}Form
scope=request
validate=false
forward name=failure path=/mainMenu.jsp/
forward name=success path=/{1}.jsp/
/action
By including this feature directly in Struts, wildcards would be available
to all Struts applications as opposed to now where wildcard support
requires a RequestProcessor extension.
For more information:
http://www.twdata.org/struts-wildcard/
Don
-
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]
Re: DO NOT REPLY [Bug 21031] - Old struts.jar in jakarta-struts-1.1-rc2.zip?
Apologies...you're right, it was. Niall - Original Message - From: James Mitchell [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 2:44 AM Subject: Re: DO NOT REPLY [Bug 21031] - Old struts.jar in jakarta-struts-1.1-rc2.zip? On Monday 23 June 2003 21:17, [EMAIL PROTECTED] wrote: 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=21031. 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=21031 Old struts.jar in jakarta-struts-1.1-rc2.zip? --- Additional Comments From [EMAIL PROTECTED] 2003-06-24 01:17 --- Johnny isn't asking a question - he's reporting a problem with the RC2 binaries from the site he specifies. I was going off of the number of ? that were in this report. It appear more exploratory than matter-of-fact. Thanks Having said that however, I downloaded the binaries from that specified site just now and the ActionErrors.isEmpty() method was there no problem. So it looks like its a problem with your setup Johnny. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- James Mitchell Software Developer/Struts Evangelist http://www.struts-atlanta.org 770-822-3359 AIM:jmitchtx - 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]
Re: Short term plans
The sentiments are good but the reality is sometimes different. I submitted two sets of logic tags in May 2001 which provided switch/case and if/and/or/else logic. They were basically wrappers for the existing struts logic tags. They were rejected at the time because the JSTL would be providing the same functionality - even though these tags worked in 2.2/1.1 and JSTL required 2.3/1.2. Funnily enough they were even on the TODO list at the time!!! So even though 1) * I wanted it * 2) * Other people wanted it * and 3) * I provided them * - it wasn't enough to get them included in Struts. Another thing was, although these logic tags were rejected the Empty and NotEmpty tags were added to Struts afterwards!! I guess the #1 requirement for anyone submitting to struts is can I get a committer to take any interest? Niall TED But to answer your question, I think the litmus test would be whether TED there is a working patch annexed. TED TED All anyone has said is that since the attention of the Committers in TED their own work is likely to be on other technologies, it is equally likely TED that the Committers won't be spending their *own* development time TED *creating* patches. TED TED As long as the change has technical merit, and a Committer is willing TED to take responsbility for the patch, we won't/can't veto something TED becomes of competition from JSTL/JSF/XLST/Velocity/Tapestry/lord-knows. CRAIG At JavaOne US 2002 (March 2002) I did a survey of the folks that came to CRAIG the Struts Community BOF. Over half the people there were developing and CRAIG deploying on J2EE 1.2 (i.e. Servlet 2.2 and JSP 1.1) platforms. Yes, it's CRAIG almost a year later now, but the situation has not *totally* changed. CRAIG CRAIG JSTL (and JavaServer Faces, when it becomes available) require Servlet 2.3 CRAIG and JSP 1.2, so they are not even an option for a very significant portion CRAIG of the Struts user community. CRAIG I think there are multiple perspectives for asking for enhancements, CRAIG all of them valid. Some examples: CRAIG CRAIG * I need it -- This particular feature would help me . . . CRAIG CRAIG * Lots of people need it . . .useful to lots of people using an existing version of Struts ... CRAIG CRAIG * I want to work on it . . .nothing stops us from adding some more CRAIGdevelopers that want to continue to enhance the existing tags. CRAIG CRAIG NOTE -- this perspective is the most critical for actually getting anything done :-). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Status of Struts-EL contrib project
David, From your original post I assumed you were going to provide JSTL style struts tags by incorporating the EL functionality of JTSL (I read somewhere it was going to be split out from the JSTL, perhaps to commons) with the main aim being that struts developers could use them now (with Servlet 2.2 / JSP 1.1) and making the migration to JSTL much easier. From what you say below it seems the intention is to move the struts tags which provide functionality that JSTL doesn't have to work in a compatible way with JSTL. Can you clarify this and are you just using the EL of JSTL or will your ammendments need the whole of JSTL and require Servlet 2.3 / JSP 1.2? Niall -Original Message- From: David M. Karr [mailto:[EMAIL PROTECTED]] Sent: 22 July 2002 17:19 To: [EMAIL PROTECTED] Subject: Status of Struts-EL contrib project I had talked last week about building a tag library, composed of tags derived from the Struts tags, but which use the JSTL expression evaluation engine for attribute values, instead of using JSP rtexprvalues. I thought I would give you a little status on how I'm doing with this. I've finished the bean and logic libraries, and am now working on the html library. It's occurred to me that if I'm building a tag library that would be used alongside the JSTL, there's not much point in porting Struts tags that duplicate JSTL tag functionality. Therefore, most of the tags in the logic library aren't in my derived library. Part of the library documentation will cover this issue, and will detail exactly which Struts tags were not ported, and which JSTL tags cover their functionality. While building this, I decided to look at building unit tests for these tags. I thought this would be easy, as I could mutate the unit tests inside the Struts distribution. I was a little surprised to discover that there are actually very few unit tests for the Struts tags, just for logic:equal, logic:notequal, logic:present, and logic:notpresent. So, as another minor subproject to this, I'm experimenting with what I can do to build more complete unit tests for the Struts-EL tags. Almost all of what I'm doing here could be ported back eventually to the Struts unit tests. In particular, for the tags which generate HTML, I'm writing tests (and reusable support code) which verifies the generated output, including checking the attributes and their values which are present or not present in the output. This code uses JUnit, Cactus, and HTTPUnit, along with requiring JTidy, AspectJ, and Xalan. Except for Xalan, these all normally go along with HTTPUnit. I'm also going to look at slightly extending the XML files which describe the tag libraries, to include an element which indicates whether an attribute uses the EL engine for evaluation. This won't be used for generating the tag libraries, only for documentation generation. I'll provide more information as I get closer to completion (or what looks like completion to me). Any comments or questions? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DynaActionForm questions
I haven't looked at DynaActionForm yet, but we are just starting to use DynaBeans - isn't the beauty of all this stuff that you don't have to use the provided DynaActionForm, but just go create your own version that suits your needs - sub-class ActionForm, implement the DynaBean interface and Bob's your uncle, it'll all work for you too - if its good and you think others would use it, submit it back to struts - I'm sure theres room for more than one implementation. Niall -Original Message- From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]] Sent: 15 March 2002 21:26 To: Struts Developers List Subject: Re: DynaActionForm questions Thanks Craig, On Fri, 2002-03-15 at 14:19, Craig R. McClanahan wrote: Pretty slick, huh? :-) It is slick indeed. The intended focus could just use a little more refining (perhaps in the users manual). If you know what your app needs to ask for, then DynaActionForms are a new and easier way to express it. On the other hand, if your application doesn't know what it's going to be asking for until runtime, then DynaActionForms aren't the complete solution, although they will probably be part of the solution I ultimately build. The two scenarios are pretty different, and the use of the dyna keyword could lead over-eager developers like me to assume something that isn't there. Thanks, Bryan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Implement HTTP and HTTPS in a safe, flexible, and easily maintainable manner
This gives an example of how to integrate SSL into a Web App, using Struts as an example. http://www.javaworld.com/javaworld/jw-02-2002/jw-0215-ssl.html winmail.dat Description: application/ms-tnef -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-struts/doc struts-nested.xml
Ted, Small point...the list of committers isnt up to date - Arron isnt on there - anyone else? -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: 16 February 2002 16:18 To: Struts Developers List Subject: Re: cvs commit: jakarta-struts/doc struts-nested.xml Arron, Could you hold off any more Commits. I'm in the middle of heavy surgery on the documentation. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Niall's if/then/else tags and switch/case/default?
I dont know how good JSPTL is because its dependant on Tomcat 4 (and/or JSP 1.2) and thats where the problem lies - we are using Tomcat 3 so I haven't looked at it. When Nivarna comes and JSPTL is part of the JSP spec (1.3 perhaps?) and everyones using servlet containers that support it then this stuff is redundant. The question is, when is that going to be and whats the best thing to do in the meantime for a) people using JSP 1.1 and b) people using JSP 1.2? My tags also included a switch/case/default which is equivalent to the choose/when/otherwise pattern in JSPTL and the if/else also supports and/or/elseif tags. I could re-engineer the if/else/elseif to not need a then and I believe this would make them as elegant as they could be. However its not worth it if theres no enthusiasm for the tags and everyones either switching to JSPTL or happy to go with whats already there (scriptlet or the current logics tags) until they switch to JSPTL. Niall -Original Message- From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig R. McClanahan Sent: 07 September 2001 07:17 To: [EMAIL PROTECTED] Subject: Re: Niall's if/then/else tags? On Thu, 6 Sep 2001 [EMAIL PROTECTED] wrote: Date: Thu, 6 Sep 2001 20:49:36 -0700 From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Niall's if/then/else tags? I agree with this. In particular, I'd like to see tags of this type incorporated in JSPTL. They currently have if, and choose/when/otherwise, but no explicit then or else (although I believe those can be constructed from the others). The if/then/else pattern can indeed be constructed from choose/when/otherwise tags in JSPTL. The reason that Struts never had an else tag in the first place is that the syntax choices were all incredibly ugly, IMHO, given the restrictions on the way you need to nest things to make it work. The choose/when/otherwise pattern in JSPTL is the least objectionable, and has the additional advantage of gracefully implementing if ... else if ... else if ... type patterns as well. Given that choose/when/otherwise does this (and more), I would be somewhat surprised if the JSPTL expert group was willing to consider adding explicit if/then/else tags as well (because they would be redundant). But the best way to find that out would be to provide feedback on the JSPTL early access release (available via http://jakarta.apache.org/taglibs) to the email address included in the docs. -- Martin Cooper Craig - Original Message - From: Ted Husted [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 06, 2001 12:57 PM Subject: Re: Niall's if/then/else tags? My take on this is here http://www.mail-archive.com/struts-user@jakarta.apache.org/msg14158.html I'm personally not in favor of distributing tags with Struts that do not depend on Struts application resoures (mappings, messages). General purpose tags can be hosted at Jakarta Taglibs. At some point, the Struts bean and logic tags will end up over there too. If someone wanted to re-package the Struts logic tags for Jarkarta Taglibs, and included Nial's extensions, I'm sure they would be well received. Ditto for the bean tags. They already have i18n and form tags that are similar to the Struts versions. -Ted. [EMAIL PROTECTED] wrote: Hi. Just wondering what the status is on Niall's IF/THEN/ELSE tags being added to the nightly build? Cheers, Dave
RE: Re[2]: New name for Components / Extended Templates?
Portlet gets my votes as well. -Original Message- From: Oleg V Alexeev [mailto:[EMAIL PROTECTED]] Sent: 28 June 2001 21:27 To: [EMAIL PROTECTED] Subject: Re[2]: New name for Components / Extended Templates? Hello Chuck, Thursday, June 28, 2001, 11:14:00 PM, you wrote: CS How about Portlet? When I look at the features that's the first thing that CS comes to mind. Good choice. Components, blocks, pieces - all this terms do not point to the general position of this package. Portlets term is clear and easy to understand. CS -Original Message- CS From: Ted Husted [mailto:[EMAIL PROTECTED]] CS Sent: Thursday, June 28, 2001 1:51 PM CS To: [EMAIL PROTECTED] CS Subject: Re: New name for Components / Extended Templates? CS What name would make sense to you, Jonathan? CS Jonathan wrote: Please just make the name something that makes sense. Something that implies its function. -- Best regards, Olegmailto:[EMAIL PROTECTED]
RE: Re[2]: New name for Components / Extended Templates?
A little portal :-) -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: 28 June 2001 23:36 To: [EMAIL PROTECTED]; Oleg V Alexeev Subject: Re[2]: New name for Components / Extended Templates? Sorry to be a bit dense, but 'portlets' isn't at all clear to me. Given that I know what 'applets' and 'servlets' are, I would have guessed that 'portlets' had something to do with a TCP/IP (or maybe HTTP) port, but I can't see how this would relate to Components, so I think I must be wrong. What's a portlet? -- Martin Cooper At 01:27 PM 6/28/01, Oleg V Alexeev wrote: Hello Chuck, Thursday, June 28, 2001, 11:14:00 PM, you wrote: CS How about Portlet? When I look at the features that's the first thing that CS comes to mind. Good choice. Components, blocks, pieces - all this terms do not point to the general position of this package. Portlets term is clear and easy to understand. CS -Original Message- CS From: Ted Husted [mailto:[EMAIL PROTECTED]] CS Sent: Thursday, June 28, 2001 1:51 PM CS To: [EMAIL PROTECTED] CS Subject: Re: New name for Components / Extended Templates? CS What name would make sense to you, Jonathan? CS Jonathan wrote: Please just make the name something that makes sense. Something that implies its function. -- Best regards, Olegmailto:[EMAIL PROTECTED]
RE: Extensions to Struts
Rob, I guess you already saw the previous thread about this, but in case you didn't Olegs requirement for his bean factory are in the following messages: http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg01763.html http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg01724.html Personally we extended ActionServlet for the following reasons: 1) To parse an additional XML configuration file and store the instantiated objects in application scope. 2) To parse an additional XML file and use it to configure a framework built on top of Struts. 3) Override the logging mechanism and add a Console window for testing purposes. 4) To override the processPopulate() method to handle dynamic properties - although as someone recently pointed out it probably would have been better to change Bean/Property utils instead - although this way I can use Struts out of the box rather than actually modifying struts classes. Perhaps processing configuration files should be dealt with separately with some kind of DigesterFactory as I believe this is probably the most common reason for extending ActionServlet - being able to just specify an input stream, dtd file name, set of rules and any methods the digester is configured packages everything nicely into a single object per config file. It would also alow testing of these kinds of thing outside the servlet environment - very handy. Ron, I liked your Extension/ExtensionServlet - obviously to satisfy everyone it would have to be able to be registered at various points in ActionServlets process() method as well as the init() (e.g. processPreprocess() and processPopulate() methods). One small comment - shouldn't you also override the destroy() method in ActionServlet and iterate through destroy() methods in the Extensions (and the same for reload() with reload() in the extension calling its destroy/init methods)? Niall -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 28 June 2001 20:50 To: [EMAIL PROTECTED] Subject: Re: Extensions to Struts Note that the main motivation for the extensions package at the link below was to avoid having to always extend the ActionServlet. As far as altering the behavior of things like the action classes, forwards, etc.. I think a good event/listener model could be used for most of those cases. I think that the event/listener registration could neatly be tied into the extensions package. You would create your org.strutsx.extensions.Extension subclass, and register for all of the events you are interested in there. --Ron Ted Husted writes: Rob, If you have a chance take at look at this http://www.rpsenterprises.com/struts/index.html and let us know what you think. I agree that is very important that we look for ways for people to add new functionality without subclassing everything in sight. Leland, Rob wrote: It would be nice if struts could be extended without having to place new code under the org.apache.struts.action classes, but just by dropping a separate jar file under some directory that would self-register. So what is the best way to extend struts so that it stays lean ? ... /
RE: Struts 1.0 Released - Looking forward to 1.1!!!!!!!
Ted, I submitted a patch a month ago, following a go-ahead from Craig to a bugzilla I raised and it got zero response. Now maybe it wasn't any good and probably I should have put more explanation, but a response saying something would have been great. That was the reason I put the comment about a committer being assigned - I'd rather know there was someone with power interested rather than waste effort again. I also submitted code for if/else and switch/case tags - if you've got the time, I would appreciate your opinion on those as well. 1) PATCH: [Bug 1683] - Change Struts tags to be more granular in their design: This patch affected the following tags and involved re-factoring code out of the doStartTag() method so that Struts tags could be more easily sub-classed and individual bits of functionality overriden - a good example of where this could be used is, generating names which include the index value when embedded in an IterateTag. BaseFieldTag.java, BaseFieldTag.java, ButtonTag.java, CancelTag.java, CheckboxTag.java, ImageTag.java, ImgTag.java, MultiboxTag.java, RadioTag.java, ResetTag.java, SelectTag.java, SubmitTag.java, TextareaTag.java http://www.mail-archive.com/struts-dev%40jakarta.apache.org/msg01450.html I believe quite a few of these tags have been changed since I submitted this so unless CVS is clever I gues its now can't be applied and was a waste of time. 2) IF / ELSE and SWITCH/CASE Tags: These tags are basically just new wrappers for existing Struts functionality - the key classes extend the existing Struts CompareTagBase. I have a new version since I submitted them which includes the ability to specify condtions on the case tag - rather than just having to be equal - if its of interest I can send it. http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg01372.html Niall -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: 21 June 2001 11:13 To: [EMAIL PROTECTED] Subject: Re: Struts 1.0 Released - Looking forward to 1.1!!! Just a note: Committers make the final decision about whether something is added to the official distribution, but we do not control the contribution or development process. Everyone is invited and encouraged to discuss how they would implement features here on the dev list, and then go off and implement them -- usually for use in your own project. When you bring the code back to list, then we can make the decision about whether it's a good fit with the Struts core. But, hey, don't wait on us guys -- do what *you* need to do, and then show us the code when you're ready. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/ Niall Pemberton wrote: These areas are currently unassigned on the ToDo list and presumably need a committer to take control. If someone is assigned I am more than willing to contribute to these (and other) areas.
RE: Struts 1.0 Released - Looking forward to 1.1!!!!!!!
Another tag works well for me :-) - we have our own customised versions of struts tags to do this. I submitted a Bugzilla to make tags more granular so that individual bits of behaviour (like generating the name )could be overriden. Unfortunately :-( it didn't make it into Struts 1.0 and I think quite a few of the classes have been changed since, so it may have been wasted effort. http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg01450.html -Original Message- From: Jeff Trent [mailto:[EMAIL PROTECTED]] Sent: 20 June 2001 21:59 To: [EMAIL PROTECTED] Subject: Re: Struts 1.0 Released - Looking forward to 1.1!!! I hear what you are saying Niall, but again, I'd sooner introduce a new tag like 'html2' before I'd change existing tags/property names - especially now that struts 1.0 is out and feels more formally defined if you know what I mean. Too bad there was no way to label something 'depcrecated' in a taglib! Imagine seeing output to System.err stating that a tag has been deprecated - pretty cool I think... - Original Message - From: Niall Pemberton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 4:23 PM Subject: RE: Struts 1.0 Released - Looking forward to 1.1!!! Jeff, You might be right, but the question is is it the right thing to do? - if it is, then it would be a shame to have to code indexed='true' from now to eternity - perhaps there could be a way of specifying the default behaviour in the struts-config. Niall -Original Message- From: Jeff Trent [mailto:[EMAIL PROTECTED]] Sent: 20 June 2001 14:09 To: [EMAIL PROTECTED] Subject: Re: Struts 1.0 Released - Looking forward to 1.1!!! Niall, Your approach is simpler. However, I believe a lot of legacy code would break if that kind of change were to be made. I think a separate property name is warranted here. - jeff - Original Message - From: Niall Pemberton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 19, 2001 7:58 PM Subject: RE: Struts 1.0 Released - Looking forward to 1.1!!! Martin, Ideally I would like Struts html tags (text, checkbox, hidden etc.) to automatically generate the name with the subscript if its embedded in an IterateTag so that iterated beans are automatically updated by Struts. For example: logic:iterate id=list name=formExample property=beanArray trtdhtml:text name=list property=desc//td /logic:iterate generates: input type=text name=beanArray[0].desc value=../ input type=text name=beanArray[1].desc value=../ input type=text name=beanArray[2].desc value=../ etc. etc. I realise you can do this with the indexId scripting variable, but this is simpler. I raised it before (prior to indexId and getIndex method) in the following messages: http://www.mail-archive.com/struts-user@jakarta.apache.org/msg05231.html http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg00975.html What do you think? Niall -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: 19 June 2001 05:28 To: [EMAIL PROTECTED] Subject: Re: Struts 1.0 Released - Looking forward to 1.1!!! Niall, Regarding auto-generating a subscript, what do you have in mind? The indexId attribute was added to the iterate tag recently (just before Struts 1.0) so that a scripting variable can be created containing the value of the current index. However, from the description in the TODO list, I'm not sure if that's the same thing or not. Thanks! -- Martin Cooper - Original Message - From: Niall Pemberton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 18, 2001 6:46 PM Subject: Struts 1.0 Released - Looking forward to 1.1!!! Congratulations and thank you for Struts 1.0 - a great product. Now I know you guys deserve a well earned rest now Struts 1.0 is released, but what sort of timescale do you envisage work starting on 1.1? I am particularly interested for starters in: 1) ActionForms with dynamic properties. 2) If/Else and Switch/Case tags (I submitted tags which do this to the dev list a while ago). 3) Improved Iteration Support - auto-generating a subscript. These areas are currently unassigned on the ToDo list and presumably need a committer to take control. If someone is assigned I am more than willing to contribute to these (and other) areas. Niall -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 16 June 2001 01:23
RE: Struts 1.0 Released - Looking forward to 1.1!!!!!!!
Martin, Ideally I would like Struts html tags (text, checkbox, hidden etc.) to automatically generate the name with the subscript if its embedded in an IterateTag so that iterated beans are automatically updated by Struts. For example: logic:iterate id=list name=formExample property=beanArray trtdhtml:text name=list property=desc//td /logic:iterate generates: input type=text name=beanArray[0].desc value=../ input type=text name=beanArray[1].desc value=../ input type=text name=beanArray[2].desc value=../ etc. etc. I realise you can do this with the indexId scripting variable, but this is simpler. I raised it before (prior to indexId and getIndex method) in the following messages: http://www.mail-archive.com/struts-user@jakarta.apache.org/msg05231.html http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg00975.html What do you think? Niall -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: 19 June 2001 05:28 To: [EMAIL PROTECTED] Subject: Re: Struts 1.0 Released - Looking forward to 1.1!!! Niall, Regarding auto-generating a subscript, what do you have in mind? The indexId attribute was added to the iterate tag recently (just before Struts 1.0) so that a scripting variable can be created containing the value of the current index. However, from the description in the TODO list, I'm not sure if that's the same thing or not. Thanks! -- Martin Cooper - Original Message - From: Niall Pemberton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 18, 2001 6:46 PM Subject: Struts 1.0 Released - Looking forward to 1.1!!! Congratulations and thank you for Struts 1.0 - a great product. Now I know you guys deserve a well earned rest now Struts 1.0 is released, but what sort of timescale do you envisage work starting on 1.1? I am particularly interested for starters in: 1) ActionForms with dynamic properties. 2) If/Else and Switch/Case tags (I submitted tags which do this to the dev list a while ago). 3) Improved Iteration Support - auto-generating a subscript. These areas are currently unassigned on the ToDo list and presumably need a committer to take control. If someone is assigned I am more than willing to contribute to these (and other) areas. Niall -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 16 June 2001 01:23 To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [ANNOUNCEMENT] Struts 1.0 (Final) Released As promised at JavaOne, the Struts project team is proud to announce the availability of Version 1.0 (final release) of the Struts Framework. The binary distribution is available at: http://jakarta.apache.org/builds/jakarta-struts/release/v1.0/ and the source distribution is available at: http://jakarta.apache.org/builds/jakarta-struts/release/v1.0/src/ Craig McClanahan
Struts 1.0 Released - Looking forward to 1.1!!!!!!!
Congratulations and thank you for Struts 1.0 - a great product. Now I know you guys deserve a well earned rest now Struts 1.0 is released, but what sort of timescale do you envisage work starting on 1.1? I am particularly interested for starters in: 1) ActionForms with dynamic properties. 2) If/Else and Switch/Case tags (I submitted tags which do this to the dev list a while ago). 3) Improved Iteration Support - auto-generating a subscript. These areas are currently unassigned on the ToDo list and presumably need a committer to take control. If someone is assigned I am more than willing to contribute to these (and other) areas. Niall -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 16 June 2001 01:23 To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [ANNOUNCEMENT] Struts 1.0 (Final) Released As promised at JavaOne, the Struts project team is proud to announce the availability of Version 1.0 (final release) of the Struts Framework. The binary distribution is available at: http://jakarta.apache.org/builds/jakarta-struts/release/v1.0/ and the source distribution is available at: http://jakarta.apache.org/builds/jakarta-struts/release/v1.0/src/ Craig McClanahan
RE: Re[2]: [PROPOSAL] Struts Extensions
Oleg, Do you not think that if there was easier/standard mechanism in Struts to initialise resources it would be valid to use that for your bean-factory, even if you still needed to sub-class ActionServlet to do your processPreprocess stuff? This gets my vote. Niall -Original Message- From: Oleg V Alexeev [mailto:[EMAIL PROTECTED]] Sent: 11 June 2001 21:00 To: [EMAIL PROTECTED] Subject: Re[2]: [PROPOSAL] Struts Extensions Hello Martin, But how about such situation as follows. I can store bean-factory object in application scope. I can use it in any action to perform bean producing. But main idea of bean-factory is to perform _automatic_ bean generation by name of the action. For example - in struts-config or in external config file I define mapping between action and some kind of bean. All beans from mappings must be created to be ready to use it in appropriate actio at request processing phase before Action.perfom method call. How can I do it without extending ActionServlet? I think there is one way to implement this with current struts API - extend ActionServlet and redefine processPreprocess method to perform all 'before Action.perfom' stuff. So struts control-gear can be extended to to register external classes or servlets to perform some activity at key points of request processing - ActionForm processing, Action processing, etc. Now it can be implemented only via ActionServlet extending - is not scalable solution for my mind. Sunday, June 10, 2001, 11:20:22 PM, you wrote: MC I like this idea. I think David is right - a lot of people do extend MC ActionServlet just to initialize resources. While this idea wouldn't remove MC all of the reasons to build a custom servlet, it would provide a MC systematic - and potentially simpler - way to solve a common problem. MC -- MC Martin Cooper MC - Original Message - MC From: David Winterfeldt [EMAIL PROTECTED] MC To: [EMAIL PROTECTED] MC Sent: Sunday, June 10, 2001 11:37 AM MC Subject: Re: [PROPOSAL] Struts Extensions It might be nice if there was a way to register an interface with the ActionServlet in the config file for it to initialize a service. All the ValidatorServlet I made does is parse the xml file with the Digester and put an object into application scope. If a class could be registered, then a servlet wouldn't hang around for no reason and it wouldn't need to be defined in the web.xml. And it sounds like a lot of people extend the ActionServlet just to initialize resources on startup. David --- Ted Husted [EMAIL PROTECTED] wrote: I agree that most extensions would be best written as independant servlets that plug into the application alongside the Struts ActionServlet. Though, I'm not sure they would need to register with the ActionServlet to access other parts of the framework. I haven't worked with the Digester directly, but most of the other Struts services are already exposed through the application context. Custom tags, for example, already access the Action Mappings this way. So any other servlet in the application (since that's all JSP's are) should be able to do the same. Another example is the Generic Connection Pool. The datasource is exposed through the application context and other services, like the TagLibs JDBC tags, can use the pool without knowing anything about Struts (or Struts knowing anything about them). So I would suggest that if there are other services that an extension needs to share that we expose them through the Application context. Oleg V Alexeev wrote: To support flexible extensions mechanism for struts there are can be made some additions to the core structure of the framework - 1. Add ability to register components or external servlets (at application level) via struts-config file. 2. Give such external components or servlets ability to use action mappings database from ActionServlet. 3. Extend core API of struts to support pluggable extensions - for example use event model or direct calls via registrations in action mappiongs database. The best way for my mind is to write external servlets, register it in struts ActionServlet and use it as external services. This approach can be useful in case of mutliple ActionServlet instances in one application - every ActionServlet subscribe to use and uses some amount of external services. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ -- Best regards, Olegmailto:[EMAIL PROTECTED]
RE: Proposal: Support nested tags where only attributes can be used
How about a custom tag, which combines bean:message and template:get functionality? For example h1Title is myTaglib:message template=page suffix=.title//h1 I've attached a tag like this. Niall -Original Message- From: Dean Wampler [mailto:[EMAIL PROTECTED]] Sent: 15 June 2001 17:28 To: 'Niall Pemberton'; [EMAIL PROTECTED] Cc: Dean Wampler (E-mail) Subject: RE: Proposal: Support nested tags where only attributes can be used I wanted to avoid writing stuff like template:insert template=t.jsp template:put name=pageTitle direct=true bean:message key=login.title/ /template:put template:put name=pageThis direct=true bean:message key=login.this/ /template:put template:put name=pageThat direct=true bean:message key=login.that/ /template:put template:put name=pageTheOther direct=true bean:message key=login.theOther/ /template:put ... /template:insert for every single page when I could just define one thing for each page: template:insert template=t.jsp template:put name=page content=login direct=true/ /template:insert and have the template page t.jsp construct all the other items dynamically. amarda.tld MessageTag.java
RE: Proposal: Support nested tags where only attributes can be used
For the example you give, the following works just as well in existing Struts: In your JSP page: template:insert template=t.jsp template:put name=pageTitle direct=true bean:message key=login.title/ /template:put /template:insert Now, in t.jsp %@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % ... h1Title is template:get name=pageTitle//h1 Niall -Original Message- From: Dean Wampler [mailto:[EMAIL PROTECTED]] Sent: 15 June 2001 01:28 To: [EMAIL PROTECTED] Cc: Dean Wampler (E-mail) Subject: Proposal: Support nested tags where only attributes can be used I'm new to struts, so bear with me. I have been working with the bean and template tags. I have found that a straightforward (if a bit tedious to do...) enhancement would make it much easier to construct JSP pages in ways useful for me. Basically, I would like to use nested tags to specify some information to outer tag, information that currently is specified only through attributes. Here's an example. Suppose I have a JSP page that uses the template:insert construct: ... %@ taglib uri=/WEB-INF/struts-template.tld prefix=template % ... template:insert template=t.jsp template:put name=pageName content=login direct=true/ /template:insert Now, in t.jsp, I would like to use the message tag with the parameter pageName as a prefix. Something that might look like: %@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % ... h1Title is bean:message key='template:get name=pageName/%=.title%'//h1 or perhaps h1Title is bean:message key='%=template:get name=pageName/+.title%'//h1 There are two problems: (i) this is ugly and not easy to use by most HTML designers, (ii) it doesn't work anyway. By the time the code gets compiled to a servlet, it appears that the key='...' expression ends up key=''. That is, 'template:get name=pageName/' is effectively empty. However, the following message tag structure would solve both problems and support the capability I'm after (indentation is for clarity...): h1Title is bean:message bean:key template:get name=pageName/.title /bean:key /bean:message /h1 In other words, support nested tags to specify the key and perhaps other attributes, so that specifying the values of the attributes is more flexible. Many of the ant tasks support capabilities like this and it greatly enhances the power and flexibility of build files. I have looked at the code for MessageTag (and others). This extension is straightforward to implement and it can be done in a backwards compatible way (that is, the old attribute syntax will still work fine). I'm willing to implement the changes, but before I do so, I wanted to check with the rest of you to see if there are any good reasons not to proceed. Thanks, dean Dean Wampler, Ph.D. [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://www.powerhousetechnology.com/ I want my tombstone to say: Unknown Application Error in Dean Wampler.exe. Application Terminated. [OK] [Cancel]
RE: Proposal: Support nested tags where only attributes can be used
I dont really get what your saying. In your template (i.e. t.jsp) you define the formatting for the common look and feel of all your pages, for example page titles, a side bar and footers. If on some pages you don't need all of them you just leave them out - for example if you didn't need a footer then don't do a template:get for it on your jsp page - it still works fine. If you have specific messages unique to a page them just put them straight on the page - if you want to prefix them with the page name then it seems easier to me to just specify it straight in bean:message key=pagename.something format. Personally we don't tie our messages to pages, more to the business area, that way they're often re-used among pages. I don't know if this is useful to you because I didn't really get what your trying to resolve. Niall -Original Message- From: Dean Wampler [mailto:[EMAIL PROTECTED]] Sent: 15 June 2001 01:57 To: [EMAIL PROTECTED] Subject: RE: Proposal: Support nested tags where only attributes can be used Interesting! I didn't know that. Certainly that would help. It's actually another example of the kind of flexibility I'm thinking about. One disadvantage, though. It requires that the outer page know all the messages the inner page wants to use. I would rather keep this coupling to a minimum (e.g., just pass the prefix, like I've shown), especially if I have lots of similar outer pages (and I will...). This way, if I add and use a new message or resource in the inner page I don't have to add corresponding tags to the outer pages, too. Thanks, dean -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 13, 2001 5:43 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Proposal: Support nested tags where only attributes can be used For the example you give, the following works just as well in existing Struts: In your JSP page: template:insert template=t.jsp template:put name=pageTitle direct=true bean:message key=login.title/ /template:put /template:insert Now, in t.jsp %@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % ... h1Title is template:get name=pageTitle//h1 Niall -Original Message- From: Dean Wampler [mailto:[EMAIL PROTECTED]] Sent: 15 June 2001 01:28 To: [EMAIL PROTECTED] Cc: Dean Wampler (E-mail) Subject: Proposal: Support nested tags where only attributes can be used I'm new to struts, so bear with me. I have been working with the bean and template tags. I have found that a straightforward (if a bit tedious to do...) enhancement would make it much easier to construct JSP pages in ways useful for me. Basically, I would like to use nested tags to specify some information to outer tag, information that currently is specified only through attributes. Here's an example. Suppose I have a JSP page that uses the template:insert construct: ... %@ taglib uri=/WEB-INF/struts-template.tld prefix=template % ... template:insert template=t.jsp template:put name=pageName content=login direct=true/ /template:insert Now, in t.jsp, I would like to use the message tag with the parameter pageName as a prefix. Something that might look like: %@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % ... h1Title is bean:message key='template:get name=pageName/%=.title%'//h1 or perhaps h1Title is bean:message key='%=template:get name=pageName/+.title%'//h1 There are two problems: (i) this is ugly and not easy to use by most HTML designers, (ii) it doesn't work anyway. By the time the code gets compiled to a servlet, it appears that the key='...' expression ends up key=''. That is, 'template:get name=pageName/' is effectively empty. However, the following message tag structure would solve both problems and support the capability I'm after (indentation is for clarity...): h1Title is bean:message bean:key template:get name=pageName/.title /bean:key /bean:message /h1 In other words, support nested tags to specify the key and perhaps other attributes, so that specifying the values of the attributes is more flexible. Many of the ant tasks support capabilities like this and it greatly enhances the power and flexibility of build files. I have looked at the code for MessageTag (and others). This extension is straightforward to implement and it can be done in a backwards compatible way (that is, the old attribute syntax will still work fine). I'm willing to implement the changes, but before I do so, I wanted to check with the rest of you to see if there are any good reasons not to proceed. Thanks, dean Dean Wampler, Ph.D. [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http
RE: reset function
If the form is in session scope and its not a wizard style form then it gives you an opportunity to initialise whatever properties you want to. Say you had a feedback form where you have a name field, comments field and priority field - each time you want to show a new default form. You probably want to leave the name field so the user doesn't have to key it in again - clear the comments field and set the priority to a default e.g. low - you would code in the reset() method to clear the comments and set the priority. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 15 June 2001 01:00 To: [EMAIL PROTECTED] Subject: reset function ** Note: This e-mail is subject to the disclaimer contained at the bottom of this message. ** : I confuse about the 'reset' function in the actionForm. The document said this method reset all bean properties to their default state. Up to knowledge, the actionForm can be stored in request scope and session scope. In the request scope, the actionForm just created by actionServlet or HTML:form so there is no need to do reset at all. I think we can initial the properties in the constructor. In the session scope, developer can maps multiple JSP pages to one actionForm to provide wizard like application. The reset function will reset bean's properties previous populate. So, what is the aim of the reset function? Am I miss something? Regards Kelvin Regards Kelvin : ** ** The information transmitted in this message and attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of CGU Insurance. This message has been scanned for viruses and cleared by MailMarshal. :
RE: PropertyUtils Enhancement Source Code
Johan
I take that as definite No! with no room for negotiation - oh shit, better
tell my boss I did it all wrong ;)
As I said to William...
The problem of implementing this using the Struts BeanUtils is that it has
been deprecated because its been donated to the Jakarta Commons project -
will we be able to persuade Jakarta Commons to include this when it doesn't
have anything to do with JavaBeans?
My interface is more minimalistic than yours because its tightly focused on
all Struts needs to do i.e. get and set values. How people implement it is
up to them - how properties a stored (doesn't have to be a HashMap), getting
a list of properties (i.e your getBeanProperties() method) and type
conversion can all be implemented in your own flavour of ActionForm (which
is what we did).
Thanks for your offer of code - these aspects of our system are done and
working and I really want to see what Struts does because if it suits us,
better to use the vanilla Struts solution.
Niall
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]]
Sent: 30 May 2001 10:07
To: [EMAIL PROTECTED]
Subject: RE: PropertyUtils Enhancement Source Code
1) Created a DynamicProperties interface which has the
following methods:
public String getValue(String property);
public String getValue(int index, String property);
public void setValue(String property, String value);
public void setValue(int index, String property, String value);
Almost the samething i have now. I only have some more (and i
don't have at
this time the index because
i don't believe that is nessesary, because BeanUtils / PropertyUtils are
taking care of that!
This is My interface that i use for quite sometime know.
public interface Property
{
public java.util.Map getBeanProperties(); // Is
needed for the new describe
method in PropertyUtils!!
public Object getBeanProperty(String sPropertyName);
public Class[] getParameterTypes(String sName); // You should be
able to get
the types of the property.
public void setBeanProperty(String sPropertyName, Object oPropertyValue);
}
2) Sub-classed ActionServlet and changed the
processPopulate method to
populate the ActionForm using the above setters if its an instance of
DynamicProperties or using its normal reflection if not.
No!
ActionServlet doesn't have to change at all!!
Everychange must only be done in the PropertyUtils and BeanUtils.
What does ActionServlet to do with beans? Nothing. Struts only
uses the Bean
And property utils
for filling the beans. At this time only with reflection but i
changed Bean
And PropertyUtils
so that it looks for the above Interface Property and then calls
the get or
set of that Property Interface.
Here some code i changed in the PropertyUtils class:
public static void setSimpleProperty(Object bean, String name,
Object value)
{
// If it is of Property
if (bean instanceof Property)
{
// Use that one instead of Reflection (you create
youre own reflection
interface)
((Property) bean).setBeanProperty(name, value);
}
else
{
// Retrieve the property setter method for the
specified property
PropertyDescriptor descriptor =
getPropertyDescriptor(bean, name);
if (descriptor == null)
throw new NoSuchMethodException(Unknown
property ' + name + ');
Method writeMethod = getWriteMethod(descriptor);
if (writeMethod == null)
throw new NoSuchMethodException(Property
' + name + ' has no setter
method);
// Call the property setter method
Object values[] = new Object[1];
values[0] = value;
writeMethod.invoke(bean, values);
}
}
3) Modified Struts tags to retrieve bean values using the above
getters if
its an instance of DynamicProperties or using its normal reflection if
not.
No tag doesn't have to be changed in my way. Because all is done throught
the Property and BeanUtils classes!!!
4) Created a sub-class of ActionForm (DynamicActionForm) which
implements
our DynamicProperties interface.
No this can be done by the programmers themself just do this:
public class DynamicForm extends ActionForm implements
org.apache.struts.util.Property
And then they must implement the four methods.
Ofcourse Struts could create a default DynamicForm that uses a Hashmap for
storing its properties
only the getParameterTypes would be a bit difficut then! (i will
think this
over)
Now we only have one DynamicActionForm and don't have to go round
setting up
loads of different ActionForm classes. The DynamicActionForm is a bit
simplistic and wouldn't suit everyones needs, but the advantage
of this is
people could create their own concrete implementations.
If they just uses my interface then it is very
RE: PropertyUtils Enhancement Source Code
The problem with your suggestion of implementing this using the Struts BeanUtils is that it has been deprecated because its been donated to the Jakarta Commons project. I understand Struts will be changed to use the Jakarta Commons version in 1.1. BeanUtils are utility methods for populating JavaBeans and the question is would we be able to persuade Jakarta Commons to include this when it doesn't have anything to do with JavaBeans? This should not be that big of an issue. AND, DynamicPropertyMappers (or whatever we want to call them) has everything to do with JavaBeans in my opinion. -will OK so get on bugzilla and submit your proposal as an enhancement to Jakarta Commons. AND, I don't see this in the JavaBeans spec (nice as it would be). http://java.sun.com/products/javabeans/docs/spec.html Niall
RE: html:errors/ tag
I haven't done this, but if you look in the comments at the start of ActionServlet it say you need to add a factory parameter to the web.xml file, something like this: servlet servlet-nameaction/servlet-name servlet-classorg.apache.struts.action.ActionServlet/servlet-class init-param param-nameapplication/param-name param-valuemyApp.ApplicationResources/param-value /init-param init-param param-nameconfig/param-name param-value/WEB-INF/struts-config.xml/param-value /init-param init-param param-namefactory/param-name param-valuemyPackage.myMessageResourcesFactory/param-value /init-param load-on-startup2/load-on-startup /servlet Niall -Original Message- From: Muthu Kannappan [mailto:[EMAIL PROTECTED]] Sent: 24 May 2001 00:13 To: [EMAIL PROTECTED] Subject: RE: html:errors/ tag Hi I have written a subclass of org.apache.struts.util.MessageResources and also a subclass of org.apache.struts.util.MessageResourcesFactory, and made my implementation so that when html:errors/ tag is called it gets the error message from my database instead of the ActionResources.properties file. But the problem that I have got now is, How do I set that up in Struts and which XML file or other file have I to modify. Could you please help me out in this. Thanks Kanna You can subclass org.apache.struts.util.MessageResources to provide your own database implementation of a resource bundle (as opposed to the common properties implementation via org.apache.struts.util.PropertyMessageResources), put an instance of your subclass in a servlet context (application-scope) attribute, and then use the html:errors tag's bundle attribute to specify the name you gave to the servlet context (application-scope) attribute. At least that should be the theory behind it, though I have not done it myself. -- Stoehr P.S. You could also have the application resource bundle be an instance of your MessageResources subclass by creating a subclass of org.apache.struts.util.MessageResourcesFactory that creates instances of your MessageResources subclass, and then specify the new factory in the ActionServlet's factory init parameter. -Original Message- From: SESHADRI Sudarshan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 22, 2001 03:52 AM To: '[EMAIL PROTECTED]' Subject: RE: html:errors/ tag Hi Kanna please send me the answer if u find it. thanks Sudarshan tks Sudarshan Tel: office : 9218 6823Fax: 9218 6455 / 9218 6916 Email: [EMAIL PROTECTED] -Original Message- From: Muthu Kannappan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 23 May 2001 8:42 To: [EMAIL PROTECTED] Subject: html:errors/ tag Hi I have been trying to use struts and wanted to use the html:errors/ tag. I wanted to the error messages to be read from a database instead of the ActionResources properties file. Could you let me know what exactly I am suppose to do to achive that. I wanted to changed the code at the place where it was looking for the properties files and make it look into the database. Could any one suggest me how to do that or has anybody done that already. Thanks Kanna Get free email and a permanent address at http://www.netaddress.com/?N=1
PATCH: [Bug 1683] - Change Struts tags to be more granular in their design
Attched is a patch file for a number of tags in the html package.
Niall
-Original Message-
From: Niall Pemberton [mailto:[EMAIL PROTECTED]]
Sent: 14 May 2001 02:00
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [Bug 1683] Changed - Change Struts tags to be more granular
in their design
Attached is a patch file.
Niall
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 10 May 2001 03:30
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Bug 1683] Changed - Change Struts tags to be more granular in
their design
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1683
*** shadow/1683 Wed May 9 10:20:03 2001
--- shadow/1683.tmp.15994 Wed May 9 19:29:35 2001
***
*** 5,11
| Status: NEW Version: 1.0 Beta 1
|
| Resolution:Platform: Other
|
| Severity: Enhancement OS/Version: Other
|
! | Priority: Component: Custom
Tags |
+-
---+
| Assigned To: [EMAIL PROTECTED]
|
| Reported By: [EMAIL PROTECTED]
|
--- 5,11
| Status: NEW Version: 1.0 Beta 1
|
| Resolution:Platform: Other
|
| Severity: Enhancement OS/Version: Other
|
! | Priority: High Component: Custom
Tags |
+-
---+
| Assigned To: [EMAIL PROTECTED]
|
| Reported By: [EMAIL PROTECTED]
|
***
*** 55,58
P.S. I would be happy to help with this, although I havent used
Ant or CVS and
! am not currently set up to do that.
--- 55,68
P.S. I would be happy to help with this, although I havent used
Ant or CVS and
! am not currently set up to do that.
!
! --- Additional Comments From [EMAIL PROTECTED]
2001-05-09 19:29 ---
! This is a good idea.
!
! If you could provide unified diffs of the recommended changes,
as described on
! the Jakarta web site:
!
! http://jakarta.apache.org/site/source.html
!
! that would be ideal, because they can be applied in an
automated fashion.
cvs diff -u d:/project/jakarta-struts/src/share/org/apache/struts/taglib/html
cvs server: Diffing d:/project/jakarta-struts/src/share/org/apache/struts/taglib/html
Index:
d:/project/jakarta-struts/src/share/org/apache/struts/taglib/html/BaseFieldTag.java
===
RCS file:
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/taglib/html/BaseFieldTag.java,v
retrieving revision 1.7
diff -u -r1.7 BaseFieldTag.java
---
d:/project/jakarta-struts/src/share/org/apache/struts/taglib/html/BaseFieldTag.java
2001/04/29 00:38:04 1.7
+++
+d:/project/jakarta-struts/src/share/org/apache/struts/taglib/html/BaseFieldTag.java
+2001/05/14 00:58:14
@@ -74,7 +74,6 @@
import org.apache.struts.util.RequestUtils;
import org.apache.struts.util.ResponseUtils;
-
/**
* Convenience base class for the various input tags for text fields.
*
@@ -153,34 +152,68 @@
// Create an appropriate input element based on our parameters
StringBuffer results = new StringBuffer(input type=\);
results.append(type);
- results.append(\ name=\);
+ results.append(\);
+
+// Prepare indvidual attributes for this element
+ prepareAttributes(results);
+
+ results.append();
+
+ // Print this field to our output writer
+ResponseUtils.write(pageContext, results.toString());
+
+ // Continue processing this page
+ return (EVAL_BODY_TAG);
+
+}
+
+/**
+ * Prepares the individual attributes, appending them to the the given
+ * StringBuffer.
+ *
+ * @param results The StringBuffer that output will be appended to.
+ * @exception JspException if a JSP exception has occurred
+ */
+protected void prepareAttributes(StringBuffer results) throws JspException {
+
+ prepareName(results);
+
+results.append(prepareAttribute(accesskey, accesskey));
+ results.append(prepareAttribute(accept, accept));
+ results.append(prepareAttribute(maxlength, maxlength));
+ results.append(prepareAttribute(size, cols));
+ results.append(prepareAttribute(tabindex, tabindex));
+
+ prepareValue(results);
+
+ results.append(prepareEventHandlers());
+ results.append(prepareStyles());
+
+}
+/**
+ * Prepares the name attribute, appending it to the the given
+ * StringBuffer
RE: A struts-compatible controller
I am in the processing of customising Struts controller to do dynamic properties and would like to hear how you handled this. Niall -Original Message- From: Dan - Blue Lotus Software [mailto:[EMAIL PROTECTED]] Sent: 12 April 2001 17:51 To: Jakarta Struts Subject: A struts-compatible controller After looking at the various projects for delivering dynamic content over the Web, I set out to develop my own MVC/Model 2-based dynamic content engine. Well, after a few months of part time work and refactoring the design, the engine is working. The architecture is similar in concept to Struts, so it seemed logical to me to make the system compatible with struts. Looking at the architecture, I don't envision any issues in adding a Struts compatibility layer to my engine. In fact, it looks like I'll only have to build 3 adapter classes to get the code in a compatible state--to wrap the model, view, and controller beans of struts to be compatible with my own. I also plan to write an XSL file for converting Struts configuration files to those for my own engine. Of course, when this functionality is complete, I I can also get some realistic comparisons in terms of performance, as well. You may be wondering where I'm taking this. Well, looking at the to-do list for Struts, I see a couple of areas that I have already completed. Additionally, there are a couple of things mine does that Struts does not even attempt. Struts To-Do Items: 1) ActionForms with dynamic properties. If I understand what is required here, I believe my engine already has this functionality. 2) Workflow processing. My system supports workflow processing, where multiple actions (or the equivalent in my architecture) can be chained together, with workflows specified by the result of the previous action. 3) Role-based action execution. The controller can be configured to execute separate workflows depending upon system state. System state can be user roles, IP addresses, or any other item that is set on the session. Additional Features: a) Workflows can be attached to "realms" rather than individual URL requests. This allows the view to be a template .jsp file, with the content being set depending upon the incoming request. This template functionality does not require the use of a proprietary templating language, simplifying template creation considerably beyond that of Velocity. b) Dynamic page caching. Using the workflow concept, dynamic pages can generate HTML saved to disk. Depending upon the cache settings, future requests can be simply forwarded to the static HTML pages, improving performance considerably. c) Dynamic content caching. Dynamic content can be cached for rapid inclusion in a template JSP. This provides the ability to create Jetspeed-like functionality for news portal content. I intend to build Model classes that retrieve dynamic RSS-based content. This content can then be wrapped by a caching object. The resulting content can be included into a template, as mentioned in a). Now, I feel that I have something significant here. I'm strongly considering releasing it open source, and was wondering what the Struts developers' reaction would be to it. In particular, I'd like to incorporate the concepts, if not the code, into the Struts code base. Assuming I can make the controller completely compatible with the Struts controller, it would seem logical that my controller code live side-by-side (in a contrib directory, no doubt) with the Struts controller. Over time, functionality can be moved over between the two, creating a hybrid of sorts--taking the best from each. Any opinions on this? Strong attention would be paid at making my portal reverse-compatible with Struts actions, allowing developers to utilize existing beans designed for Struts with a different controller. The tag libraries, too, will remain 100% compatible with this controller. If interest is sufficient, I can also outline a sample configuration file for this controller, which should provide more information about how I think the two can work together. I just want to get a little developer reaction before I put my head on the chopping block. Thanks for your time. I look forward to reading your feedback on this. -dan -- Dan Kirkpatrick, Software Architect Blue Lotus Software+44 (0) 1224 575 985 [EMAIL PROTECTED] http://www.bluelotussoftware.com
REQUEST: Iterating Input Forms
Hi,
I proposed a change to Struts form tags (e.g. html:text, html:hidden,
html:checkbox etc) a few days ago so that they would generate appropriate
name attributes to automatically populate collections when embedded in the
logic:iterate tag.
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg05231.html
What I proposed was that tags such as the above would check if they are
embeded in an logic:iterate tag and generate a name attribute
appropriately. I changed the html:text, html:hidden, html:checkbox
tags so that instead of setting the name property to this.property they used
the following method to determine the name (and it worked OK).
private String decideName() {
// Check if this Tag is embedded in an Iterator Tag
Tag tag = findAncestorWithClass(this, IterateTag.class);
// No iterator, use the property as the name
if (tag == null)
return this.property;
IterateTag iterator = (IterateTag)tag;
int index = iterator.getLengthCount()-1;
return iterator.getProperty()+"["+index+"]."+this.property;
}
(Addtionally the logic:iterate tag needs to be changed to have a
getLengthCount() method included).
Perhaps this is not a good idea causing too many problems with, for example,
compatibility or scope but I would appreciate some feed back. I'm sure if
this change is not suitable as it stands there are alternatives which would
make it work such as an new attribute which would cause this to be generated
or alternatively if you could provide a default method which sets the name
to this.property, but could be overriden so that the tags could be
sub-classed.
Any feed back would be appreciated.
Niall
This proposal would take Struts jsp such as:
logic:iterate id="list" name="formExample" property="beanArray"
trtdhtml:hidden name="list" property="code"//td
tdhtml:checkbox name="list" property="select"//td
tdhtml:text name="list" property="desc"//td
/tr
/logic:iterate
Would generate fields such as:
input type="hidden" name="beanArray[0].code" value=".."/
input type="checkbox" name="beanArray[0].select"/
input type="text" name="beanArray[0].desc" value=".."/
Causing Struts to automatically populate a collection of beans using:
formExample.getBeanArray(0).setCode(x);
formExample.getBeanArray(0).setDesc(x);
formExample.getBeanArray(0).setSelect(x);
Previous Related Threads:
form question
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg05210.html
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg05216.html
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg05231.html
logic:iterate and form controls, revisited
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg02128.html
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg04316.html
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg02145.html
logic:iterate and form input fields
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg01662.html
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg01646.html
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg01417.html
winmail.dat
RE: form question
I have the same problem - form fields embedded in an iterate tag.
Would it be possible to change tags such as CheckboxTag and BaseFieldTag so
that they detect when they are embedded in the "iterate" tag and format the
name attribute appropriately.
I tried changing these two tags replacing the following line in the the
doStartTag() method:
results.append(property);
With the following code and it worked well, automatically populating my
collection objects:
results.append(decideName());
/**
* Determine the name attribute
*/
private String decideName() {
// Check if this Tag is embedded in an Iterator Tag
Tag tag = findAncestorWithClass(this, IterateTag.class);
// No iterator, use the property as the name
if (tag == null)
return this.property;
IterateTag iterator = (IterateTag)tag;
int index = iterator.getLengthCount()-1;
return iterator.getProperty()+"["+index+"]."+this.property;
}
Niall
P.S. thanks for Struts - great framework.
-Original Message-
From: Uwe Pleyer [mailto:[EMAIL PROTECTED]]
Sent: 25 March 2001 07:24
To: [EMAIL PROTECTED]
Subject: Re: form question
Hey,
I had some hard nights fighting with exactly this problem and got
a solution
wich is not very elegant but works...
html:form action="/formAction.do"
table border="1" width="100%"
// some headings for the table
% int i = 0; %
logic:iterate name="Bean" property="beanItems" id="anything"
tr
td
html:text name="Bean" property='%= "beanItems[" + i +
"].amount"
%'/
/td
td
$bean:write name="Bean" property='%= "beanItems[" + i +
"].total"
%' filter="true" /
/td
td
html:checkbox name="Bean" property='%= "beanItems[" + i +
"].checkbox" %'/
/td
td
/tr
% i++; %
/logic:iterate
/table
html:submit/
/html:form
As you see, you use the collektion of your formbean directly. The
Bean needs
properties, getter and setter Methods according to the Javabean-Spec whats
the reason to change BeanItems to beanItems!
private Collection beanItems;
public Item getBeanItems(int index)
public void setBeanItems(int index, Item item)
public Item[] getBeanItems()
public void setBeanItems(Item[] items)
It's also important to configure your formbean with scope="session" in
Struts-config and never to destroy your Collection in the
reset-Method! The
HTML for the input field will show like this: input type="text"
name="beanItems[0].amount" value="123"
After submit Struts uses the following setter Method:
Bean.getBeanItems(0).setAmount("123"); As struts use the getBeanItems(i)
Method to get yor Item-Objects, there is no chance to create them in the
request-scope. There must be held from the moment you establish your
beanItems-Collection for output till the submit of the user in
session-scope.
Hope that helps
Uwe
JOEL VOGT schrieb:
Hi all,
I have a html form on a jsp page. This form has a table generated by the
logic iterate tag.
In each table row, there are two fields, one a checkbox and the other a
text field.
What I want is when the user clicks 'submit' all the values are sent to
an action form for storing and then to my servlet for processing.
How do I make a form that will automatically be populated by all these
values? In other words I'm stuffed please help ;)
Thanks, Joel.
Sample jsp:
html:form action="/formAction.do"
table border="1" width="100%"
// some headings for the table
logic:iterate name="Bean" property="BeanItems" id="bean"
tr
td
html:text name="bean" property="amount"/
/td
td
$bean:write name="bean" property="total" filter="true" /
/td
td
html:checkbox name="bean" property="checkbox"/
/td
td
/tr
/logic:iterate
/table
html:submit/
/html:form
How do I get these values into a form then servlet then database?
