RE: Making Struts Build Easier (Re: coming out for JSF + Struts , was: Struts JSR?)
One more comment about the difficult of contribution to open source projects in general. I have used a great deal of open source code and modified it quite a bit, but have never been successful in making contributions, although I have made more than one attempt. The problem I have is that I don't use all the same tools as the typical open source project, i.e. Visual SourceSafe instead of CVS. Of course if you step into a project the size of struts without having experience if the background tools, sh.. quickly hits the fan and you have no hope of making a useful contribution. I have no good answers for this, just passing on my $.02... Edgar -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, March 22, 2004 9:47 AM To: Struts Developers List Subject: Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?) Personally, I find the Struts build files to be complex and confusing. I've come to associate Maven with easy builds because building commons components (including the distro, website, tests, etc) is a snap compared to Struts. I agree that storing jars in cvs isn't a good idea which is why using Maven is so nice; it downloads the correct jars automatically. Anything we can do to make the build more straightforward, whether it's with Ant or Maven, is a good thing :-). David --- Joe Germuska [EMAIL PROTECTED] wrote: For me, the main discouraging thing about contributing to the development of Struts has been the build process. In the past, you had to download all of jakarta-commons and spend a day or two figuring out how to get that to build. Recently, I tried to build Struts and was successful using the Maven stuff. Personally, I don't mind using Maven, but I don't know that it should be *required* to build a project from scratch. I'd love to be able to cvs co Struts, navigate to jakarta-struts and type ant jar. I realize this is no easy thing to accomplish with a build file - but it has been the most discouraging factor for me. ;-) The only way we could accomplish something like that with a build file would be by including JARs in CVS, and if you ask me, there are enough reasons why that's a bad idea that I prefer the way it is, even though I'd very much like to see people feel more comfortable getting in and working on Struts source code. When you say I don't know that [Maven] should be *required*... is your point that Ant is a widely accepted Java tool, while Maven has yet to cut a 1.0 release? That's fair -- just want to make sure I understand you. The build.xml file generated by 'maven ant' uses the ant 'get' task and the Maven iBiblio repository to download dependencies; we could perhaps look at copying some of that into our ant script to reduce build.properties to being more about configuration stuff and less about dependency stuff. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.638 / Virus Database: 409 - Release Date: 3/21/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.638 / Virus Database: 409 - Release Date: 3/21/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Browser-specific attrs for html tags (was: [Bug 26795])
I have done a fair amount of tag work and this one doesn't make any sense to me. I am a big fan of the struts tags and I extend them all the time. First of all if you are doing an href in a button, why are you using a struts tag. If he wants to do a custom tag of aButton href... have at it. Additionally, using the struts tag is no different than using an html button (with the exception that the value of onclick can't be another tag). Lastly, with the new jsp spec, I always forget which one, custom tags can be declared as pass through, i.e. unknown attributes are simply passed through to the html so why add complexity to the current tags. Edgar -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 6:01 PM To: Struts Developers List Subject: RE: Browser-specific attrs for html tags (was: [Bug 26795]) --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.580 / Virus Database: 367 - Release Date: 2/6/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Compartmentalization of Modules (was Re: [18111] et al)
If the use of modules is truly to split struts-config.xml files, then isn't it simpler to just use comma delimited configuration files in web.xml? Edgar -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 20, 2004 3:02 PM To: Struts Developers List Subject: Compartmentalization of Modules (was Re: [18111] et al) If you had the time, it might help me if you could elaborate on the reasons one might want to block direct links between modules. Ultimately, I think we need to understand the use cases for modules. So far in our usage, it has been predominantly a way of segmenting a large app into manageably sized struts-config files. I could be wrong, but I suspect that there are many other Struts users who use it this way, regardless of the original design intention. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.558 / Virus Database: 350 - Release Date: 1/2/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: why are form beans required for html:form?
The data not going to a form bean seem to be a 'very' limited use, especially with the ease of DynaActionForms. There already exists a fair amount of technology to handle this sort of situation. Additionally, the idea of struts was to put a framework around this. To compliciate the tags for this situation seems...like it should be thought about further. Edgar -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 11:21 PM To: Struts Developers List Subject: RE: why are form beans required for html:form? On Thu, 15 Jan 2004 12:14:46 -0600, Joe Germuska wrote: Now, at the risk of sidetracking this discussion, I have to bring up my other Struts pet-peeve -- the over complexity of pre-filling forms from data rather than from the request. I'm wondering if bringing up some questions about how the form bean is looked up gives me a chance to scratch that itch too...? I don't think this is what you meant, but I've wondered whether the tags should check the request for a corresponding attribute if the formbean property returns null. This could answer the case where the target property is not a String (or boolean). If the bean property is null, and the same property exists in the request, then we have the case where validation failed and the attribute could not be stored in the target property. If the tag then displayed the request attribute, we could have typed input field on ActionForms. (Essentially, we are using the request as our String buffer.) Though for consistency, a better idea (if this first idea is even good) would be to check the request for a corresponding attribute first, and then look to the formbean property if the attribute is absent. Again, this would let us use the request for an input buffer, and reserve the ActionForm for validated input. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.558 / Virus Database: 350 - Release Date: 1/2/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.558 / Virus Database: 350 - Release Date: 1/2/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
There is another benefit to the way that struts does things. Since the actionform has such a heavy structure, standard actions can be written based on the structure. If a common set of business actions can be defined then actions can be reused across large sections of a web enabled application, i.e. wizards, reports, lookup-save-saveas-delete, etc. Then business object can implement these simple interfaces, dropped into an actionform and off you go. Edgar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, December 20, 2003 5:47 PM To: Struts Developers List Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum) I think that sounds like a good compromise. In my view, there are really two types of forms - small ones with one or two parameters, and full blown complex input forms. In the former case, I think combining the form and action is a good idea; the latter, probably not so much. In WebWork2/XWork, as I understand it, your action can declare JavaBean setters which will be automatically populated by the framework. This makes it very easy to unit test and frees the actions from any servlet dependencies. This approach works very well for actions that require a couple of parameters, while I might favor the Struts approach for larger forms. To experiment adding these and other WebWork2/XWork features in Struts we started the Struts Action Invocation Framework (SAIF) on struts.sf.net The Struts sf site is a great forum for trying out ideas before sticking them in Struts core. To implement the integrated form/action, we scope actions (request/session/application), then use action interceptors to set action JavaBean setters from the request parameters. While SAIF certainly isn't ready to be put in Struts core, the action interceptor idea is showing promise and provides a good alternative to the more heavy-handed ActionForm for simplier situations. Don Hack might be too strong a word. I'd call it a reasonable alternative extension of the framework :) If we want to look at the WebWork/Maverick approach of using a single input/command handler, where Struts has separate input and command handlers, why not add the said standard ExecuteFormAction and ExecuteForm subclass to the build and see how the community reacts? After 1.2.0 rolls, we could add them to the nightly build and mark them experimental. When 1.2.1 comes around, we could then decide whether to leave them or pull them. If we decide to pull them, we can always start that toolkit on SourceForge, and let it live there. Or, if the community likes the idiom, then in 2.x we could provide the ExecuteForm behavior without providing an Action to do it. -Ted. Don Brown wrote: Yes, it is possible to do a lot of things with Struts currently, but for the most part, they are all hacks. With Struts 2.0, we have a chance to look at Struts best practices, other web frameworks, and current technologies to design Struts to be the best and easiest framework for web applications, and perhaps beyond. My point is we should look at whether to encourage through Struts design and documentation the combination of forms and actions, or keep the current design. In this process, I think it is important to look at other frameworks and the results of the design choices they made, particularly our close cousin WebWork2/XWork. Don On Sat, 20 Dec 2003, Ted Husted wrote: Don Brown wrote: Hmm...I'm not familiar with that discussion, but I don't see why general form functionality couldn't be defined in an interface, but the ActionForm left how it is. Of course we also have a chance to do what Craig said he'd change about Struts (at JavaOne 2003 JSF BOF) and combine forms and actions. WebWork2/XWork seems to have done well with that approach. It's been mentioned on the list that you can combine Actions and ActionForms already. All that's needed is an ActionForm subclass with an execute property, and a standard Action that simply returns that result instead: ExecuteForm ef = (ExecuteForm) form; return ef.execute(request,response,mapping,form); -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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
I use dynamic fields all the time. The fields visible to the user are based on a usage profile, for example if a user is entering orders and his profile is for export orders he sees a booking field, if his profile is for domestic orders he doesn't. This is a view issue, the booking should be in the model and passed through struts NMW (I don't believe the small DB optimization is worth the trouble). The issue to struts and the model is the conditional validation. There is one other place where this is a problem and that is with the struts method of handling checkboxes since all of them on a specific form have to be reset and if they are conditional in the view it poses a problem although they pose a problem on a multipage form in any case. Edgar -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Thursday, December 18, 2003 6:29 PM To: Struts Developers List Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum) The dynamic field use case comes up all the time, but I have trouble getting my head around it. What would be helpful would be a example application that people could play with. You can take thought experiments only so far :) My first question would be how would anything (never mind Struts) address this use case? The other half of the problem would be creating a dynamic query to go with the dynamic form, so that only the fields you are editing are updated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
And you're really going to have to break both of my arms and/or kick me out of Struts development if you want ActionForm *ever* changed to an interface again -- in *any* future Struts release. I think it's an absolutely horrible idea, for reasons that have been documented way too many times to count. Craig McClanahan - Also, again totally agreeing with Ted, make everything interface based, a few more hears here ;^) Joe Germuska The interface discussion has come up previously and there was some emotion tied to it. Edgar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: getDataSource deprecate
Sorry to disagree with you Vic. There are so many good reasons to keep struts data source for other than large J2EE projects. First it works, is simple, loading your apps is simpler, just drop in the war, no messing with the container. Second for testing it is simpler, you can just run moc tests. For small apps, struts data source is really useful. If you do completely drop struts data source, please throw in a plug for Poolman on sourceforge on the faq explaining why you dropped it (http://sourceforge.net/projects/poolman/). Thanks Edgar -Original Message- From: Vic Cekvenich [mailto:[EMAIL PROTECTED] Sent: Saturday, December 06, 2003 7:18 AM To: [EMAIL PROTECTED] Subject: getDataSource deprecate Consider if it be good idea to sometime in the future mark getDataSource as deprecated. .V - 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: Should Struts ship with all of the commons jar files needed t o get Struts datasources working?
I disagree about the web app containing the DB Pool as configuration of multiple DB Pools in a container containing many different apps is a royal pain, not to mention a potential source of downtime for unrelated users. Please don't remove this feature. Leave it depreated as long as you like. Thanks Edgar -Original Message- From: Vic Cekvenich [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 4:43 PM To: [EMAIL PROTECTED] Subject: Re: Should Struts ship with all of the commons jar files needed to get Struts datasources working? Hello Rick, They are deprecated; targeted for removal; and for a good reason, since it's a bad practice to have a data source served by the web app., a container provides a data source. In esence, maybe legacy jar should not be included any more, it has been a while since 1.1 released. There is to much talk about data connection's as it is on user. (I wish more be taged as deprected :logic/bean, since in the future... they will be and there was a comment on dev list that no one is keen to patch, so just give users a signal ) .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Extending ActionMapping
This looks like an XML validation error. I assume you didn't modify the stuts-config.dtd, therefore your enhanced struts-config would not pass a strict xml evaluation. Is it possible that Jrun doesn't require xml validation of configuration files? I know that Resin doesn't validate xml configuration files other than for open/close tags. Edgar -Original Message- From: Raudenbush, Pamela [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2003 5:16 PM To: '[EMAIL PROTECTED]' Subject: Extending ActionMapping I successfully implemented a class that extends ActionMapping (MyActionMapping). I have only one new member - validState with a setter and getter. I was able to successfully add this new attribute to my struts-config: ?xml version=1.0 encoding=ISO-8859-1 ? !DOCTYPE struts-config PUBLIC -//Apache Software Foundation//DTD Struts Configuration 1.0//EN http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd; action path=/award forward=/Award.jsp scope=request validState=F /action I set a default in my web-inf: init-param param-namevalidState/param-name param-valueN/param-value /init-param I defined my ActionMapping in my web-inf: init-param param-namemapping/param-name param-valueorg.util.MyActionMapping/param-value /init-param Also, init-param param-namevalidating/param-name param-valuetrue/param-value /init-param As I said, it works fine -- on MY development environment. I use Jrun3.1 app server and struts 1.0. My co-worker pulls the exact code, config files (web-inf and struts-config), etc from CVS (I even started from scratch and pulled the same code), but he gets the following message: Attribute validState must be declared for element type action. We ran it against tomcat and got the same message. We see no differences in our webapp configuration. Any ideas on why we are getting this message? - 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: Multi Action servlet !
Why wouldn't changing the servlet mapping from *.do -- action servlet to *.[actiontype] -- [associated action servlet] work? As long as you are consistent would struts care? Edgar -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2003 7:10 AM To: Struts Developers List Subject: Re: Multi Action servlet ! People have done it, but it's a delicate thing to try. The recommended approach is to use Struts 1.1 modules. To customize the front controller logic for each module, you can plug in alternate Request Processors if needed. This gives you all the benefits of having multiple servlets, without the extra overhead. (There is *no* performance benefit in having multiple servlets that do the same thing.) A better place to ask questions like this would be the Struts USER list. This is where you'd ask if we were going to support multiple servlets in the future. (Answer to that one: not any time soon.) -Ted. Karikalan Kumaresan wrote: Hi, Does anyone know, is it possible to have 2 action servlet configured in struts for different project in a same JVM/in same webserver. Cheers, Kari... -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: 14 November 2003 07:15 To: Struts Developers List Subject: RE: Parsing Error in struts Most likely you haven't closed a JSP tag correctly. Try commenting out sections of your JSP to narrow down where the error is. But you should be asking on the struts-user list not here. Steve -Original Message- From: Abhijeet Mahalkar [mailto:[EMAIL PROTECTED] Sent: November 13, 2003 9:21 PM To: Struts Developers List Subject: Parsing Error in struts I am getting following error is there anybody who can guide me for he same [11/14/03 10:38:12:954 GMT+05:30] 11d6d752 WebGroup E SRVE0026E: [Servlet Error]-[End of content reached while more parsing required: tag nesting error?]: org.apache.jasper.compiler.ParseException: End of content reached while more parsing required: tag nesting error? at org.apache.jasper.compiler.JspReader.popFile(JspReader.java:293) at org.apache.jasper.compiler.JspReader.hasMoreInput(JspReader.ja va(Compiled Code)) at org.apache.jasper.compiler.Parser.parse(Parser.java(Compiled Code)) at org.apache.jasper.compiler.Parser.parse(Parser.java(Inlined Compiled Code)) at org.apache.jasper.compiler.Parser$Tag.accept(Parser.java(Compi led Code)) at org.apache.jasper.compiler.Parser.parse(Parser.java(Compiled Code)) at org.apache.jasper.compiler.Parser.parse(Parser.java(Inlined Compiled Code)) at org.apache.jasper.compiler.Parser$Tag.accept(Parser.java(Compi led Code)) at org.apache.jasper.compiler.Parser.parse(Parser.java(Compiled Code)) at org.apache.jasper.compiler.Parser.parse(Parser.java(Inlined Compiled Code)) at org.apache.jasper.compiler.Parser$Tag.accept(Parser.java(Compi led Code)) at org.apache.jasper.compiler.Parser.parse(Parser.java(Compiled Code)) at org.apache.jasper.compiler.Parser.parse(Parser.java:1110) at org.apache.jasper.compiler.Parser.parse(Parser.java:1106) at org.apache.jasper.compiler.ParserController.parse(ParserContro ller.java:309) at org.apache.jasper.compiler.Compiler.compile(Compiler.java(Compiled Code)) at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.loadJSP(JspServ let.java(Compi led Code)) at com.ibm.ws.webcontainer.jsp.servlet.JspServlet$JspServletWrapp er.loadIfNeces sary(JspServlet.java(Compiled Code)) at com.ibm.ws.webcontainer.jsp.servlet.JspServlet$JspServletWrapp er.service(Jsp Servlet.java(Compiled Code)) at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.serviceJspFile( JspServlet.jav a(Compiled Code)) at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.service(JspServ let.java(Compi led Code)) at javax.servlet.http.HttpServlet.service(HttpServlet.java(Compil ed Code)) at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doServic e(StrictServle tInstance.java(Compiled Code)) at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._servic e(StrictLifecy cleServlet.java(Compiled Code)) at com.ibm.ws.webcontainer.servlet.IdleServletState.service(Stric tLifecycleServ let.java(Compiled Code)) at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service (StrictLifecyc leServlet.java(Inlined Compiled Code)) at com.ibm.ws.webcontainer.servlet.ServletInstance.service(Servle tInstance.java (Compiled Code)) at com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dis patch(ValidSer vletReferenceState.java(Compiled Code)) at com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispa tch(ServletIns tanceReference.java(Inlined Compiled Code)) at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleW ebAppDispatch( WebAppRequestDispatcher.java(Compiled Code)) at
RE: Conversion to ToStringBuilder
I agree, the less jars the better. As far as containers shipping with commonly used jar files, these common applications aren't standing still and we test with the specific jars are applications are using, wouldn't this be confusing and possibly waste more time that it saves. Edgar -Original Message- From: Vic Cekvenich [mailto:[EMAIL PROTECTED] Sent: Sunday, November 09, 2003 2:29 PM To: [EMAIL PROTECTED] Subject: Re: Conversion to ToStringBuilder The less jars, the better. I have like 2 dozen. I wish containers shipped with some commons-* jars and xml handling jars, like Tomcat does. Really, servelt 2.5 spec should state something like jars needed by 80% of apps (collections, beans, log4j, xmltypes suggested) should be in the container common lib. No, not the silly j2ee.jar which has things that are used by 15% of people (yes, it's a scientific #, it says this, if I do not need it, no one needs it). I mean even rt.jar is 18 megs, why not containers have some stuff, we already have class loader issues anyway. bP is only 90K, but needs a lot of jars to wake up. I happen to use lang for other things so this one does not help me and it would detriment and active commiter. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Nested-EL
Everyone has preferences but in my opinion JSTL doesn't hold a candle to the nested tags, especially customized nested tags. I do agree however that JSTL for nested tags is not that important. It does help in environments where there is ZERO tolerance for JSP expressions or that are running older versions of the servlet container. Edgar -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 14, 2003 8:24 PM To: Struts Developers List Subject: Re: Nested-EL --- [EMAIL PROTECTED] wrote: Back in September, David Karr was threatening to do Tiles-EL and Nested-EL. I see that the Tiles-EL has been committed, sweet. Nested-EL seems to be missing. David, have you started working on Nested-EL? If so, how far off is it from being complete? If not, do you have any tips, because I am getting started on it tonight. Doesn't the EL replace the need for a nested tag library? Isn't the EL syntax easier than using nested tags? I haven't used Nested but it seems like a Nested-EL is redundant. David Carl - 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: Struts-chain Behavior Discussion
Not that I am an expert, nor is this the Command Chain a major issue for me, but logic in configuration files (xml) is like writing LISP. For some it is a rare beauty, for others it foggy at best. Edgar -Original Message- From: Paul Speed [mailto:[EMAIL PROTECTED] Sent: Monday, October 06, 2003 7:57 PM To: Struts Developers List Subject: Re: Struts-chain Behavior Discussion Jing Zhou wrote: - Original Message - From: Paul Speed [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, October 06, 2003 5:58 PM Subject: Re: Struts-chain Behavior Discussion Jing Zhou wrote: - Original Message - From: Paul Speed [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, October 06, 2003 3:40 AM Subject: Re: Struts-chain Behavior Discussion (1) LookupCommand (2) ExceptionCatcher (3) SelectLocale (4) Process Action (a) SelectAction (b) CreateActionForm (c) PopulateActionForm (d) ValidateActionForm If validations fail in (d), the (e) and (f) are not necessary. Right, but then it can just stop that particular chain. I was under the impression that a chain can be aborted. If validation fails then the Process Action chain could abort and the main chain would continue on to PerformForward. Incorporating Craig's comments about SelectInput on validation failure are left as an exercise for the reader. ;) I see what you mean. But the complexity is roughly the same as or more than the original one in chain-config.xml. What I am looking for is a simpler syntax to do the same thing without explicitly defining possible nested chains. See my previous message, an example is given. It's not so much about complexity as it is readability. In the above example, the main steps are pretty clear: (1) LookupCommand (2) ExceptionCatcher (3) SelectLocale (4) Process Action (5) PerformForward (For clarity, I might even lump the first three into their own chain.) If I care what Process Action is then I can see the detail. Goto's were deemed dangerous because of the behavior that they hide. They obfuscate the flow of the code. It's not really any different here either. command jumpLabel=L1 className=Class1 / command jumpLabel=L2 className=Class2 / command label=L1 className=Class3 / command label=L2 className=Class4 / I had a longer response prepared to your other post, but decided it was too wordy. :) One example where the obfuscation comes in is that I had to look at it for a bit before determining that Class4 was always run. If a few more commands are thrown in, it really gets confusing. -Paul -Paul Jing - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Accept patches to make html taglib more extensible
Perhaps if you changed the name to renderAdditionalTags and renderPreliminaryTags it might be more palatable. A perfect use case is if you want to create a more programmer friendly checkBox implementation. The easy answer is to have a parallel field which is hidden with the text values of 'true' or 'false' with javascript syncronizing the values to guarantee a result returned. Edgar -Original Message- From: Sgarlata Matt [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2003 7:28 AM To: Struts Developers List Subject: Re: [VOTE] Accept patches to make html taglib more extensible FYI I'm about halfway through implementing proposal A. Since David voted against proposal B I am going to drop the issue ;) More comments below... - Original Message - From: Robert Leland [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Sunday, September 28, 2003 10:06 PM Subject: Re: [VOTE] Accept patches to make html taglib more extensible B) Add a new renderExtraAttributes() method that gives people the chance to throw non-standard HTML into their tags that extend from Struts tags. snip from=BaseFieldTag.java results.append(\); results.append(this.prepareEventHandlers()); results.append(this.prepareStyles()); results.append(this.getElementClose()); matts-idea results.append(renderExtraAttributes()); /matt-sidea return results.toString(); /snip Use Case for Part B: Unfortunately I still can't think of a good HTML 4.01 compliant use case for renderExtraAttributes(), but here is a weak try at it. No solid use case will allways get my -1. I don't want to see unnecessary methods added just because they might somehow prove useful. I will vote for adding a method that will be used for a specific purpose. I like the idea of this hook, and I don't personally care if it is valid HTML 4.01 is produced or not, that is YOUR choice! Because if you NEED to do this you're going to do it anyway, just not as easily. I agree that whether or not HTML 4.01 compliant code is rendered by a JSP tag is the choice of the developer of the tag, but even if we get a solid use case it sounds like David will veto it. Also when you say invalid HTML 4.01 do you mean specific to say IE 6.0 or do you mean just adding additional HTML which isn't really invalid? I meant adding things that were browser-specific, like for IE 6.0. Matt - 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]
View Logic which belongs in the Business Tier [was RE: Editable F ields V/S Static Text]
This is in answer to Craig's question a few days back about what kind of business logic was needed in the tag classes. In my application there are quite a few classes of information that are business logic requirements that without enhancing the tags would need view code. 1) The business logic should decide if a field is RW, RO or hidden to a particular user in a particular part of the database. This is way too much logic for any view technology. An example from my application is a Purchase Order. The clerk, can enter the order and the base fields including the customer the material will be shipped to. The manager can only enter the approval field, so the customer is read-only to the manager. The supplier has access to the order, but can't necessarily (depending upon requirements in the supplier configuration) see who the customer is so in this case the customer is a hidden field or omitted from the html entirely. The easy argument to the above is this can all be done in JSTL or scriptlet or to use multiple JSP/ActionForms/Actions one for each role. In my mind, this logic is too complex for scripts and the refactoring overhead of removing it from java is too expensive. 2) Validation: Currently the struts validator is very popular with good reason. However, this is creating a whole class of business logic in separate files which are difficult to refactor, difficult to code complex logic around, etc. There should be an interface for the business logic to implement to supply entry points for field validation. 3) Basic information: Field sizes and types should be obtained from the business tier, and not coded into the view with 'size and maxlength'. Size and maxlength should be rendered, but automatically based on information from the business tier. Edgar -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2003 8:22 PM To: Struts Developers List Subject: Re: Editable Fields V/S Static Text 3) Lastly, there are certain class of business information that the view needs, i.e. readonly, size. The tags should have to ability to easily pass this information from the business tier to the view. Again, the hope of a submission relating to this type of extension being accepted seems iffy, especially since generalizing a specific implementation is a bit of effort. I'd need to see a more detailed description of what you're thinking about to know whether it would fit in, but I assume you're talking about something more than the disabled and readonly attributes that already exist? Edgar Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Accept patches to make html taglib more extensible
+1
If 'renderExtraAttributes' always renders the last attributes of the tag
this looks clean to me. This would allow rendering multiple input or
other tags with the single tag.
Edgar
-Original Message-
From: Sgarlata Matt [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 28, 2003 11:02 AM
To: Struts Developers List
Subject: [VOTE] Accept patches to make html taglib more extensible
I hope it's OK for a non-committer to start a vote. I know
this has been a contentious issue, so I would like to clearly
outline my plan for making the html taglibs more extensible
and I would like a vote before I go to all the trouble of
coding, updating documentation, resolving bugfixes, answering
questions, etc.
DESIRED FUNCTIONALITY
The ability to cleanly extend the Struts tags. The tags are
so good that when an application-specific requirement arises,
it's much more desirable to extend from the Struts tag and
keep tie-ins with ActionForms and such than it is to go off
on your own.
PROPOSED SOLUTION
The solution is two parts. Please vote separately for each
part of the solution.
A) Instead of accessing instance variables directly, use getters.
snip from=BaseFieldTag.java
if (accept != null) {
results.append( accept=\);
//old way
//results.append(accept);
//new way
results.append(getAccept());
results.append(\);
}
/snip
If someone wanted to override the accept attribute so that it
was always equal to foo then they would be able to do so. A
better use case would be overriding the onclick method so
that it does something special like display a calendar popup.
Getters are actually already used in some places (e.g. -
prepareMouseEvents in BaseHandlerTag), so really this is just
doing an audit on the code to ensure getters are used
consistently throughout the taglib.
Use case for Part A:
I built an implementation
of Matt Kruse's JavaScript calendar widget based on the
Struts tags a few weeks before Matt made his own
implementation, so I have some experience doing this. As
some brief background, the widget is a text box and a
corresponding calendar icon. When you click on the calendar
icon a popup appears where you can choose the date. When you
click on the text box (which is what overrides a Struts tag)
you want onfocus to automatically call this.blur() so that
the user can't enter text into the textbox (that's the
calendar popup's job). So in my subclass it would be nice to
override the getOnfocus() method instead of overriding the entire
renderIForgetWhatItIsCalled() method. Of course in this
particular instance
getOnfocus() is already being used instead of onfocus being
accessed directly, but I think this behavior should be
consistent for all attributes.
B) Add a new renderExtraAttributes() method that gives people
the chance to throw non-standard HTML into their tags that
extend from Struts tags.
snip from=BaseFieldTag.java
results.append(\); results.append(this.prepareEventHandlers());
results.append(this.prepareStyles());
results.append(this.getElementClose());
matts-idea
results.append(renderExtraAttributes());
/matt-sidea
return results.toString();
/snip
Use Case for Part B:
Unfortunately I still can't think of a good HTML 4.01
compliant use case for
renderExtraAttributes(), but here is a weak try at it. If my other
suggestion of having the render() method call getters instead
of directly accessing instance variables is used, then
renderExtraAttributes() becomes more important. If it is not
provided and someone wants to stick in some non-HTML 4.01
compliant HTML, what they will do is override something like
the getSize() method so that it correctly renders the size
and then sticks in the understandard HTML. This is a nasty
hack but you know a programmer will choose that over
duplicating an entire render() method.
If you made it this far, thanks for reading this long email
;) I know I've posted much of this before in several
different messages, but hopefully this consolidation is useful.
Matt
-
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: Struts vs JSP : Validators
Tiles and validator contain functionality not readily available in JSF. Edgar -Original Message- From: Guido García Bernardo [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2003 6:41 AM To: Struts Developers List Subject: Struts vs JSP : Validators What do you think about Struts validators vs JSF validators ? (advantages, etc) I think you encourage the user to migrate to jsf html tags instead of using the struts ones (at least for new projects), but what about validators? Regards. - 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
For the first time in many months, there was some visible progress in the area of acceptance of submissions on tags. Thank you David and Robert. I do have some points that I am sure will draw fire, but I have been an idiot on this forum for so long... 1) It is fine that the basic tags in struts don't emit non-standard html, but why do struts tags have to 'police' the emission of non-html. For many intranet style projects, non standard html is important to achieve specific required functionality. To deny the need for such code seems strange. 2) It baffles my mind why struts insists the tags be so minimalistic and non-creative. I am aware of the difficulties in writing tags with the weird life span and semi random instantiation patterns and the bugs that are almost endemic with custom tags. But simple tags like java-script assisted date entry are so basic that simple implementations should be part of struts. Many of us have implementations of this (i.e. Matt Kruse's date functions) but there would be no hope of a submission passing muster. 3) Lastly, there are certain class of business information that the view needs, i.e. readonly, size. The tags should have to ability to easily pass this information from the business tier to the view. Again, the hope of a submission relating to this type of extension being accepted seems iffy, especially since generalizing a specific implementation is a bit of effort. Edgar -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2003 5:07 PM To: Struts Developers List Subject: Re: Editable Fields V/S Static Text David Graham wrote: There are 3 things that earn my -1 on tag enhancements: 1. Functionality already provided by the JSTL. Just as an aside, I believe by -1 David means that he won't volunteer his own time to the issue. As a volunteer, this is his absolute right. But, since the Struts minimum platform doesn't support JSTL, this point alone would not be a justification for a product change veto. 2. Functionality that supports non-standard HTML generation. 3. Tags that don't tie into the Struts core functionality. These are better suited for the Jakarta Taglibs project. However, IMHO, these would be technical justifications for a -1 veto =:) -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: Editable Fields V/S Static Text
You could use a JSP expression to output the readonly='true' attribute of the html:text or use the html-el library and use jstl to evaluate the attribute. Edgar -Original Message- From: Chris Gastin [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 12:29 AM To: [EMAIL PROTECTED] Subject: Editable Fields V/S Static Text Has anyone considered a feature which toggles between an editable form element and read only text / static text. I find myself developing JSPs where depending on the Use Case fieldA could be an editalbe text box (input name=fieldA value=My Text Value /) in Use Case 1 on xyz.jsp and readonly text /static text in Use Case 2 (My Text Value) on the same jsp. Presently I am using the logic:equal/logic:equal tags. Which get really messy. Here is some sample code. logic:equals name=actionForm property=myFieldEditable value=true html:text name=actionForm propertymyField / /logic:equal logic:equals name=actionForm property=myFieldEditable value=false bean:write name=actionForm propertymyField / /logic:equal It would be nice to add an attribute to the current tag libraries, which is a boolean, and does this toggling for you. Here is what I am envisioning If actionForm.myField = My Text Value; This tag html:text name=actionForm propertymyField readOnlyText=true/ would output My Text Value. Where html:text name=actionForm propertymyField readOnlyText=false/ the following tag would output input name=fieldA value=My Text Value / As you can imagine this would not be a huge undertaking to add this feature to the current tag libraries in struts. I could use this feature, and I am sure other could too. I am willing to contribute my time to the development effort. I am not stuck on the attribute name readOnlyText, and would welcome suggestions. Does this sound like a good idea, and if the answer is yes, what is the next step. Chris Gastin - 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
If the tags were structured differently so they were easier to extend without breaking when new releases of struts come out these issues might not come up. Of course, I myself have resigned myself to this issue since the tags are such a political football on this list. Edgar -Original Message- From: Robert Leland [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 12:23 PM To: Struts Developers List Subject: Re: Editable Fields V/S Static Text Yes, This has been brought up many times over the last 3 years, and probably has been implemented several times extending the Struts tags. I am not opposed to such a feature, and would support it, though other committers might not. The key argument against it is that it would transform the html tags into a non-standard implementation. The html tags are ment to be a thin module aware layer over the browsers tags, and nothing more. That is why we don't have a Calender tag or Date chooser tag. Though I suppose if you really --knocked our socks off !-- with a spiffy implementation it could become part of Struts. I believe since we still support Netscape 4.X series browsers, a read-only attribute has not been added. Since struts is trying to get out of the JSP tag business since 40-50% of our bugs are there. which subtracts from our limited time for the core framework. You might consider contributing the tag to http://struts.sf.net -Rob Chris Gastin wrote: Has anyone considered a feature which toggles between an editable form element and read only text / static text. I find myself developing JSPs where depending on the Use Case fieldA could be an editalbe text box (input name=fieldA value=My Text Value /) in Use Case 1 on xyz.jsp and readonly text /static text in Use Case 2 (My Text Value) on the same jsp. Presently I am using the logic:equal/logic:equal tags. Which get really messy. Here is some sample code. logic:equals name=actionForm property=myFieldEditable value=true html:text name=actionForm propertymyField / /logic:equal logic:equals name=actionForm property=myFieldEditable value=false bean:write name=actionForm propertymyField / /logic:equal It would be nice to add an attribute to the current tag libraries, which is a boolean, and does this toggling for you. Here is what I am envisioning If actionForm.myField = My Text Value; This tag html:text name=actionForm propertymyField readOnlyText=true/ would output My Text Value. Where html:text name=actionForm propertymyField readOnlyText=false/ the following tag would output input name=fieldA value=My Text Value / As you can imagine this would not be a huge undertaking to add this feature to the current tag libraries in struts. I could use this feature, and I am sure other could too. I am willing to contribute my time to the development effort. I am not stuck on the attribute name readOnlyText, and would welcome suggestions. Does this sound like a good idea, and if the answer is yes, what is the next step. Chris Gastin - 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 think it is more than a 'preference' based on the rapidity with which INVALID or WONTFIX is stamped on tag suggestions and patches. Perhaps it would be best if the tags were cut loose from struts and a different group of committers were responsible for them. I wouldn't, nor would I expect anyone else interested in the tags to make any time commitment with the current 'RULES' placed on the tags, i.e. ONLY emit HTML 4.01 or XHMTL 1.0, only a 'thin' layer over standard html tags, etc. Edgar -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 2:23 PM To: Struts Developers List Subject: Re: Editable Fields V/S Static Text It's only a political football in the sense that most of the current committers would prefer not to work on the HTML tags. If other folks came to the fore and committed themselves to supporting those tags, including writing unit tests and answering questions on the user list, I don't think you would see much opposition to development in that area -- along with an eventual nomination for committer status for the individuals involved so that they can do their work directly. Asking the existing committers to do all the work isn't the way to leverage how open source operates :-). Asking the existing committers to apply patches (and add unit test cases that already work), and pestering them until they get around to it (or nominate you to committer status so you can do it yourself) *is* the way to leverage how open source operates :-). Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Conceptual question about populating/validating values
If I were you I would use strings in my form beans (or at least methods or parallel field which accept strings as arguments) and look into third party stuff, i.e. Matt Kruse's date handling javascript. Additionally, I would bypass the validator and validate in my action (that way you would have the text the user entered). It is easy enough to emulate the validator flow of control (just read the mapping and get the 'input' value and forward to it). Edgar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 6:23 AM To: [EMAIL PROTECTED] Subject: Conceptual question about populating/validating values Hi there, I have a conceptual question about the population process for properties inside Struts. First of all a description: I have a JSP which includes a text input field like this: html:text name=myForm property=currentPerson.birthDate/ currentPerson is a Person-Object which has a birthDate-Attribute of type java.util.Date (!). This object is part of the myForm-Bean. I know about the alternative to have string values in my FormBean and set the property of my object by hand, but I don't like this !! The Request-Processing now does the following: 1. RequestProcessor.processPopulate(...) 2. RequestUtils.populate(...request) 3. BeanUtils.populate(bean, properties) ... 4. BeanUtils.setProperty(...) 5. ConvertUtils.convert(...) 6. PropertyUtils.setProperty(...) 6. RequestProcessor.processValidate(...) .. In my example the string representing a date is converted into a Date-Object in step 5 (ConvertUtils.convert()) I could use the sessions locale here for LOCALE-specific conversions and set a default value in case the conversion failes. I know about this ! Lets asume the following: - A user enters an invalid date - conversion failes and the default value will be set as birthDate - the user gets the page back including an error message about an invalid date - the date input field holds the default date now BUT: What I would like the user to see is it's original text, not the default value or anything else. ANY IDEA, how to do this ? (Without having string variables to store the form-values !) Since I also would also like to specify a regexp-mask in the validation.xml it looks to me, that the processValidate() is a bit too late. Thanks in advance, Dirk - 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: Conceptual question about populating/validating values
If you are saving system objects, i.e. request, to persistent objects, you will have synchronization problems. At least null them out at the end of the action cycle. I am not sure struts is the right framework to start your customizations since you have problems with the precepts. There are other frameworks out there which don't force the MVC abstraction through single use beans which might be a better starting point. Edgar -Original Message- From: Bygrave, Graham BGI UK [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 6:53 AM To: Struts Developers List Subject: RE: Conceptual question about populating/validating values I hit the same problem. I don't like having two fields (string and type specific) as you have to sync. them and it bloats your objects out. I don't like the idea of having two suites of objects, it's just more work. I don't like not using the validator either. I made some minor modifications to beanutils/convertutils to allow for the passing through of the property name in question. You also need to get access to the ServletRequest object in your custom converter (I did this using a filter which stores the requests in a thread local object, which you may find distasteful). I don't want to loose any erroneous input the user entered, so my custom converter writes the input into the http request (just using the full a.b.c notation is a key) and this is then put back into the jsp using a slightly modified TextTag. You have access to the request in your converter, so you can build any validation errors there. Regards, Graham. -Original Message- From: Edgar P Dollin [mailto:[EMAIL PROTECTED] Sent: 17 September 2003 12:33 To: Struts Developers List Subject: RE: Conceptual question about populating/validating values If I were you I would use strings in my form beans (or at least methods or parallel field which accept strings as arguments) and look into third party stuff, i.e. Matt Kruse's date handling javascript. Additionally, I would bypass the validator and validate in my action (that way you would have the text the user entered). It is easy enough to emulate the validator flow of control (just read the mapping and get the 'input' value and forward to it). Edgar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 6:23 AM To: [EMAIL PROTECTED] Subject: Conceptual question about populating/validating values Hi there, I have a conceptual question about the population process for properties inside Struts. First of all a description: I have a JSP which includes a text input field like this: html:text name=myForm property=currentPerson.birthDate/ currentPerson is a Person-Object which has a birthDate-Attribute of type java.util.Date (!). This object is part of the myForm-Bean. I know about the alternative to have string values in my FormBean and set the property of my object by hand, but I don't like this !! The Request-Processing now does the following: 1. RequestProcessor.processPopulate(...) 2. RequestUtils.populate(...request) 3. BeanUtils.populate(bean, properties) ... 4. BeanUtils.setProperty(...) 5. ConvertUtils.convert(...) 6. PropertyUtils.setProperty(...) 6. RequestProcessor.processValidate(...) .. In my example the string representing a date is converted into a Date-Object in step 5 (ConvertUtils.convert()) I could use the sessions locale here for LOCALE-specific conversions and set a default value in case the conversion failes. I know about this ! Lets asume the following: - A user enters an invalid date - conversion failes and the default value will be set as birthDate - the user gets the page back including an error message about an invalid date - the date input field holds the default date now BUT: What I would like the user to see is it's original text, not the default value or anything else. ANY IDEA, how to do this ? (Without having string variables to store the form-values !) Since I also would also like to specify a regexp-mask in the validation.xml it looks to me, that the processValidate() is a bit too late. Thanks in advance, Dirk - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
RE: signature [was: Struts web site [was: Re: Conversion of web s ite docs to XHTML]]
What about ethernet and pots? No matter what we use today, sooner or later I'm sure we'll be using something else Edgar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tiles-el and nested-el tags (was Re: Support for non-JSTL tags)
Thanks for the update. I'll see if I can work them a little for you. Edgar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag)
I haven't seen a patch for the tags (except for James, David and Aaron) in quite a while because the response to maintaining/enhancing the tags is so negative. Most of us who really use/customize the tags have gone our own way already. Edgar -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2003 7:10 PM To: Struts Developers List Subject: RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag) I feel it's become a bit too easy to give the JSTL answer and not deal with the issue as presented. And I do feel that if there are gaps in the functionality provided by the current supported environment we should at least consider additions, particularly if someone has gone to the trouble of providing a patch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag)
I would like to see those responses. Edgar -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2003 8:08 PM (Hey, maybe I should start answering the html taglib questions with the Velocity Tools solution!) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: forms tag ? serialaizable
Your form beans should be serializable if you are keeping them in session scope. I am not familiar with scaffoldingLib but AFAIK the straight struts ActionForm and derivatives all serialize OK. Obviously, everything you throw in an ActionForm must be serializable as well. There are a few classes in the jdk which are not serializable, each of which is listed in the javadoc. Hope that helps Edgar -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Vic Cekvenich Sent: Monday, March 24, 2003 5:03 PM To: '[EMAIL PROTECTED]' Subject: forms tag ? serialaizable AFAIK we can't specify the type of class that the form bean is in, in struts config. (not formbean, but form-beans ) For example, form-beans type= myserilazableformbeanbase This would allow me to implement session fail over of session beans. AFAIK, this was depercated in 1.1. Yes, this can be miss-used but So can someone educate me that this works, else it's a feature request. Easy way to test is to add this to resin, for example: session-config file-storeWEB-INF/session/file-store /session-config This give me exception that formbean is not seriazable (concreate class is, ie form-bean name=userBean type=org.apache.scaffoldingLib.beans.UserBean/ is, but the base class is not. This is true of Collections as well) tia, Vic - 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: Interesting Bug Fact
I would like to add an observation to this 'fact'. The tags have taken a huge hit due to the complexity tomcat added with 'pooled' tags. The pooling broke all the tags resulting in a high level of bug reporting. IMO it highlights the importance of the tag library to struts, at least until JSF is ready for prime time. Edgar -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2003 10:09 AM To: '[EMAIL PROTECTED]' Subject: Interesting Bug Fact I just did a quick bug search and roughly 35% of Struts' total bugs have been reported against the Custom Tags category. I think this highlights the difficulty of writing custom tags and supports a move to separate Struts distributions of Core and Custom Tags. David _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail - 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: Some taglibs are missing a few common attributes.
Unfortunately, you can't use bean:message as the value of an
attribute. Are you suggesting that the user does
c:set var=titlevalue
bean:message key=my.title bundle=mybundle /
/c:set
html-el:text property=mypro title=${titlevalue} /
That seems a little disconcerting.
Edgar
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 05, 2003 9:41 AM
To: '[EMAIL PROTECTED]'
Subject: Re: Some taglibs are missing a few common attributes.
I definitely don't think we should support replacement args
because then the
html tags turn into messaging tags. A bundle attribute might
be nice but
the bean:message or preferably fmt:message tags are more flexible.
David
From: James Mitchell [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Some taglibs are missing a few common attributes.
Date: Wed, 5 Mar 2003 06:04:08 -0500
We allow titleKey for the html:frame, altKey and titleKey for
html:button, and a few others, but do not allow a way to specify the
bundle or args.
Besides the obvious...
bean:define id=myMessage
bean:message key=my.title/
bean:define
html:sometag title=%=myMessage%/
...work-around, I'm wondering if we should add this.
I think we shouldn't. I think the work-around is a much
more flexible
and generally better solution given the options available with
bean:message.
Your thoughts?
--
James Mitchell
Web Developer/Struts Evangelist http://jakarta.apache.org/struts/
People demand freedom of speech to make up for the freedom
of thought
which they avoid.
- Soren Aabye Kierkegaard (1813-1855)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
-
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 12573] - Handling of HTML-Checkboxes and (dynamic) FormBeans result in false values
If this was an option in the tag, then the user could choose for himself to accept the 'small' risk of incompatible browers, i.e. shadowcheckboxes=true This would be a very nice addition to the tag libraries as it is one of the more confusing initial aspects of learning struts. Also, non-reseting checkboxes is a deterent to reuse of forms with checkboxes, as you are forcing the assumption of every checkbox being on the jsp page. Edgar -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Friday, February 14, 2003 11:30 AM To: [EMAIL PROTECTED] Subject: Re: [Bug 12573] - Handling of HTML-Checkboxes and (dynamic) FormBeans result in false values That may be how some browsers submit the form but AFAIK there is nothing in the HTTP spec that guarantees this ordering. David From: Emmanuel Feller [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: [Bug 12573] - Handling of HTML-Checkboxes and (dynamic) FormBeans result in false values Date: Fri, 14 Feb 2003 17:24:53 +0100 Hi James, We use this such of thing on projects in production for years and we do not have any bug related. We tested this with IE, Mozilla and Opera but it should work with any browser. When the form is submitted, the file is parsed and the checkbox and the input are in lexical order. I will submit a patch and committers will be able to test. I understand the process for bug solving, escuse my mistake. next i will use bugzilla :). Regards, Emmanuel Emmanuel Feller Cap Gemini Ernst Young +33 2 51 17 35 00 poste 37 16 +33 6 23 34 63 39 - Message d'origine - De : James Mitchell [EMAIL PROTECTED] A : 'Struts Developers List' [EMAIL PROTECTED] Envoye : vendredi 14 fevrier 2003 16:52 Objet : RE: [Bug 12573] - Handling of HTML-Checkboxes and (dynamic) FormBeans result in false values I don't believe that will work since you are not guaranteed any order for form fields submitted. -- James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org/ The man who does not read good books has no advantage over the man who cannot read them. - Mark Twain (1835-1910) -Original Message- From: Emmanuel Feller [mailto:[EMAIL PROTECTED]] Sent: Friday, February 14, 2003 10:45 AM To: Struts Developers List Subject: Re:[Bug 12573] - Handling of HTML-Checkboxes and (dynamic) FormBeans result in false values Hi, I'm quite new to the ML, struts and ASF projects, so please escuse my poor english (i'm french). If it is not the way to submit a solve the bug please redirect me. :) I have a solution for the chekbox missing in the request when not checked : the taglib should generate after the checkbox input tag an hidden input tag wich have the same name than the chekbox. So if the checkbox is checked, the first value in the request is 'yes' (from the checkbox) and ignore the second one, else the value of parameter is 'no' from the hidden input. I hope it helps. I'll submit to the list a patch for the taglib on monday if needed. Regards Emmanuel Emmanuel Feller Cap Gemini Ernst Young +33 2 51 17 35 00 poste 37 16 +33 6 23 34 63 39 -- --- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail - 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: nested taglib purpose?
If you do a lot of nesting, the nested tag lib is a lot easier to use than EL. Don't enhance it or even fix bugs, but leave it alone please. Thanks. Edgar -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 11, 2003 11:07 AM To: [EMAIL PROTECTED] Subject: nested taglib purpose? In reviewing bug 16916 I started wondering what the purpose of the nested taglib is. It seems like its functionality is handled by struts-el tags and the EL syntax they provide. That bug deals with Tomcat 4.1.18 which supports the EL so the need for nested goes away. Am I missing something? Thanks, Dave _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus - 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: [Proposal] Migrate to Dependency on commons-resources
I like the idea. While your at it, can each message pass in its own resource bundle so you can keep the resources with the Class/Package? Edgar -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 6:15 PM To: Struts Developers List Subject: Re: [Proposal] Migrate to Dependency on commons-resources I am using them outside of Struts now, and it makes perfect sense =:0) It's important to remember that the idea of a message resource is generic to an application and is not a Struts concept. If something occurs on the domain layer, the enterprise application should be able to return the information using the same tokens as the presentation tier. Or, more properly, the presentation tier (Struts) should use the same tokens as the rest of the application. =: Struts uses the ApplicationResource but the underlying idea is it belongs to the application generally (hence, the name). It's actually very difficult to write an multi-tier i18n enterprise application with something like the (Action)Messages. There are a ton of messges that you want to return from the domain, including confirmation messages (like record #63 inserted). Meanwhile, the Commons Validator also has the idea of a Message carrier (like ActionMessages) at its core, and there should be a generic implementation of this object in the Commons, whether Struts uses it or not. -Ted. David Graham wrote: ActionMessages doesn't make sense outside of Struts. It would need a new name at the least. If we move them to commons, they should become interfaces with some default implementations. Then people would be free to plugin their own implementation. I think they're fine staying in Struts for now; 2.0 might be a better time to look at this architecture. David From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: [Proposal] Migrate to Dependency on commons-resources Date: Mon, 13 Jan 2003 17:40:38 -0500 Can we also migrate the Message carrier [o.a.s.a.ActionMessages] and Message element [o.a.s.a.ActionMessages] to Commons Resources? The idea being a domain logic object may like to return a collection of Messages to the presentation tier. (At least mine would!) I'm thinking someone should be able to offload the whole ActionForm.validate() mechanism to the domain tier, and just use Struts to reconcile and display the messages according to the client's locale. I've actually already started to generalize ActionMessage/s. for this purpose. At one time, I think Martin and I were talking about putting it somewhere in the Commons, but I forget which package now. Resources makes sense to me. =:0) So, then, ActionMessages would also become a wrapper around a Commons class and would also encapsulate the Struts globals. Of course, I am volunteering to port the code, if that's what we want to do. -Ted. Craig R. McClanahan wrote: As we've discussed a couple of times, the last major functionality change we had discussed for Struts 1.1 was to migrate to dependence on commons-resources, rather than the proprietary message resource facilities inside og.apache.struts.util. As you might recall, Michael Schacter took a first crack at factoring out the Struts resources classes out to create this commons package, which is currently in the sandbox. I've recently gone through it, and did a major refactoring of commons-resources, to the point where I'm now ready to propose that we modify Struts to depend on it. I'd like the other committers to evaluate the current state of commons-resources, and my proposed integration plan below, to see what they think of this idea. The nightly build of commons-resources.jar included in recent Struts nightly builds is the code that I'm proposing. You can see the Javadocs for this code at: http://jakarta.apache.org/commons/resources/api/ and get the sources via either CVS (from jakarta-commons-sandbox) or nightly snapshots: http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-res ources/ In terms of Struts integration, I propose: (1) Most Struts classes declare a static MessageResources instance for the messages unique to that Struts package. For example, org.apache.struts.taglib.bean.CookieTag has this: protected static MessageResources messages = MessageResources.getMessageResources (org.apache.struts.taglib.bean.LocalStrings); This would be migrated to the new Messages class from commons-resources: protected static Messages messages = Messages.getMessages(org.apache.struts.taglib.bean); The calls to actually retrieve message strings are compatible with the existing code, as well as the properties files used to acquire the message strings, so no other changes should be required.
Tag Elimination
The html tags are useful struts tags in a standard browser environment. The nested iterators, since they iteract nicely with html tags, seem more straight forward to use than the equivalent JSTL. If you are already iterating using the nested taglib, the nested logic tags are again more straightforward to use than the equivalent jstl tags. If the jstl tags could be used easily as the iterating library for the html tags, it would be a nice benefit for those who use form nesting. Edgar 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: [FRIDAY] Jane! Stop this crazy thing!
John Brenner. Stand on Zanzibar. Edgar -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 31, 2002 5:14 AM To: Struts Developers List; [EMAIL PROTECTED] Subject: [FRIDAY] Jane! Stop this crazy thing! [EMAIL PROTECTED] wrote: martinc 2002/12/30 23:29:16 Modified:.build-webapps.xml Log: Since we have links to the news and FAQs in the documentation app, and on the web site, it would be a really good idea to actually build these and include them in the documentation app, and thus have them appear on the web site. Now please excuse me while I go rebuild the 1.1-b3 release to include all the relevant content... Not Friday, but it is New Years Eve =:0) ... which of our many favorite Science Fiction authors wrote: It's suppose to be automatic, but you still have to press the button. Autographed Struts in Action to first lucky winner to cite author and book =;0) And, lets all wish Martin a very Happy Hogmanay http://www.dunsnortin.demon.co.uk/Hgmnyweb/hogmanay/hogmanorigin.htm ... I think he's going to have a very nice present for us all !! -Ted. Jane? Who's Jane? * http://www.cybercomm.nl/~ivo/ * http://www.cybercomm.nl/~ivo/sounds.html -- 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: Overloaded Setters in Form
I have had success overloading properties and used the effect liberally. I have found that if you are consistent in your overloading, i.e. for every setter of type x supply a getter of type x as well (at least in the containers I am using) they seem to function. Based on your comments, I have a concern that something will break going forward. I looked for overloading in the spec (attached) and they don't specifically speak to the issue. http://java.sun.com/products/javabeans/docs/beans.101.pdf Could you point me toward some documentation which gives more details? Thanks Edgar -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 24, 2002 9:12 AM To: Struts Developers List Subject: Re: Overloaded Setters in Form It's contrary to the JavaBean specification to overload the property methods (getters and setters), if that's what you are trying to do. So, it won't work, because it's not suppose to. -Ted. 12/23/2002 10:31:41 PM, Carl Fyffe [EMAIL PROTECTED] wrote: Seasons greetings friends! I sent an email inquiring about overloaded setters in Forms to the struts-user mailing list. I was told that I needed a BeanInfo. I gave the BeanInfo a try and it did not work. So, I started reading code and decided that an overloaded example in TestBean was needed. Of course it now fails just like my example. I am stuck there. The BeanInfo's that I have created, with and without my overloaded methods, do not work. Does anyone have a TestBeanBeanInfo that works? Any advice would be greatly appreciated. Carl -- 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]
RE: Overloaded Setters in Form
I am not using Introspector. I either use low level introspection (in which you can specifically set your object parameter types) or I let struts do the introspection. Perhaps your issue is just with Introspector? Edgar -Original Message- From: Carl Fyffe [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 24, 2002 1:13 PM To: 'Struts Developers List' Subject: RE: Overloaded Setters in Form Edgar does have a point, the spec doesn't say beans *bad joke* about overloading. I gave it another go after reading (AGAIN) Craig's first post on this topic (12/14/2002) and this time, instead of using a null getter, I provided a getter for the overloaded setter. Still does not work. Introspector only returns one PropertyDescriptor for the property. Edgar and Craig both lead me to believe that this is possible, but I am starting to think that I am trying to put a square peg in a round hole. Edgar: Would you be willing to share some of your implementation details? Architectural Gurus: The problem I am trying to solve is that I have a data source that returns Strings only (xml file), should I create Beans specifically for that data source and then convert over to my Form? Thanks for all of your help, Carl -Original Message- From: Edgar P. Dollin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 24, 2002 10:26 AM To: 'Struts Developers List' Subject: RE: Overloaded Setters in Form I have had success overloading properties and used the effect liberally. I have found that if you are consistent in your overloading, i.e. for every setter of type x supply a getter of type x as well (at least in the containers I am using) they seem to function. Based on your comments, I have a concern that something will break going forward. I looked for overloading in the spec (attached) and they don't specifically speak to the issue. http://java.sun.com/products/javabeans/docs/beans.101.pdf Could you point me toward some documentation which gives more details? Thanks Edgar -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 24, 2002 9:12 AM To: Struts Developers List Subject: Re: Overloaded Setters in Form It's contrary to the JavaBean specification to overload the property methods (getters and setters), if that's what you are trying to do. So, it won't work, because it's not suppose to. -Ted. 12/23/2002 10:31:41 PM, Carl Fyffe [EMAIL PROTECTED] wrote: Seasons greetings friends! I sent an email inquiring about overloaded setters in Forms to the struts-user mailing list. I was told that I needed a BeanInfo. I gave the BeanInfo a try and it did not work. So, I started reading code and decided that an overloaded example in TestBean was needed. Of course it now fails just like my example. I am stuck there. The BeanInfo's that I have created, with and without my overloaded methods, do not work. Does anyone have a TestBeanBeanInfo that works? Any advice would be greatly appreciated. Carl -- 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] -- 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: Overloaded Setters in Form
I switch between booleans and strings for actions and imbed actions into a 'generic' class. Struts currently, doesn't have a problem with this (at least in the current versions). Is there a chance this will stop working? Edgar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: modifying the mapping input path during validation
Can this be a property of the form itself? Edgar -Original Message- From: Brian Moseley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 17, 2002 1:10 PM To: [EMAIL PROTECTED] Subject: Re: modifying the mapping input path during validation 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:[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: modifying the mapping input path during validation
If you change the value on the form, the target JSP will be created with the value set assuming the form field is on the JSP. Edgar -Original Message- From: Brian Moseley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 17, 2002 1:38 PM To: Struts Developers List Subject: Re: modifying the mapping input path during validation Edgar P. Dollin wrote: Can this be a property of the form itself? the id is set as a property on the form, but there's no logic anywhere to set it as a request parameter before RequestProcessor forwards to the input page. -- 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: [OT]AW: Why are people are up on Struts
The version to try for windoze is lugaru / epsilon. If you learn the keystrokes you will never give it up. Edgar -Original Message- From: Phase Web and Multimedia [mailto:[EMAIL PROTECTED]] Sent: Friday, December 13, 2002 1:48 PM To: Struts Developers List Subject: [OT]AW: Why are people are up on Struts Just because you guys are talking so highly about emacs... I'm gonna have to go back and try it on some things for a while. Thanks a lot! I hate it when people tell me things that strike my curiosity and make me think... H, maybe I passed that up to hastily Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -Original Message- From: Phase Web and Multimedia [mailto:[EMAIL PROTECTED]] Sent: Friday, December 13, 2002 11:42 AM To: Struts Developers List Subject: RE: [OT] Re: Why are people are up on Struts It's a trade-off. Many of the great plugins and such that are supplied with a well developed (cross-platform) ide are far better in my book for development at large. I only resort to emacs/vi/pico when i am editing files on a server remotely. But, I am in control of all the code I write and I'm not writing any perl or c/c++. Straight JAVA is what I write. So emacs is not that efficient to me. P.S. Eclipse is a great ide and has a format method that cleans up messy java code quite nice. But, it lack great search and replace features that emacs does have. Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -Original Message- From: Benjamin Tomasini [mailto:[EMAIL PROTECTED]] Sent: Friday, December 13, 2002 11:15 AM To: Struts Developers List Subject: Re: [OT] Re: Why are people are up on Struts Normally a reader only in this list, but here are 2 cents... With a basic knowledge of Emacs, Ant, and Perl you can conquer the world faster than with any IDE I know of. And conquer it from pretty much any shell - bash, X, even Windows! Plus, Emacs is great for cleaning up messy code. Its indent feature in java-mode (cc-mode) is quite handy. On Fri, 2002-12-13 at 14:00, Eddie Bush wrote: I can live with vi if it's forced upon me, but I much prefer Emacs. 'Course nowadays, assuming you're using an x terminal (or are on windows) both of them are fairly easily used through their toolbars ... at least, I think vim has one now (or can perhaps - nearly certain). I suppose that's for the mortals among us ;-O I just go for the arcane key sequences personally - so much more efficient. One nifty thing I really like about Emacs is that, sometimes I can remember the command name but not it's key sequence - and it tells you what the sequence is once you invoke it the long way. So, I can keep important shortcuts in my head, and, when I run across a situation that requires me to use something that I don't recall the shortcut for, I can invoke it manually and get a referesher on what the sequence is to invoke it. I really like that feature :-) It works great so long as you can remember the command name or ... at least have an idea (as it has completion assistance for commands too). David Graham wrote: I like vi now that I know how to use it but why couldn't they put common commands at the bottom of the screen for us mortals? David -- Eddie Bush -- 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] -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Why struts is looked down upon...
Congratulations... You have gotten big enough to draw negative attention. It is a sign of true success. Edgar -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED]] Sent: Friday, December 06, 2002 9:36 PM To: [EMAIL PROTECTED] Subject: Why struts is looked down upon... Any of you care to comment on this? http://java.enigmastation.com/Q806 I'll post a rebuttle on my weblog shortly. Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
