DO NOT REPLY [Bug 15604] New: - Struts framework should use getInstance Method for instantiating FormBeans
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=15604. 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=15604 Struts framework should use getInstance Method for instantiating FormBeans Summary: Struts framework should use getInstance Method for instantiating FormBeans Product: Struts Version: 1.0.2 Final Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Digester AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Suggession Instead of instantiating formbeans using newInstance of reflection API, if struts gives the developer with a getInstance method. Developer will have the liberty to either create a new instance or return a Proxy Instance. Disadvantage with the existing framework : 1. FormBean may grow large depending upon the number of fields used. 2. When form data is required for backend purpose, Data from formbean has to be copied to another 'application specific Object', this is just to decouple struts from my application. Advantages when struts invokes a getInstance() method on the FormBean 1. I need have any variables in my form bean 2. I need not write getter/setter methods in my form bean 3. I need not transfer data from formbean (frontend) to my application specific data object (backend) 4. Adding new variable is as simple as adding setter/getter methods in the respective interface and start using the same name as variables in my JSP. How : 1. I will return a Proxy Instance for the Form Bean 2. Write only my application specific data object to hold the data, which will have only a HashMap. 3. When struts framework invokes any setter method, the data will be set to my data object's HashMap as MethodName vs. Value 4. Now theres no transfer of data required, all the data required for my form bean is available in the data object, which is specific to my application (not depending on struts). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Taglib URI's
If you subscribe to the digest, you can still post to the User list. You can also post to the User list through the BaseBeans newsgroup. 12/15/2002 11:14:23 AM, Matt Raible [EMAIL PROTECTED] wrote: This is probably a question for the struts-user list, but I'm scared to subscribe to that inbox filler-upper ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/doc using.xml index.xml acquiring.xml
husted 2002/12/22 08:44:25 Modified:doc using.xml index.xml acquiring.xml Log: Add links to prerequesites. Add mention of subscribing to Digest and posting to User list. Remove book newsflash before it becomes dated. Revision ChangesPath 1.5 +5 -1 jakarta-struts/doc/using.xml Index: using.xml === RCS file: /home/cvs/jakarta-struts/doc/using.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- using.xml 1 Dec 2002 16:03:21 - 1.4 +++ using.xml 22 Dec 2002 16:44:25 - 1.5 @@ -138,7 +138,9 @@ strongSTRUTS-USER Digest/strong - Subscribe to this list to receive a daily digest of the Struts USER list.br/ [a href=mailto:[EMAIL PROTECTED];Subscribe/a]br/ - [a href=mailto:[EMAIL PROTECTED];Unsubscribe/a] + [a href=mailto:[EMAIL PROTECTED];Unsubscribe/a]br/ + If you subscribe to the Digest, you can also post to the User list. + (Just don't quote the entire Digest mailing in a reply!) /li li @@ -146,6 +148,8 @@ so that you can participate bwithout/b subscribing to the regular mailing list.br/ [a href=http://www.proj.com/subscribe.jsp;Struts Newsgroup/a]br/ + This is another way to post to the User list without subscribing to the + regular list. br/ Our thanks to BaseBeans Engineering for providing this much-needed service! /li /ul 1.42 +0 -5 jakarta-struts/doc/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-struts/doc/index.xml,v retrieving revision 1.41 retrieving revision 1.42 diff -u -r1.41 -r1.42 --- index.xml 12 Dec 2002 02:11:10 - 1.41 +++ index.xml 22 Dec 2002 16:44:25 - 1.42 @@ -145,11 +145,6 @@ Links to excerpts are provided when available. /p - p - bNews flash:/b - a href=resources/books.htmlStruts books hit #1 band/b #2 on Amazon best seller list./a - /p - /section section 1.4 +64 -38jakarta-struts/doc/acquiring.xml Index: acquiring.xml === RCS file: /home/cvs/jakarta-struts/doc/acquiring.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- acquiring.xml 1 Dec 2002 16:03:22 - 1.3 +++ acquiring.xml 22 Dec 2002 16:44:25 - 1.4 @@ -26,28 +26,29 @@ /p ul - + li - a href=http://jakarta.apache.org/builds/jakarta-struts/release/v1.0.2; - bStruts 1.0.2 Binary Distribution/b/a - /li - -li - a href=http://jakarta.apache.org/builds/jakarta-struts/release/v1.0.2/lib; - bStruts 1.0.2 Library Distribution/b/a - /li - -li - a href=http://jakarta.apache.org/builds/jakarta-struts/release/v1.0.2/src; - bStruts 1.0.2 Source Code Distribution/b/a - /li - +a href=http://jakarta.apache.org/builds/jakarta-struts/release/v1.0.2; +bStruts 1.0.2 Binary Distribution/b/a +/li + +li +a href=http://jakarta.apache.org/builds/jakarta-struts/release/v1.0.2/lib; +bStruts 1.0.2 Library Distribution/b/a +/li + +li +a href=http://jakarta.apache.org/builds/jakarta-struts/release/v1.0.2/src; +bStruts 1.0.2 Source Code Distribution/b/a +/li + /ul p Check the a href=http://jakarta.apache.org/struts/doc-1.0.2/release-notes-1.0.2.html; -Release Notes/a for a summary of the changes since the Struts 1.0.1 release. +Release Notes/a for a summary of the changes since the Struts 1.0.1 +release. /p p @@ -56,7 +57,7 @@ a href=http://jakarta.apache.org/struts/doc-1.0.2/installation.html#Prerequisites; prerequisite/a software applications. Then, follow the appropriate instructions to - a href=http://jakarta.apache.org/struts/doc-1.0.2/installation.html#Installing; +a href=http://jakarta.apache.org/struts/doc-1.0.2/installation.html#Installing; install and use a Struts binary distribution/a in your web application or for a href=http://jakarta.apache.org/struts/doc-1.0.2/installation.html#Building; @@ -85,7 +86,8 @@ p Check the a href=http://jakarta.apache.org/struts/userGuide/release-notes-1.1-b2.html; -Release Notes/a for a summary of the changes since the Struts 1.0.2 release. +Release Notes/a for a summary of the changes since the Struts 1.0.2 +release. /p p @@ -95,7 +97,8 @@ prerequisite/a software applications. Then, follow the appropriate
cvs commit: jakarta-struts/doc/news index.xml
husted 2002/12/22 08:44:56 Modified:doc/news index.xml Log: Move book news to news page, with other dated items. Revision ChangesPath 1.11 +32 -3 jakarta-struts/doc/news/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-struts/doc/news/index.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- index.xml 29 Nov 2002 19:53:24 - 1.10 +++ index.xml 22 Dec 2002 16:44:56 - 1.11 @@ -112,6 +112,35 @@ hr size=1 noshade=/ -- +h3a name=20021213/a12 December 2002 - Struts book #1 and #2/h3 +p +a href=http://www.amazon.com/exec/obidos/ISBN=0672324725/hitchhikeguidetoA/; +bStruts Kick Start/b/a +by James Turner and Kevin Bedell is now available from Amazon for immediate delivery: +/p +p +Buy one, buy two. They make great stocking stuffers. Use them as door +stops. Learn to use the enclosed CD as a lethal thrown weapon. Fun for +the whole family. +/p +hr size=1 noshade=/ + + +h3a name=20021212/a12 December 2002 - Struts book #1 and #2/h3 +p +a href=http://www.amazon.com/exec/obidos/tg/browse/-/3610/1/002-5420337-0432053?rank=%2Bsalesrankamp;submit.x=4amp;submit.y=13;img border=0 src=../images/books/topsellers.jpg width=284 height=220 align=right valign=top//a +Struts books top the #1 strongand/strong #2 slots on Amazon's a href=http://www.amazon.com/exec/obidos/tg/browse/-/3610/1/002-5420337-0432053?rank=%2Bsalesrankamp;submit.x=4amp;submit.y=13;Java Programming bestseller list/a! +/p +hr size=1 noshade=/ + + +h3a name=20021203/a3 December 2002 - Struts book rated 11 out of 10/h3 +p +small(3 December 2002)/smallbr /strongStruts in Action/strong rated 11 out of 10 by a href=http://books.slashdot.org/article.pl?sid=02/11/25/1731249amp;mode=threadamp;tid=156;Slashdot/a. +/p +hr size=1 noshade=/ + + h3a name=20021127/a27 Nov 2002 - Expresso 5.0.2 Released/h3 p Expresso 5.0.2 can be downloaded freely from: @@ -140,13 +169,13 @@ /p ul li - a href=http://www.amazon.com/exec/obidos/ISBN=0596003285/hitchhikeguidetoA/;Amazon/a +a href=http://www.amazon.com/exec/obidos/ISBN=0596003285/hitchhikeguidetoA/;Amazon/a /li li - a href=http://www.bookpool.com/.x/6kq93k1kim/sm/0596003285;Bookpool/a +a href=http://www.bookpool.com/.x/6kq93k1kim/sm/0596003285;Bookpool/a /li li - a href=http://www.oreilly.com/catalog/jakarta;O’Reilly/a +a href=http://www.oreilly.com/catalog/jakarta;O’Reilly/a /li /ul hr size=1 noshade=/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/resources books.xml
husted 2002/12/22 08:45:10 Modified:doc/resources books.xml Log: Move book news to news page, with other dated items. Revision ChangesPath 1.16 +0 -13 jakarta-struts/doc/resources/books.xml Index: books.xml === RCS file: /home/cvs/jakarta-struts/doc/resources/books.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- books.xml 12 Dec 2002 02:38:54 - 1.15 +++ books.xml 22 Dec 2002 16:45:10 - 1.16 @@ -9,19 +9,6 @@ body chapter name=Struts Resources href=http://husted.com/struts/resources; -section name=Struts Book News - -p -small(12 December 2002)/smallbr /a href=http://www.amazon.com/exec/obidos/tg/browse/-/3610/1/002-5420337-0432053?rank=%2Bsalesrankamp;submit.x=4amp;submit.y=13;img border=0 src=../images/books/topsellers.jpg width=284 height=220 align=right valign=top//a -Struts books top the #1 strongand/strong #2 slots on Amazon's a href=http://www.amazon.com/exec/obidos/tg/browse/-/3610/1/002-5420337-0432053?rank=%2Bsalesrankamp;submit.x=4amp;submit.y=13;Java Programming bestseller list/a! -/p - -p -small(3 December 2002)/smallbr /strongStruts in Action/strong rated 11 out of 10 by a href=http://books.slashdot.org/article.pl?sid=02/11/25/1731249amp;mode=threadamp;tid=156;Slashdot/a. -/p - -/section - section name=Books about Struts table -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/faqs helping.xml
husted 2002/12/22 08:56:00 Modified:doc/faqs helping.xml Log: Clarify how to submit patches. Revision ChangesPath 1.3 +19 -5 jakarta-struts/doc/faqs/helping.xml Index: helping.xml === RCS file: /home/cvs/jakarta-struts/doc/faqs/helping.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- helping.xml 6 Nov 2002 22:48:46 - 1.2 +++ helping.xml 22 Dec 2002 16:56:00 - 1.3 @@ -39,11 +39,14 @@ /p p -Our challenge to any team using Struts is to donate the time of one team member one -afternoon a week (or more if you can spare the resources). Have your team member browse Bugzilla for any -issues without a a href=#codepatch/a or a href=#testsunit test/a, and add the patch or test. -If the patch is written on company time, and you want to give your company an author's credit, that's -fine with us. +Our challenge to any team using Struts is to donate the time of one team member +one afternoon a week (or more if you can spare the resources). +Have your team member browse +a href=http://jakarta.apache.org/site/bugs.html;Bugzilla/a for any issues +without a a href=#codepatch/a or a href=#testsunit test/a, +and add the patch or test. +If the patch is written on company time, +and you want to give your company an author's credit, that's fine with us. /p p @@ -57,6 +60,17 @@ how-tos that we can make part of the a href=documentationdocumentation/a. The mailing list is very active and trundling through the archives is no picnic. We can always use people who can reduce the best threads to coherent articles that we can put in the User Guide. +/p + +p +Some Apache products like you to submit your patch to the mailing list. +We would prefer that you create a +a href=http://jakarta.apache.org/site/bugs.html;Bugzilla/a +Bugzilla report and then attach the patch to the report. +To do this, you must first create the report, +and then modify the report to add your patch. +We realize this is a bit clumsy, but it keeps us from losing things, +and helps to ensure that your patch will be attended. /p p -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/faqs helping.xml
husted 2002/12/22 09:09:01 Modified:doc/faqs helping.xml Log: Conform line lengths - no content changes. Revision ChangesPath 1.4 +228 -157 jakarta-struts/doc/faqs/helping.xml Index: helping.xml === RCS file: /home/cvs/jakarta-struts/doc/faqs/helping.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- helping.xml 22 Dec 2002 16:56:00 - 1.3 +++ helping.xml 22 Dec 2002 17:09:01 - 1.4 @@ -13,18 +13,34 @@ section href=contents name=Index p -font face=Arial, Helvetica, sans serifYou can't always get what you want / but if you try real hard / you might just find / -that you get what you need. /fontbr/ +font face=Arial, Helvetica, sans serif +You can't always get what you want / +but if you try real hard / +you might just find / +that you get what you need. +/fontbr/ [Rolling Stones] /p ul -lia href=#corpWhat can my company do to help support Struts?/a/li -lia href=#bugsHow can I report bugs or make feature requests?/a/li -lia href=#contributeHow can I contribute to Struts source code?/a/li -lia href=#documentationHow can I contribute to the documentation?/a/li -lia href=#releaseSo when is the next release coming out?/a/li -lia href=#release_helpHow can I help the next release along?/a/li +lia href=#corp +What can my company do to help support Struts? +/a/li +lia href=#bugs +How can I report bugs or make feature requests? +/a/li +lia href=#contribute +How can I contribute to Struts source code? +/a/li +lia href=#documentation +How can I contribute to the documentation? +/a/li +lia href=#release +So when is the next release coming out? +/a/li +lia href=#release_help +How can I help the next release along? +/a/li /ul /section @@ -32,10 +48,13 @@ section href=corp name=What can my company do to help support Struts? p -Struts is an all volunteer product. Our customers are the volunteers who donate -their time and energy to supporting the product. If you want to support Struts, and -become one of our customers, then you need to -a href=http://jakarta.apache.org/site/getinvolved.html;get involved/a and become a volunteer. +Struts is an all volunteer product. +Our customers are the volunteers who donate their time and energy to +supporting the product. +If you want to support Struts, and become one of our customers, +then you need to +a href=http://jakarta.apache.org/site/getinvolved.html;get involved/a +and become a volunteer. /p p @@ -50,16 +69,20 @@ /p p -If Struts doesn't do what iyou/i want, it's up to byou/b to step up and propose the patch. -If Struts doesn't ship as often as you would like, it's up to you to step up with the tests and fixes that -get a release out the door. +If Struts doesn't do what iyou/i want, it's up to byou/b to step up +and propose the patch. +If Struts doesn't ship as often as you would like, it's up to you to step up +with the tests and fixes that get a release out the door. /p p -If Struts does do what you want, help others become involved by turning your war stories into FAQs and -how-tos that we can make part of the a href=documentationdocumentation/a. The mailing list is very -active and trundling through the archives is no picnic. We can always use people who can reduce the best -threads to coherent articles that we can put in the User Guide. +If Struts does do what you want, help others become involved by turning your +war stories into FAQs and how-tos that we can make part of the +a href=documentationdocumentation/a. +The mailing list is very active and trundling through the archives is no +picnic. +We can always use people who can reduce the best threads to coherent articles +that we can put in the User Guide. /p p @@ -74,8 +97,8 @@ /p p -We don't sell Struts for money, but anyone who wants to be our customer can pay us back by donating -the time and energy that money represents. +We don't sell Struts for money, but anyone who wants to be our customer +can pay us back by donating the time and energy that money represents. /p /section @@ -84,128 +107,148 @@ p You can research and report outstanding fixes and feature requests using -a href=http://jakarta.apache.org/site/bugs.html;Jakarta Bugzilla/a. If you -are unsure if this is an actual problem, feel free to bring it up the list -first. But to sure that an issue is resolved, read -a href=http://www.chiark.greenend.org.uk/~sgtatham/bugs.html;How to Report -Bugs Effectively/a and report it to +a href=http://jakarta.apache.org/site/bugs.html;Jakarta Bugzilla/a. +If you are unsure
Re: Reloading ActionServlet configuration
See also http://jakarta.apache.org/struts/faqs/newbie.html#reload 12/16/2002 2:38:52 PM, Ron Monson [EMAIL PROTECTED] wrote: Since the reload() method has been removed from ActionServlet effective 1.1b2 I am trying to find an alternative way of 'reloading' the configuration on-the-fly. Simply calling init() again or destroy () and then init() does not seem to work. Also, the destroy() method doesn't seem to be completed yet. Does anyone have any suggestions?? Thanks, Ron _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Module path-mapping limitation
It's not so much a bug as a design flaw. The current approach to prepending the module is under-designed and just jams it in. Though, I keep meaning to check whether the template feature we added later ($M$P) could be used to get around this somehow. -Ted. 12/17/2002 12:22:39 PM, Matt Raible [EMAIL PROTECTED] wrote: Is there a bug that I can reference (in my writing) for the limitation that modules can only be used with extension-mapping (*.do) rather than path-mapping (/do/*)? If this has been fixed, please let me know. Matt -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: modifying the mapping input path during validation
12/17/2002 2:31:52 PM, Erik Hatcher jakarta- [EMAIL PROTECTED] wrote: Or the evil action chaining keeping things available for you in a later action. IMHO, Action chaining is linking three or more Actions together. (e.g., three points determine a chaine :0) Simply forwarding from one Action to another, so the second can select the page and complete the response, is an ordinary and expected use of the framework. The evil part is when people start using the Action objects as an API and want to pass (new) parameters from one Action to another, either by changing the properties on the ActionForm or by creating a new query string on the fly. The danger here is that the Action *classes* become coupled and start looking like a mess of GOTOs. While there could be exceptions, this usually indicates that there is not sufficient separation between the Action classes and the business tier. Why? Because if I have a decent business facade, I shouldn't have to kludge-around with setting new properties on an ActionForm or as a request parameter. I should be able to code directly to the business facade. Now, none of this speaks to the current thread, I just wanted to chime in about the Action Chaining. IMHO, Erik doesn't practice Action Chaining, as the term was originally used, he simply links from one Action to another, which is an expected practice. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: modifying the mapping input path during validation
My first suggestion would be try not to think in terms of request parameters and try to think in terms of ActionForm properties. Generally, all the request parameters should be represented as ActionForm properties. Struts will then take care of automatically populating the properties. My second suggestion would be to try and put gory details like id= 104 behind ActionForward. Instead creating an ActionForward by appending the parameter, you can call the forward by name. I don't know what 104 does, but you could have the equivalent of forward name=home104 path:/home.do?id=104/ Where home104 is a descriptive name rather than an arbitrary identifier. My third suggestion would be to use an ActionMapping for the input property rather than a presentation page. Ideally, all pages should be behind ActionMapping handlers. If you need to apply some post-validation logic or seed any properties (!parameters) on the ActionForm, you can do that here. -Ted. 12/17/2002 1:10:28 PM, Brian Moseley [EMAIL PROTECTED] wrote: any comments on the problem i've outlined below? i realize that it's not clean to give a form bean any amount of control logic (which is what i want to do by allowing it to manipulate the input path). i'd prefer to avoid this if possible. one thought is that RequestProcessor.process could offer a post validation hook that would allow the input path to be specified by an application component. but which component? neither actions or forms make sense here. another thought: form definitions in struts-config optionally specify sprintf-like format strings which are used by the mapping/forward/whatever to dynamically generate paths. once again, the requirement i have to live with is that my form's input page requires a particular request parameter to be set. it's just a form for modifying the attributes of a model object, and the request parameter is simply the object's unique id. this is clearly a common design pattern; how do other people solve the problem of providing a needed request parameter to an action form's input after a failed validation? Brian Moseley wrote: i sent the below message to struts-user a couple of days ago. since that time i tried to address the problem by creating a subclass of RequestProcessor and overriding the process method. didn't work. i figured i could make an unfrozen clone of the mapping to pass into processValidate, which would allow my form to set the input path inside its validate method. unfortunately, there was no clean way to do this; i didn't want to cut and paste processValidate into my subclass, and there is no hook within process to allow a subclass to step in and create the mapping clone. i wound up having the form set a session attribute which the action then gets and removes. a grotesque solution to be sure, but the only apparent alternative was worse. so the question i put to you folks is: how must struts change to allow me to modify the mapping's input path inside the form's validate method? or is there some existing solution that i'm completely missing? thanks! Brian Moseley wrote: i'm using struts 1.1b2 to perform a simple validation on an action form. it works great, except: when validation fails, i need to specify an additional request parameter for the input path, as the input page requires that parameter to exist. unfortunately, i get a configuration frozen error when i try to modify the input path in the action form's validate method. i've considered but rejected using a session attribute instead of a request parameter for this particular piece of data. other than that, is there a solution that i'm missing? thanks! -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/userGuide building_view.xml
husted 2002/12/22 11:41:19 Modified:doc/userGuide building_view.xml Log: Conform use of pre/code tags; no content changes. Revision ChangesPath 1.20 +124 -125 jakarta-struts/doc/userGuide/building_view.xml Index: building_view.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/building_view.xml,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- building_view.xml 17 Dec 2002 07:21:05 - 1.19 +++ building_view.xml 22 Dec 2002 19:41:19 - 1.20 @@ -130,18 +130,17 @@ for the application. In the case described above, it would be codecom.mycompany.mypackage.MyApplication/code. /p -pre -lt;servlet - lt;servlet-nameactionlt;/servlet-name - lt;servlet-classorg.apache.struts.action.ActionServletlt;/servlet-class - lt;init-param -lt;param-nameapplicationlt;/param-name -lt;param-valuecom.mycompany.mypackage.MyResourceslt;/param-value - lt;/init-param - lt;.../ -lt;/servlet -/pre - +precode![CDATA[ +servlet + servlet-nameaction/servlet-name + servlet-classorg.apache.struts.action.ActionServlet/servlet-class + init-param +param-nameapplication/param-name +param-valuecom.mycompany.mypackage.MyResources/param-value + /init-param + !-- ... -- +/servlet +]]/code/pre p The important thing is for the resource bundle to be found on the class path for your application. Another approach is to store @@ -155,12 +154,12 @@ that copies the contents of a codesrc/conf/code directory to the codeclasses/code directory: /p - pre -lt;!-- Copy any configuration files -- -lt;copy todir=classes -lt;fileset dir=src/conf/ -lt;/copy - /pre +precode![CDATA[ +!-- Copy any configuration files -- +copy todir=classes +fileset dir=src/conf/ +/copy +]]/code/pre /section section name=3.3 Forms and FormBean Interactions href=form_beans @@ -190,12 +189,10 @@ standard HTML and JSP pages. For example, an input element for a codeusername/code field might look like this (in JSP): /p - -pre -lt;input type=text name=username - value=lt;%= loginBean.getUsername() %gt;/gt; -/pre - +precode![CDATA[ +input type=text name=username + value=%= loginBean.getUsername() / +]]/code/pre p which is difficult to type correctly, confuses HTML developers who are not knowledgeable about programming concepts, and can cause problems with @@ -203,11 +200,9 @@ building forms, based on the Custom Tag Library facility of JSP 1.1. The case above would be rendered like this using Struts: /p - -pre -lt;html:text property=username/gt; -/pre - +precode![CDATA[ +html:text property=username/; +]]/code/pre p with no need to explicitly refer to the JavaBean from which the initial value is retrieved. That is handled automatically by the JSP tag, using @@ -232,57 +227,61 @@ example application included with Struts) named codelogon.jsp/code: /p hr/ -pre -lt;%@ page language=java %gt; -lt;%@ taglib uri=/WEB-INF/struts-html.tld -prefix=html %gt; -lt;%@ taglib uri=/WEB-INF/struts-bean.tld -prefix=bean %gt; -lt;html:htmlgt; -lt;headgt; -lt;titlegt; - lt;bean:message key=logon.title/gt; -lt;/titlegt; -lt;/headgt; -lt;body bgcolor=whitegt; -lt;html:errors/gt; -lt;html:form action=/logon focus=usernamegt; -lt;table border=0 width=100%gt; - lt;trgt; -lt;th align=rightgt; - lt;bean:message key=prompt.username/gt; -lt;/thgt; -lt;td align=leftgt; - lt;html:text property=username - size=16/gt; -lt;/tdgt; - lt;/trgt; - lt;trgt; -lt;th align=rightgt; - lt;bean:message key=prompt.password/gt; -lt;/thgt; -lt;td align=leftgt; - lt;html:password property=password - size=16/gt; -lt;/tdgt; - lt;/trgt; - lt;trgt; -lt;td align=rightgt; - lt;html:submitgt; -lt;bean:message key=button.submit/gt; - lt;/html:submitgt; -lt;/tdgt; -lt;td align=rightgt; - lt;html:resetgt; -lt;bean:message key=button.reset/gt; - lt;/html:resetgt; -lt;/tdgt; - lt;/trgt; -lt;/tablegt; -lt;/html:formgt; -lt;/bodygt; -lt;/html:htmlgt; -/pre +precode![CDATA[ +%@ page language=java % +%@ taglib + uri=/WEB-INF/struts-html.tld + prefix=html % +%@ + taglib uri=/WEB-INF/struts-bean.tld + prefix=bean % +html:html +head +title + bean:message key=logon.title/ +/title +/head +body bgcolor=white +html:errors/ +html:form
Re: Avoid code reformating !
It's true that since the Struts product does not define its own code standards, we default to the Sun conventions, as given by the Jakarta guidelines. Personally, I augment these with the Java Elements of Style, which, in practice, act like a superset of the Sun conventions. As a practical matter, we do have to balance Observe the style of the original with our responsibility to maintain a code base for the benefit of others (rather than ourselves). Technically, we should veto submissions that do not follow the Sun coding conventions, but we've been lax about that in the past. I would simply suggest that we continue to follow the practice of submitting code changes and style changes separately. If someoone has a stylistic scratch to itch, they should scratch it. (But it would be polite to find a bug itch to scratch first =:) Incidentally, the tab thing is because we email the deltas and sending tabs by email is problematic =:( -Ted. 12/16/2002 6:44:07 PM, David Graham [EMAIL PROTECTED] wrote: A couple of things: 1. Tabs were addressed as an issue but the jakarta guidelines state that tabs are not to be used in the first place. This drives me crazy but I follow it nonetheless. 2. I agree with closing one line blocks but this isn't in any standard. I've seen a lot of Struts code that will follow an unclosed one line block with more code which makes it very confusing. This is fair game for changing in my book. 3. I disagree that we should stop formatting code. We have a standard that we should be following. If we need to change that standard then we can debate that. Dave From: Erik Hatcher [EMAIL PROTECTED] Reply-To: Struts Developers List struts- [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Avoid code reformating ! Date: Mon, 16 Dec 2002 18:25:55 -0500 As for seeing a class structure, this is what IDE's like Eclipse and IDEA make a moot point. I think if code doesn't follow the Jakarta (or project-specific) conventions then its fair game for reformatting. This is communal code and no one person owns it, this is why conventions exist and we must adhere to them for the sake of the community. Please. But, while we are talking about coding conventions, at least please adopt closing if/for/while/etc blocks with curly brackets for one-line blocks. The Struts codebase is littered with non-curly-bracketed one- line blocks and that in and of itself drives me nuts when I'm trying to follow the code. :)) Erik Cedric Dumoulin wrote: I said that I don't want to debate on this. I know the reformated code doesn't follow the recomanded Jakarta rules code standard. But another rule is to respect any other well formated standard ;-). For me, the reformated code is really unreadable: I can't detect the classes and methods structures at a glance, and so it requires me some times to try to figure it out. I thing it is a waste of time ... Cedric -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/doc/userGuide installation.xml
If you like, you could just move the Services SQL stuff to Scaffold in the Commons Sandbox for the time being. I'll be visiting the Scaffold.sql package and the Commons SQL package this week (as part of paying gig), and should probably look at this as well. If it's not directly Struts related, we should remove it to the Commons. -Ted. 12/18/2002 1:51:54 AM, Rob Leland [EMAIL PROTECTED] wrote: Martin Cooper wrote: I guess we could remove the commons-services.jar from the builds, +1 Do you have any thoughts on how best to salvage the code you're interested in? Need to give it some thought. I just discovered it when I was removing unused imports and cleaning up JavaDoc, for contrib projects last week. Maybe create a contrib/utils directory ? Unofficial but gererally usefull classes. I'll have to make a list, if they aren't too many classes then see if they fit somewhere in commons, or maybe punt them over to SourceForge, before deleting them outright. SPEAKING of which After 1.1 The o.a.s.u.IteratorAdapter should probably be deprecated and punted over to commons-collections ?, or if there is already an equalivent in commons use that internally instead. -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Avoid code reformating !
It's true that since the Struts product does not define its own code standards, we default to the Sun conventions, as given by the Jakarta guidelines. Personally, I augment these with the Java Elements of Style, which, in practice, act like a superset of the Sun conventions. As a practical matter, we do have to balance Observe the style of the original with our responsibility to maintain a code base for the benefit of others (rather than ourselves). Technically, we should veto submissions that do not follow the Sun coding conventions, but we've been lax about that in the past. I would simply suggest that we continue to follow the practice of submitting code changes and style changes separately. If someoone has a stylistic scratch to itch, they should scratch it. (But it would be polite to find a bug itch to scratch first =:) Incidentally, the tab thing is because we email the deltas and sending tabs by email is problematic =:( -Ted. 12/16/2002 6:44:07 PM, David Graham [EMAIL PROTECTED] wrote: A couple of things: 1. Tabs were addressed as an issue but the jakarta guidelines state that tabs are not to be used in the first place. This drives me crazy but I follow it nonetheless. 2. I agree with closing one line blocks but this isn't in any standard. I've seen a lot of Struts code that will follow an unclosed one line block with more code which makes it very confusing. This is fair game for changing in my book. 3. I disagree that we should stop formatting code. We have a standard that we should be following. If we need to change that standard then we can debate that. Dave From: Erik Hatcher [EMAIL PROTECTED] Reply-To: Struts Developers List struts- [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Avoid code reformating ! Date: Mon, 16 Dec 2002 18:25:55 -0500 As for seeing a class structure, this is what IDE's like Eclipse and IDEA make a moot point. I think if code doesn't follow the Jakarta (or project-specific) conventions then its fair game for reformatting. This is communal code and no one person owns it, this is why conventions exist and we must adhere to them for the sake of the community. Please. But, while we are talking about coding conventions, at least please adopt closing if/for/while/etc blocks with curly brackets for one-line blocks. The Struts codebase is littered with non-curly-bracketed one- line blocks and that in and of itself drives me nuts when I'm trying to follow the code. :)) Erik Cedric Dumoulin wrote: I said that I don't want to debate on this. I know the reformated code doesn't follow the recomanded Jakarta rules code standard. But another rule is to respect any other well formated standard ;-). For me, the reformated code is really unreadable: I can't detect the classes and methods structures at a glance, and so it requires me some times to try to figure it out. I thing it is a waste of time ... Cedric -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15604] - Struts framework should use getInstance Method for instantiating FormBeans
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=15604. 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=15604 Struts framework should use getInstance Method for instantiating FormBeans --- Additional Comments From [EMAIL PROTECTED] 2002-12-22 22:09 --- You can achieve some of this by using DynaBeans. Struts does not approve of using the same object as the form bean and model bean which is why it's set up this way. You can use PropertyUtils to easily move the data between objects. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/userGuide building_view.xml
dgraham 2002/12/22 15:10:29 Modified:doc/userGuide building_view.xml Log: Added text for section 3.4.3 Tiles. Revision ChangesPath 1.21 +55 -2 jakarta-struts/doc/userGuide/building_view.xml Index: building_view.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/building_view.xml,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- building_view.xml 22 Dec 2002 19:41:19 - 1.20 +++ building_view.xml 22 Dec 2002 23:10:28 - 1.21 @@ -685,10 +685,63 @@ /section section name=3.4.3 Page Composition With Tiles href=Tiles - p -[:TODO:] +Tiles is a powerful templating library that allows you to construct views by combining +various tiles. Here's a quick setup guide: /p + ol + liCreate a /layout/layout.jsp file that contains your app's common look and feel: + pre + lt;html + lt;body + lt;tiles:insert attribute=body/ + lt;/body + lt;/html + /pre + /li + li + Create your /index.jsp homepage file: + pre + lt;h1This is my homepage!lt;/h1 + /pre + /li + liCreate a /WEB-INF/tiles-defs.xml file that looks like this:br/ + pre + lt;tiles-definitions + lt;definition name=layout path=/layout/layout.jsp + lt;put name=body value=/ + lt;/definition + lt;definition name=homepage extends=layout + lt;put name=body value=/index.jsp/ + lt;/definition + lt;tiles-definitions + /pre + /li + li + Setup the TilesPlugin in the struts-config.xml file: + pre + lt;plug-in className=org.apache.struts.tiles.TilesPlugin + lt;set-property property=definitions-config value=/WEB-INF/tiles-defs.xml/ + lt;/plug-in + /pre + /li + li + Setup an action mapping in struts-config.xml to point to your homepage tile: + pre + lt;action + path=/index + type=org.apache.struts.actions.ForwardAction + parameter=homepage/ + /pre + /li +/ol +p + The TilesPlugin configures a special RequestProcessor that determines if the requested view is a + tile and processes it accordingly. Note that we made the homepage tile extend our root layout + tile and changed the body attribute. Tiles inserts the file named in the body attribute into the main + layout. +/p +pSee the the tiles-documentation webapp for in-depth examples./p /section section name=3.4.4 Image Rendering Components href=image_rendering -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Fwd: typo on Struts page
FYI - Not acked. Pier Begin forwarded message: From: Kris Resellmo [EMAIL PROTECTED] Date: Mon Dec 23, 2002 1:58:11 AM Europe/London To: [EMAIL PROTECTED] Subject: typo on Struts page http://jakarta.apache.org/struts/userGuide/release-notes-1.1- b2.html#New One line in this section reads: Nested - An very cool taglib extension It should probably be: Nested - A very cool tagbli extension Kris Resellmo Northwestern University, Evanston, IL. USA [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Avoid code reformating !
Personally I find the sun style with things just anyhow all over the place to be quite messy completely unreadable. When I read source for a struts class I usually have to spend 10 minutes moving the braces around so I can figure out what is going on... Still one mans meat is anothers poison, and if theres one thing in development that is bound to spark off 'holy wars' its coding style ;-) -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Monday, December 23, 2002 03:53 To: Struts Developers List Subject: Re: Avoid code reformating ! It's true that since the Struts product does not define its own code standards, we default to the Sun conventions, as given by the Jakarta guidelines. Personally, I augment these with the Java Elements of Style, which, in practice, act like a superset of the Sun conventions. As a practical matter, we do have to balance Observe the style of the original with our responsibility to maintain a code base for the benefit of others (rather than ourselves). Technically, we should veto submissions that do not follow the Sun coding conventions, but we've been lax about that in the past. I would simply suggest that we continue to follow the practice of submitting code changes and style changes separately. If someoone has a stylistic scratch to itch, they should scratch it. (But it would be polite to find a bug itch to scratch first =:) Incidentally, the tab thing is because we email the deltas and sending tabs by email is problematic =:( -Ted. 12/16/2002 6:44:07 PM, David Graham [EMAIL PROTECTED] wrote: A couple of things: 1. Tabs were addressed as an issue but the jakarta guidelines state that tabs are not to be used in the first place. This drives me crazy but I follow it nonetheless. 2. I agree with closing one line blocks but this isn't in any standard. I've seen a lot of Struts code that will follow an unclosed one line block with more code which makes it very confusing. This is fair game for changing in my book. 3. I disagree that we should stop formatting code. We have a standard that we should be following. If we need to change that standard then we can debate that. Dave From: Erik Hatcher [EMAIL PROTECTED] Reply-To: Struts Developers List struts- [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Avoid code reformating ! Date: Mon, 16 Dec 2002 18:25:55 -0500 As for seeing a class structure, this is what IDE's like Eclipse and IDEA make a moot point. I think if code doesn't follow the Jakarta (or project-specific) conventions then its fair game for reformatting. This is communal code and no one person owns it, this is why conventions exist and we must adhere to them for the sake of the community. Please. But, while we are talking about coding conventions, at least please adopt closing if/for/while/etc blocks with curly brackets for one-line blocks. The Struts codebase is littered with non-curly-bracketed one- line blocks and that in and of itself drives me nuts when I'm trying to follow the code. :)) Erik Cedric Dumoulin wrote: I said that I don't want to debate on this. I know the reformated code doesn't follow the recomanded Jakarta rules code standard. But another rule is to respect any other well formated standard ;-). For me, the reformated code is really unreadable: I can't detect the classes and methods structures at a glance, and so it requires me some times to try to figure it out. I thing it is a waste of time ... Cedric -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [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]
DO NOT REPLY [Bug 2017] - Text entered in forms using multi-part/formdata cannot be utf8
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=2017. 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=2017 Text entered in forms using multi-part/formdata cannot be utf8 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-12-23 03:36 --- I finally got around to verifying that this bug is fixed when using the new CommonsMultipartRequestHandler implementation. One complication is that some browsers do not send the character encoding with the request, even when it is different from the default ISO-8859-1, making it impossible to correctly interpret the submitted bytes. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Avoid code reformating !
Somewhat off-topic at this point:
Actually, Sun's style is pretty specific for most things that matter.
The problem is probably that Sun code doesn't always follow Sun's
style.
re: Brace reformatting for readability, I prefer reading code with
braces lined up, but since over 70% of the C code I've read and almost
as much of the Java code I've read use the Kernigan and Richie style
bracing I've gotten used to reading it and writing it over the years.
I'm not sure if that's the kind of reformatting to which you're
refering, but it's good to learn both ways in any case.
For the format impaired:
KR style:
if( you can read this ){
you'll go far
}
Versus:
if( you can read this )
{
you'd also like pascal
}
And actually, Sun-style would be:
if (you can read this){
you'll like tomcat code
}
(except replace the 8 spaces with a tab, leave everything else spaces;
the part that jakarta leaves out... thankfully.)
I've found it enlightening to be able to read and write all of these
styles fluently... especially when contributing to jakarta
projects. :) Ironically, none of them are my native tongue but I'm
an odd-ball.
-Paul Speed
Andrew Hill wrote:
Personally I find the sun style with things just anyhow all over the place
to be quite messy completely unreadable.
When I read source for a struts class I usually have to spend 10 minutes
moving the braces around so I can figure out what is going on...
Still one mans meat is anothers poison, and if theres one thing in
development that is bound to spark off 'holy wars' its coding style ;-)
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 23, 2002 03:53
To: Struts Developers List
Subject: Re: Avoid code reformating !
It's true that since the Struts product does not define its own
code standards, we default to the Sun conventions, as given by the
Jakarta guidelines.
Personally, I augment these with the Java Elements of Style,
which, in practice, act like a superset of the Sun conventions.
As a practical matter, we do have to balance Observe the style of
the original with our responsibility to maintain a code base for
the benefit of others (rather than ourselves).
Technically, we should veto submissions that do not follow the Sun
coding conventions, but we've been lax about that in the past.
I would simply suggest that we continue to follow the practice of
submitting code changes and style changes separately. If someoone
has a stylistic scratch to itch, they should scratch it. (But it
would be polite to find a bug itch to scratch first =:)
Incidentally, the tab thing is because we email the deltas and
sending tabs by email is problematic =:(
-Ted.
12/16/2002 6:44:07 PM, David Graham [EMAIL PROTECTED]
wrote:
A couple of things:
1. Tabs were addressed as an issue but the jakarta guidelines
state that
tabs are not to be used in the first place. This drives me crazy
but I
follow it nonetheless.
2. I agree with closing one line blocks but this isn't in any
standard.
I've seen a lot of Struts code that will follow an unclosed one
line block
with more code which makes it very confusing. This is fair game
for
changing in my book.
3. I disagree that we should stop formatting code. We have a
standard that
we should be following. If we need to change that standard then
we can
debate that.
Dave
From: Erik Hatcher [EMAIL PROTECTED]
Reply-To: Struts Developers List struts-
[EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: Avoid code reformating !
Date: Mon, 16 Dec 2002 18:25:55 -0500
As for seeing a class structure, this is what IDE's like Eclipse
and IDEA
make a moot point. I think if code doesn't follow the Jakarta
(or
project-specific) conventions then its fair game for
reformatting. This is
communal code and no one person owns it, this is why conventions
exist and
we must adhere to them for the sake of the community. Please.
But, while we are talking about coding conventions, at least
please adopt
closing if/for/while/etc blocks with curly brackets for one-line
blocks.
The Struts codebase is littered with non-curly-bracketed one-
line blocks
and that in and of itself drives me nuts when I'm trying to
follow the
code. :))
Erik
Cedric Dumoulin wrote:
I said that I don't want to debate on this. I know the
reformated code
doesn't follow the recomanded Jakarta rules code standard. But
another
rule is to respect any other well formated standard ;-).
For me, the reformated code is really unreadable: I can't
detect the
classes and methods structures at a glance, and so it requires
me some
times to try to figure it out. I thing it is a waste of time
...
Cedric
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
