Re: Re[2]: Client/Server Side Validation for Struts 1.1
I'm copying a posting I made to the user list (before I knew about the dev-list) as I think it has many similarities to the current discussions: The code I wrote has gone on hold due to outside circumstances and whilst I look at the Struts Validator. I'll also be thinking of a way of generating the html completely dynamically using XML (equivalent to the data-mapping tag below) and XSLT as the forms (potentially thousands) in the application have an identical look and feel. Regards, Sean --- All, If anyone read my last (and first) posting to the list they'll know that I'm new to Struts. Anyway, after deciding to plan on using Struts in my next project, I felt that for the application many Beans would be required for the many, many, many, forms. All of which will need extensive validation. So I decided that ideally one shouldn't need to define a Bean for each form, only define the data on the form to be picked up by the ActionServlet, validated and then passed to the custom Action class. Anyway, I thought that it would be a lot of work to implement and also read the current plans for version 1.1 (of Struts) and came up with a half-way house, for us in the interim. However, at the w/e I got bored and ended up writing my initial design and it is already just about useable. It's not complete and I'm sure there's lots of missing pieces and bugs. I intend to carry on with it this week as much as I can, but thought I'd just pass on more about it. Once it is more useable I'll willingly pass on the code to others, but it can't be easily back-engineered into newer releases of Struts. But at the least it may spark some ideas for the Struts developers. My implementation of course is very rough and there are much better ways to do it, and I'm in no doubt that the team (knowing the framework inside-out) could do it much better. (I also have other ideas that would be cool too) Anyway, he's how it is used: (I've directly re-coded existing classes where necessary, and also made a new package. All original Struts functionality remains - I hope!.) 1. in the struts-config.xml file you have a definition for your forms, e.g. action-mappings action path=/order type=com.bar.fu.OrderAction name=orderForm input=/order.jsp forward name=success path=/confirmOrder.jsp / /action /action-mappings data-mappings data-mapping name=orderForm property-mapping viewName=customerID modelName=customerID type =int required=true / property-mapping viewName=productID modelName=productID type =int required=true / property-mapping viewName=price modelName=price type=float required=true regExpr= / /data-mapping /data-mappings An additional property-mapping attribute is 'defaultValue'. 2. If validation is specified in web.xml then each data value is validated according to the data-type to be converted to and any regular expressions given (haven't implemented the regExp bit yet). Failure naturally takes the user back to the 'input' page (in the action-mappings). 3. All that happens then is that the ActionForm given in Action.process() is a subclass called org.apache.struts.data.DataForm which is a 'glorified Hashtable' of the values defined in the data-mapping for that form. 4. There will also be populate and extract methods on the DataForm class to automatically 'move' values to and from the DataForm and a Bean (or EJB) given. Using this extension to Struts will greatly speed the development of our next project, but it would be good if something like it could be incorporated into the original code-stream. Anyway, if people are interested in it then let me know and once I've put some more work into it I'll be happy to pass it on. Regards, Sean -- Dr Sean Radford, MBBS, MSc Senior Consultant Agora Professional Services Ltd [EMAIL PROTECTED] http://www.agora.co.uk
Adding RowTag to Struts
Hello all, I am writing in hopes of getting the RowTag added to Struts. I think this is a Tag - allowing for alternate row colors inside an iterate tag. I have added this class to the latest version of struts, and added its description to struts-logic.tld, but everytime I checkout a new version of Struts, it overwrites my changes. Therefore, this e-mail is sent in hopes of getting this tag added to Struts soon. This e-mail is based on a posting found at: http://www.mail-archive.com/struts-user@jakarta.apache.org/msg07855.html Thanks, Matt tag namerow/name tagclasscom.amarda.framework.taglib.RowTag/tagclass bodycontentJSP/bodycontent info Format a HTML Table Row (i.e. TR/TR) /info attributenameoddColor/name/attribute attributenameevenColor/name/attribute attributenameoddStyleClass/name/attribute attributenameevenStyleClass/name/attribute attributenamealign/name/attribute attributenamevalign/name/attribute attributenameonblur/namertexprvaluetrue/rtexprvalue/attribute attributenameonchange/namertexprvaluetrue/rtexprvalue/attribute attributenameonclick/namertexprvaluetrue/rtexprvalue/attribute attributenameondblclick/namertexprvaluetrue/rtexprvalue/attribute attributenameonfocus/namertexprvaluetrue/rtexprvalue/attribute attributenameonkeydown/namertexprvaluetrue/rtexprvalue/attribute attributenameonkeypress/namertexprvaluetrue/rtexprvalue/attribute attributenameonkeyup/namertexprvaluetrue/rtexprvalue/attribute attributenameonmousedown/namertexprvaluetrue/rtexprvalue/attribute attributenameonmousemove/namertexprvaluetrue/rtexprvalue/attribute attributenameonmouseout/namertexprvaluetrue/rtexprvalue/attribute attributenameonmouseover/namertexprvaluetrue/rtexprvalue/attribute attributenameonmouseup/namertexprvaluetrue/rtexprvalue/attribute attributenamestyle/namertexprvaluetrue/rtexprvalue/attribute attributenamestyleClass/namertexprvaluetrue/rtexprvalue/attribute /tag RowTag.java
WhoWeAre
I'm going to slip a WhoWeAre page to the documentation later today, listing the contributors and Committers. This would go over the WhoWeAre text that is in the root folder of the distribution. Craig and I have longish bios there. If any other Committers would like to send me theirs, I'll include them in the update. Source Code Contributors Arun M. Thomas Chris Audley Craig R. McClanahan David Geary Don Clasen Florent Carpentier Jeff Hutchison Jimmy Larsson Luis Arias Marius Barduta Mike Schachter Niall Pemberton Ralph Schaer Rob Leland Sean Kelly Ted Husted User Guide Contributors --- Chris Assenza Craig R. McClanahan David Geary dIon Gillard Eric Wu John Rousseau Larry McCay Martin Cooper Matthias Kerkhoff Mike Schachter Robert Hayden Stanley Santiago Ted Husted Wong Kok Kai Active Committers - Craig R. McClanahan ([EMAIL PROTECTED]) David Geary ([EMAIL PROTECTED]) Michael Schachter ([EMAIL PROTECTED]) Ted Husted ([EMAIL PROTECTED]) Rob Leland ([EMAIL PROTECTED]) Vincent Massol ([EMAIL PROTECTED]) Cedric Dumoulin ([EMAIL PROTECTED]) Martin Cooper ([EMAIL PROTECTED]) Emeritus Committers --- + Luis Arias + Pierre Delilse More About Us ... -- Craig and Ted hyperbole / -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/
RE: WhoWeAre
Ted, If you could add this for me I'd appreciate it: --- Mike Schachter I'm currently a student of computer science at Drexel University in Philadelphia, PA. I've been working at HP Middleware, formerly Bluestone Software for 3 years programming in Java and recently J2EE technologies. I'm a full time worker from September until April and a student and part time worker from April until August. In my spare time I've been known to run monkey-knife fights in a shady south philly warehouse. Err... I mean... nothing. -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 14, 2001 8:33 AM To: [EMAIL PROTECTED] Subject: WhoWeAre I'm going to slip a WhoWeAre page to the documentation later today, listing the contributors and Committers. This would go over the WhoWeAre text that is in the root folder of the distribution. Craig and I have longish bios there. If any other Committers would like to send me theirs, I'll include them in the update. Source Code Contributors Arun M. Thomas Chris Audley Craig R. McClanahan David Geary Don Clasen Florent Carpentier Jeff Hutchison Jimmy Larsson Luis Arias Marius Barduta Mike Schachter Niall Pemberton Ralph Schaer Rob Leland Sean Kelly Ted Husted User Guide Contributors --- Chris Assenza Craig R. McClanahan David Geary dIon Gillard Eric Wu John Rousseau Larry McCay Martin Cooper Matthias Kerkhoff Mike Schachter Robert Hayden Stanley Santiago Ted Husted Wong Kok Kai Active Committers - Craig R. McClanahan ([EMAIL PROTECTED]) David Geary ([EMAIL PROTECTED]) Michael Schachter ([EMAIL PROTECTED]) Ted Husted ([EMAIL PROTECTED]) Rob Leland ([EMAIL PROTECTED]) Vincent Massol ([EMAIL PROTECTED]) Cedric Dumoulin ([EMAIL PROTECTED]) Martin Cooper ([EMAIL PROTECTED]) Emeritus Committers --- + Luis Arias + Pierre Delilse More About Us ... -- Craig and Ted hyperbole / -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/
Re: WhoWeAre
Mike, I'm from Lower merion and I went to Penn. My cousin is an engineer at Drexel. - Original Message - From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 14, 2001 11:27 AM Subject: RE: WhoWeAre Ted, If you could add this for me I'd appreciate it: --- Mike Schachter I'm currently a student of computer science at Drexel University in Philadelphia, PA. I've been working at HP Middleware, formerly Bluestone Software for 3 years programming in Java and recently J2EE technologies. I'm a full time worker from September until April and a student and part time worker from April until August. In my spare time I've been known to run monkey-knife fights in a shady south philly warehouse. Err... I mean... nothing. -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 14, 2001 8:33 AM To: [EMAIL PROTECTED] Subject: WhoWeAre I'm going to slip a WhoWeAre page to the documentation later today, listing the contributors and Committers. This would go over the WhoWeAre text that is in the root folder of the distribution. Craig and I have longish bios there. If any other Committers would like to send me theirs, I'll include them in the update. Source Code Contributors Arun M. Thomas Chris Audley Craig R. McClanahan David Geary Don Clasen Florent Carpentier Jeff Hutchison Jimmy Larsson Luis Arias Marius Barduta Mike Schachter Niall Pemberton Ralph Schaer Rob Leland Sean Kelly Ted Husted User Guide Contributors --- Chris Assenza Craig R. McClanahan David Geary dIon Gillard Eric Wu John Rousseau Larry McCay Martin Cooper Matthias Kerkhoff Mike Schachter Robert Hayden Stanley Santiago Ted Husted Wong Kok Kai Active Committers - Craig R. McClanahan ([EMAIL PROTECTED]) David Geary ([EMAIL PROTECTED]) Michael Schachter ([EMAIL PROTECTED]) Ted Husted ([EMAIL PROTECTED]) Rob Leland ([EMAIL PROTECTED]) Vincent Massol ([EMAIL PROTECTED]) Cedric Dumoulin ([EMAIL PROTECTED]) Martin Cooper ([EMAIL PROTECTED]) Emeritus Committers --- + Luis Arias + Pierre Delilse More About Us ... -- Craig and Ted hyperbole / -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/
DTD Location
Currently, the XML indicates that the DTD is located over the web using a public qualifier. Does it really check over the web for the DTD to validate against? I would rather not do this for performance reasons. If it does, can I change the reference to a SYSTEM ref instead. What is the recommended approach for a production implementation? Thanks in Advance, Ken Hoying Practice Partner TITAN Technology Partners Pager: 216-275-7284
cvs commit: jakarta-struts build.xml
craigmcc01/06/14 09:35:59 Modified:.Tag: STRUTS_1_0_BRANCH build.xml Log: Update version number in build.xml so the various documentation generated from it will say 1.0 instead of 1.0-b1. Revision ChangesPath No revision No revision 1.52.2.1 +1 -1 jakarta-struts/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-struts/build.xml,v retrieving revision 1.52 retrieving revision 1.52.2.1 diff -u -r1.52 -r1.52.2.1 --- build.xml 2001/05/06 12:07:31 1.52 +++ build.xml 2001/06/14 16:35:54 1.52.2.1 @@ -82,7 +82,7 @@ property name=project.name value=jakarta-struts/ !-- Version of the project -- -property name=project.version value=1.0-b1/ +property name=project.version value=1.0/ !-- == Derived Properties --
Re: WhoWeAre
Sorry to hear that. Guess your not too happy with the 76ers right about now... ;- - Original Message - From: Jonathan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 14, 2001 12:21 PM Subject: Re: WhoWeAre Mike, I'm from Lower merion and I went to Penn. My cousin is an engineer at Drexel. - Original Message - From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 14, 2001 11:27 AM Subject: RE: WhoWeAre Ted, If you could add this for me I'd appreciate it: --- Mike Schachter I'm currently a student of computer science at Drexel University in Philadelphia, PA. I've been working at HP Middleware, formerly Bluestone Software for 3 years programming in Java and recently J2EE technologies. I'm a full time worker from September until April and a student and part time worker from April until August. In my spare time I've been known to run monkey-knife fights in a shady south philly warehouse. Err... I mean... nothing. -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 14, 2001 8:33 AM To: [EMAIL PROTECTED] Subject: WhoWeAre I'm going to slip a WhoWeAre page to the documentation later today, listing the contributors and Committers. This would go over the WhoWeAre text that is in the root folder of the distribution. Craig and I have longish bios there. If any other Committers would like to send me theirs, I'll include them in the update. Source Code Contributors Arun M. Thomas Chris Audley Craig R. McClanahan David Geary Don Clasen Florent Carpentier Jeff Hutchison Jimmy Larsson Luis Arias Marius Barduta Mike Schachter Niall Pemberton Ralph Schaer Rob Leland Sean Kelly Ted Husted User Guide Contributors --- Chris Assenza Craig R. McClanahan David Geary dIon Gillard Eric Wu John Rousseau Larry McCay Martin Cooper Matthias Kerkhoff Mike Schachter Robert Hayden Stanley Santiago Ted Husted Wong Kok Kai Active Committers - Craig R. McClanahan ([EMAIL PROTECTED]) David Geary ([EMAIL PROTECTED]) Michael Schachter ([EMAIL PROTECTED]) Ted Husted ([EMAIL PROTECTED]) Rob Leland ([EMAIL PROTECTED]) Vincent Massol ([EMAIL PROTECTED]) Cedric Dumoulin ([EMAIL PROTECTED]) Martin Cooper ([EMAIL PROTECTED]) Emeritus Committers --- + Luis Arias + Pierre Delilse More About Us ... -- Craig and Ted hyperbole / -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/
Re: DTD Location
Thanks you! I figured they would not have implemented it with a lookup over the web. Thanks, Ken Hoying Practice Partner TITAN Technology Partners Pager: 216-275-7284 Craig R. McClanahan To: [EMAIL PROTECTED] craigmcc@apacc: che.org Subject: Re: DTD Location 06/14/2001 12:48 PM Please respond to struts-dev On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote: Currently, the XML indicates that the DTD is located over the web using a public qualifier. Does it really check over the web for the DTD to validate against? I would rather not do this for performance reasons. If it does, can I change the reference to a SYSTEM ref instead. What is the recommended approach for a production implementation? If you look inside the controller servlet, you'll see that it registers a local copy of the struts-config DTD, as well as the web.xml DTDs, with the XML parser (the digester.register() calls). This tells the parser to use the local copy when a request for the specified public identifier is made. Among other things, that means you can run Struts-based apps even when you are not connected to the internet. As long as your struts-config.xml file has the correct public identifier, Struts does *not* go across the net to perform the validation. Thanks in Advance, Ken Hoying Practice Partner TITAN Technology Partners Pager: 216-275-7284 Craig McClanahan
Re: DTD Location
Another way is to implement your own EntityResolver to maintain a local cache. This is explained in the javadoc for the EntryResolver class (somewhere in javax.xml...) -will [EMAIL PROTECTED] writes: Currently, the XML indicates that the DTD is located over the web using a public qualifier. Does it really check over the web for the DTD to validate against? I would rather not do this for performance reasons. If it does, can I change the reference to a SYSTEM ref instead. What is the recommended approach for a production implementation? Thanks in Advance, Ken Hoying Practice Partner TITAN Technology Partners Pager: 216-275-7284
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. :
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
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: DTD Location
On Thu, 14 Jun 2001, William Shulman wrote: Another way is to implement your own EntityResolver to maintain a local cache. This is explained in the javadoc for the EntryResolver class (somewhere in javax.xml...) It's already there, and already used! See the sources for ActionServlet, in particular the calls to digester.register(). The code in the digester then implements an appropriate EntityHandler. Craig -will [EMAIL PROTECTED] writes: Currently, the XML indicates that the DTD is located over the web using a public qualifier. Does it really check over the web for the DTD to validate against? I would rather not do this for performance reasons. If it does, can I change the reference to a SYSTEM ref instead. What is the recommended approach for a production implementation? Thanks in Advance, Ken Hoying Practice Partner TITAN Technology Partners Pager: 216-275-7284
Re: Calling ActionForm.reset() from html:form when creating a bean
Hi, maybe one should add a ActionForm.init() method (with same parameters as reset()) which is then called in FormTag.doStartTag() whenever it creates a new ActionForm instance? This would not break existing code and would help those who would like do some initialization (I'm one of them, too). What do you think? - Original Message - From: Cook, Levi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 13, 2001 11:53 PM Subject: RE: Calling ActionForm.reset() from html:form when creating a bean I agree that breaking the 1.0 code-base would be a bad thing. However, I believe the 1.0 release should be as correct as possible. Following my own definition of correct, and recognizing that Struts openly claims Beta status I believe this feature should be included. Following Roland, I have trouble imagining a scenario where this should cause problems. Basically, you know that the framework invokes your forms reset method, therefore you need to make sure it represents the state you intend. If someone has another scenario, please chime in. Regards, Levi Cook -Original Message- From: Roland Huss [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 13, 2001 4:27 PM To: [EMAIL PROTECTED] Subject: Re: Calling ActionForm.reset() from html:form when creating a bean Craig R. McClanahan [EMAIL PROTECTED] writes: Bugzilla #2108 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2108 asks a very reasonable question -- whey isn't the reset() method called when a new form bean is created in the html:form tag? After all, the controller servlet will always call reset() on the form bean (whether or not it is newly created) before calling populate() to copy the request parameters. Recently I would indeed have needed this feature to initialize the possible choices for multi-choice select box using html:options attribute property to return a collection for the multiselect box. But it since it wasn't called upon form creation, the list has never been initialized. My solution was to use the collection attribute which takes a collection put into the request by the previous action, which after all was the cleaner solution anyway (no logic within forms !). This seems like a perfectly reasonable thing to add for 1.1. My question is, what do folks think about making this change for 1.0 as well? I'm more than a little concerned that it would break existing code, but the consistency argument might make doing this worthwile anyway. (Of course, we would highlight this change in the Release Notes.). What do you think? Should we do this in 1.0 as well? At the moment, I can't imagine any situation where it would harm to call reset() upond form creation (or why it would be reasonable to rely that it is *not* called). So, I would vote to include it in 1.0 as well cu... -- ...roland huss consol.de
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]
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: Proposal: Support nested tags where only attributes can be used
On Thu, 14 Jun 2001, Dean Wampler wrote: h1Title is bean:message bean:key template:get name=pageName/.title /bean:key /bean:message /h1 There's a pretty significant problem with this -- the JSP page compiler will consider .title to be template text, and will just copy it to the output page. That's not to say we couldn't make the bean:message tag smarter about where it gets its key from, but we have to obey the rules of the language we're writing for. The typical way to deal with dynamic stuff at runtime is to use a runtime expression. 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. You might want to have a look at the JSP Specification as well. Some of the things you discuss are just plain not legal in JSP. 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] Craig
cvs commit: jakarta-struts/doc/userGuide volunteers.xml
husted 01/06/14 18:45:28 Added: doc/userGuide Tag: STRUTS_1_0_BRANCH volunteers.xml Log: Add WhoWeAre page, update Resources, and related indices. Revision ChangesPath No revision No revision 1.1.2.1 +271 -0jakarta-struts/doc/userGuide/Attic/volunteers.xml
cvs commit: jakarta-struts/doc project.xml
husted 01/06/14 18:46:05 Modified:doc Tag: STRUTS_1_0_BRANCH project.xml Log: Update project index. Revision ChangesPath No revision No revision 1.1.2.3 +2 -1 jakarta-struts/doc/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-struts/doc/project.xml,v retrieving revision 1.1.2.2 retrieving revision 1.1.2.3 diff -u -r1.1.2.2 -r1.1.2.3 --- project.xml 2001/06/14 00:22:29 1.1.2.2 +++ project.xml 2001/06/15 01:46:05 1.1.2.3 @@ -8,13 +8,14 @@ menu name=Documentation item name=Home href=index.html/ item name=Installation href=installation.html/ - item name=User Guide (1.0) href=userGuide/index.html/ +item name=User Guide (1.0) href=userGuide/index.html/ item name=Javadochref=api/index.html/ item name=Release Notes (1.0b1) href=release-notes-1.0-b1.html/ item name=Release Notes (1.0b2) href=release-notes-1.0-b2.html/ item name=Release Notes (1.0b3) href=release-notes-1.0-b3.html/ item name=Release Notes (1.0)href=release-notes-1.0.html/ item name=Resources href=userGuide/resources.html/ +item name=Who We Are href=userGuide/volunteers.html/ item name=TODO List (1.1)href=todo-1.1.html/ /menu
