Re: Compartmentalization of Modules (was Re: [18111] et al)
Comments below... - Original Message - From: James Mitchell [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 22, 2004 4:18 PM Subject: Re: Compartmentalization of Modules (was Re: [18111] et al) html:link module=exercise action=welcome / I don't think that's the best idea. Doing that means your pages know they are in a particular module. I disagree that this means pages know that they are in a particular module. Continuing with the previous example, if I put html:link module=exercise action=welcome / in my JSP, that means that I know there is a module called exercise with an action called welcome. However, I should be able to put that same link in a JSP that is in the default module or any module and it will still work. I don't see a problem with this proposed change to the html:link tag. If I were to begin using them again, I like the idea of being able to use (dare I say 'share') a single jsp in several different Modules. Definitely. I do this all the time. So you'll get a different looking (and acting) page but you don't have to copy the jsp into that modules folder. It simply renders the images, css, scripts, etc, etc for the Module that it happens to be used in. Does that make sense? Yep, that makes sense. What I do now is I have a 'common' folder directly off the webapp root where I put JSPs that are used by multiple different modules. (My 'common' folder is not a proper Struts module, just a folder for me to put in common JSPs.) Of course this solution can be generalized to use any folder name. Now the problem with this approach is that referencing a JSP in the common folder is a little different when coming from the default module or from some other module. For example... default module: jsp:include page=common/commonpage1.jsp/ other modules: jsp:include page=../common/commonpage1.jsp/ My solution to this problem is basically that I don't use the default module for much of anything. My current thinking is that it's good to initialize plugins and to use for the login and logoff actions, and that's it. Another solution is to write a custom tag (which I have done) that will translate URLs for you automatically. I do something like this: krm:urlcommon/commonpage1.jsp/krm:url which will always translate to common/commonpage1.jsp (the tag just takes its body contents and prepends http://ip_address/webapp_name/) Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
Niall - If you do add on to this patch to support JavaScript validations of numberFormats, there is probably some existing JavaScript code available that you can use. I would start by looking at Matt Kruse's JavaScript Date Functions, which you can find here: http://www.mattkruse.com/javascript/date/ Matt - Original Message - From: Niall Pemberton [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 9:48 AM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] OK hey, appreciate your feedback - and the mask/regexp gives me another string to my bow! I do think using the DecimalFormat style patterns is much easier and intuitive, but there is the issue over JavaScript and there are issues with the DecimalFormat parse() method. I think I need to re-think this enhacement request so I'll drop it for the moment and perhaps submit something different at a later date. Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 1:46 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] --- Niall Pemberton [EMAIL PROTECTED] wrote: I agree with both of you! Not having JavaScript implementation shouldn't be an issue - if people want it then someone would come up with it. However, because the approach I took was to modify the exiting number validations (byte, short, long, integer, float, double) then it means that where there is JavaScript validation (not all of them seem to have) these will now fail if a pattern is used, because they don't take into account the pattern. I would put some additional time on this, if a committer was willing to implement it. But since David Graham has said he is -1 on this, doesn't that effectively make this enhacement request dead? There wasn't a vote so my -1 is more of an indication that I don't like the idea. Mask is the most flexible validation that allows many things like formatted number validations. If you can't get your regex to work you might try writing a custom validation action that uses DecimalFormat. If that works you could post a patch to bugzilla. I encourage you to get the regex to work though because it will make life easier in the long run :-). David Niall Richard Hightower wrote ... I agree about that sticky wicket, but There are already validation rules that do not have client-side support (via JavaScript). At least this type of stuff would be nice in the contrib area. Ted Husted wrote ... In principle, I'd agree with Rick, since these type of patterns are the standard way of doing this sort of thing on the Java platform. But, the sticky wicket is lack of a JavaScript implementation. People would expect an implementation like this to include client-side support, as the other validations do. -Ted. On Thu, 15 Jan 2004 20:54:17 -0700, Richard Hightower wrote: Niall, I don't get a vote. I am not a committer. But if I did I would vote +1 on the idea (I have not studied your implementation). I can write regular expressions in a pinch, but why not support all of the java.text.* in the validator rules (including currencey). I like the idea. Rick Hightower Developer Struts/J2EE training -- http://www.arc-mind.com/strutsCourse.htm Struts/J2EE consulting -- http://www.arc- mind.com/consulting.htm#StrutsMentoring -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 5:38 PM To: Struts Developers List Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] OK so how can it be done with mask? also, it doesn't get more basic than numbers...if it can be done with mask, but its complicated, doesn't ease of use cut any ice? Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in
Re: why are form beans required for html:form?
Joe - I agree that html:form is being too aggressive in its requirement of a form bean. I believe there is already an open BugZilla ticket for this issue: http://issues.apache.org/bugzilla/show_bug.cgi?id=24356 Your reasoning is a little different than the reasoning in the ticket, so it might be useful to include your email as a comment on the bug. Matt - Original Message - From: Joe Germuska [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, January 14, 2004 10:32 AM Subject: why are form beans required for html:form? I'm working with an old Struts application recently ported to a Struts 1.2 nightly. One land mine that keeps popping up is that pages using the html:form JSP tag which used to work now no longer do. I have one specific case where a developer chose not to implement an ActionForm class (probably because the app also pre-dated DynaForms and/or he was being lazy) so now the JSP throws an exception when it comes to the html:form tag and can't find a form bean associated with the destination action. Now, I'm all for encouraging people to use Struts the way it was designed to be used, but in this case, the form has no HTML fields which are pre-filled from a form bean, so it seems pushy of the html:form tag to insist that this is an error condition. Would it make more sense to have the individual input tags complain if they can't find a form bean, and have html:form be more permissive? 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] - 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)
- Original Message - From: Joe Germuska [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 5:04 PM Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum) So then, with specific frameworks, I don't understand how Pico's orientation towards constructors works in an environment where beans need to be dynamically instantiated, but perhaps I just haven't thought about it hard enough. Avalon seems too heavy, which leaves us (or me at least) with Spring and HiveMind. I haven't developed with either but so far the docs for Spring give me a warm fuzzy feeling while the HiveMind docs kind of scare me. I agree with your assessment of frameworks 100%. However, Spring is under an LGPL license, so Struts can't use Spring unless either Struts switches to LGPL or Spring switches to ASF, right? It would be kind of silly for Struts to stay under ASF in this case, since the Spring license would force the undesirable LGPL clauses on any projects that were based on Struts. Am I right? Matt - 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)
Sorry about that! You are right, the license is ASF. It says so both on the SourceForge site and in the license included in Milestone 3. I don't know where I got the idea that it was LGPL. Matt - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 5:20 PM Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum) Nope, Spring is Apache-style, I just checked. You had me worried there for a minute :) Don On Wed, 17 Dec 2003, Sgarlata Matt wrote: - Original Message - From: Joe Germuska [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 5:04 PM Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum) So then, with specific frameworks, I don't understand how Pico's orientation towards constructors works in an environment where beans need to be dynamically instantiated, but perhaps I just haven't thought about it hard enough. Avalon seems too heavy, which leaves us (or me at least) with Spring and HiveMind. I haven't developed with either but so far the docs for Spring give me a warm fuzzy feeling while the HiveMind docs kind of scare me. I agree with your assessment of frameworks 100%. However, Spring is under an LGPL license, so Struts can't use Spring unless either Struts switches to LGPL or Spring switches to ASF, right? It would be kind of silly for Struts to stay under ASF in this case, since the Spring license would force the undesirable LGPL clauses on any projects that were based on Struts. Am I right? 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action Wrappers. 2nd Request for Comments Code Contribution
Hi, I'm not a committer either, but I've been lurking on this list a bit and have learned a thing or two. Your plug-in is a very frequently requested feature, but it definitely looks a lot like what is called action chaining, which is not considered a Struts best practice. You can search the mail archives for more information. As a quick summary, action chaining is considered a bad idea because it generally indicates that logic that should be in a separate business tier has been pushed up inappropriately to the presentation tier. If you are looking for a way to chain commands in the business tier you might want to investigate the Commons Chain package, which is currently in the jakarta commons sandbox. If you still think your plug-in is worthwhile after reading why people dislike Struts chaining, SourceForge could be a good place to get started. Matt - Original Message - From: john sessler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 3:35 PM Subject: Action Wrappers. 2nd Request for Comments Code Contribution Hello All, I've developed code that I would like to submit for comment and consideration for inclusion in the Struts code base whenever it becomes ready for prime time. Following is a very brief description of the purpose of the code. Complete information, code and API can be found here: https://www.sistemas-jasper.com/indexStrutsActionWrappers.htm. Action wrappers are Struts actions that invoke other actions. The design goal of action wrappers was to sift common functionality from actions so that it can be reused. Action wrappers are meant to be plug and play components. They are useful because they allow the designer to apply common functionality to application specific actions. They are rather like decorators because they can be applied to and and removed from their wrapped actions without modification of the wrapped action. Action wrappers are configured in the Struts configuration file. The idea for action wrappers originated from the need to protect JSP views from being duplicated by the user simply by cutting and pasting the URL in a new browser window address box. A problem very closely related to this one which influenced the development of action wrappers is the problem of insuring that an action is executed exactly one time even though the link or form which leads to the action remains available to the user. The code works without modification to existing Struts code (1.1). However, it uses a somewhat uncertain mechanism to accomplish action invocation. Please read the API docs for class ActionProcessor for a description of the mechanism and for possible solutions. I have never contributed code to an open source project before so I'd like some guidance on how to go forward. Thank you, John A. Sessler - Do you Yahoo!? The New Yahoo! Shopping - with improved product search - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
[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]
Re: [Short Term Plan] Struts to depend on Validator 1.1.0
Some other suggestions: findErrors() getErrors() getErrorMessages() getActionMessages() I like doValidate(), validateForm(), getActionMessages() and getErrorMessages(). Matt - Original Message - From: Robert Leland [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, September 26, 2003 2:59 PM Subject: Re: [Short Term Plan] Struts to depend on Validator 1.1.0 David Graham wrote: Only ActionError was deprecated, not ActionErrors. We still need to use ActionErrors because the ActionForm.validate() method returns an instance of that class. ActionMessage should be used instead of ActionError though. Eventually we'll need to add a method that will allow us to deprecate ActionForm.validate(), just as Action.execute() deprecated Action.perform(). The only reason I haven't done that is I couldn't think of a good name maybe valid(), validateForm(), doValidate(), checkFields(), checkForm() ... ??? - 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: Action Chaining
There are probably many different solutions to make action chaining more intuitive. However, action chaining is not considered a best practice in the Struts community so effort will not be put forward to make it easier to do. There has been a lot of discussion of action chaining in both the user and developer list archives. As a quick summary, action chaining is considered a bad idea because it generally indicates that logic that should be in a separate business tier has been pushed up inappropriately to the presentation tier. If you are looking for a way to chain commands in the business tier you might want to investigate the Commons Chain package, which is currently in the jakarta commons sandbox. I hope that answers your question, Matt - Original Message - From: Derek Richardson [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, September 26, 2003 3:57 PM Subject: Action Chaining To enable action chaining in an intuitive way, it seems that when the ActionServlet is called, it can look for an attribute in the request that indicates whether it has run before in this request. If the attribute is not there, do everthing and then set the attribute; if the attribute is there, don't reload the action form and don't reset the action errors collection and don't do anything else that intuitively should be one-time-only. Or maybe it's the request processor that's modified, in the same spirit. I've just had the idea, haven't actually looked at the code. Of course, this is so obvious that it must have been discarded already with good reason. So, before I find out why it's not reasonable the hard way by implementing it, please tell me where the hidden problems lie. Thanks, Derek Richardson - 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
- Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, September 26, 2003 7:52 PM Subject: Re: Editable Fields V/S Static Text However, at this time, we have a Struts-el taglib in circulation. We even have a Struts-faces taglib in the wings. We've definately reached the point where the JSTL has to sink or swim on its own. If the Community wants to use the tags, then we are bound to facilitate that any way we can. Standards are essential, but community-building is the Apache prime directive, and a large segment of our community is still locked out of the JCP JSTL standard. It would be neat to build tags that extend JSTL functionality to fill in gaps left by the standard. Let the JSTL do the heavy lifting and add on as necessary. I think this is the mandate of the taglibs-unstandard tag library, which is still in the sandbox. I like the tags I see there a lot, particularly un:instanceOf and un:invoke, although I think the tags could definitely use some work. The documentation is awful and last time I looked un:invoke couldn't invoke methods with parameters (it could only invoke methods without parameters). I would love to see some of the power of Velocity put into JSP taglibs, like the ability to use the EL-like syntax to invoke methods. Of course if I really want that I should probably just use Velocity, huh? ;) Of course at a certain point you have basically eliminated the advantage of removing scriptlet code because your JSP tags are so sophisticated, but in my opinion the JSTL is a lot easier to use than scriptlets because it's easier to get at things in the pageContext, request, etc. and on the presentation tier you often don't care about data types. David Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Editable Fields V/S Static Text
- Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, September 26, 2003 1:02 AM Subject: Re: Editable Fields V/S Static Text --- Robert Leland [EMAIL PROTECTED] wrote: David Graham wrote: --- Sgarlata Matt [EMAIL PROTECTED] wrote: OK, here's another idea. I searched the archives for it and couldn't find it. How about two simple changes: 1) Add a new renderExtraAttributes() method that gives people the chance to throw non-standard HTML into their tags that extend from Struts tags. I am -1 on the Struts tags supporting any non-standard HTML including providing the suggested hook method. Like Java itself, Struts aims to be a cross-platform tool. Adding support for non-standard HTML undermines that goal and promotes non-interoperability. Is it really the Struts tag library's mantra to dictate that the tags should not be modified externally to gain needed functionality ? I'm still not clear about this. What is the needed functionality that we're not providing? The needed functionality is the ability to cleanly extend the Struts tags. They 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. By not providing hooks, wheather these are the correct ones or not, isn't very developer friendly. A framwork can be developer friendly, and well designed at the same time. I agree but hook methods that exist solely to help people write non-standard HTML aren't the way to go. Methods that perform a standard function that can be overridden are more appropriate IMO. And It's not that the tags would be producing non standard HTML 4.01, it's that they would/could add composite functionality over and above standard HTML that would still be 4.01 compliant. What's an example of this? I thought of a use case that *is* 4.01 compliant! 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. 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. I hope all this is clear, the threads are getting vicious here... David Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Editable Fields V/S Static Text
Has anyone ever discussed adding a general-purpose attributes attribute to the html tag library to support non-standard HTML like this? For example, html:text property='something' attributes='readonly onclick=alert(\hello\)\'/ Obviously it is better to not include onclick on the attributes attribute, but I just included it as an example. Just a thought... Matt - Original Message - From: Robert Leland [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 1:23 PM 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
OK, here's another idea. I searched the archives for it and couldn't find
it.
How about two simple changes:
1) Add a new renderExtraAttributes() method that gives people the chance to
throw non-standard HTML into their tags that extend from Struts tags. Here
is a snippet from BaseFieldTag.java:
snip
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
The use cases for this are (a) to support the readonly attribute and (b) to
support the attributes extension that was shot down for inclusion in the
out-of-the-box Struts html tags.
2) Instead of accessing instance variables directly, use getters. (I'm not
sure if this will cause problems with the EL versions of tags... thoughts
anyone?)
snip
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.
I apologize in advance if this has been discussed before. ([OT] I really
wish there was an easier way to search the archives. I have resorted to
googling them, but it's still a pain.)
Matt
- Original Message -
From: Robert Leland [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 1:41 PM
Subject: Re: Editable Fields V/S Static Text
Sgarlata Matt wrote:
Has anyone ever discussed adding a general-purpose attributes attribute
to
the html tag library to support non-standard HTML like this? For
example,
Yes, it was vetoed by several committers. Search the archives.
-
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
OK, here's another idea. I searched the archives for it and couldn't find
it.
How about two simple changes:
1) Add a new renderExtraAttributes() method that gives people the chance to
throw non-standard HTML into their tags that extend from Struts tags. Here
is a snippet from BaseFieldTag.java:
snip
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
The use cases for this are (a) to support the readonly attribute and (b) to
support the attributes extension that was shot down for inclusion in the
out-of-the-box Struts html tags.
2) Instead of accessing instance variables directly, use getters. (I'm not
sure if this will cause problems with the EL versions of tags... thoughts
anyone?)
snip
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.
I apologize in advance if this has been discussed before. ([OT] I really
wish there was an easier way to search the archives. I have resorted to
googling them, but it's still a pain.)
Matt
- Original Message -
From: Robert Leland [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 1:41 PM
Subject: Re: Editable Fields V/S Static Text
Sgarlata Matt wrote:
Has anyone ever discussed adding a general-purpose attributes attribute
to
the html tag library to support non-standard HTML like this? For
example,
Yes, it was vetoed by several committers. Search the archives.
-
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: Tiles-el and nested-el tags (was Re: Support for non-JSTL tags)
I'm planning on committing the tiles-el library this weekend, but I won't have any unit or integration tests for it by the time I commit it. I'll proceed down that path once it's committed, but that process will be slow. I'd appreciate it if motivated Tiles/JSTL users could test it as much as possible once I've put it into the nightly build. I'll do my best to do some testing with tiles-el. I don't use every tag and attribute in the library in my application, but I will test as much as I can. If you want any help on the development of the library let me know. I'll also start looking at the nested-el library, just for completeness. That seems like a good idea to me, although I don't use nested-el so I won't be able to help test. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tiles-el and nested-el tags (was Re: Support for non-JSTL tags)
Speaking of EL, I noticed we don't have EL versions of the Tiles tags. I
would be happy to provide the implementations, but I know it will be
tedious so I only want to proceed if there's a reasonably good chance
they will be added to the Struts distribution. Thoughts anyone?
In a private conversation Steve Raeburn indicated he would be interested
in these tags. Steve also pointed out we are missing the Nested tags,
but since I've never used those before I leave that tedious task to
someone else ;)
Matt
Steve Raeburn wrote:
You are right, JSTL doesn't completely remove the need for Struts specific
tags.
I think for the purposes of this discussion, the next generation would be
JSTL plus the struts-el taglib and when we talk about the Struts tags, we're
really talking about the traditional, non-el tags.
So keep using the html:form and other Struts tag and consider migrating to
the EL versions if you are using JSTL.
Steve
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: September 1, 2003 1:17 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465]
- Enhancement of the html:link tag)
Perhaps this belongs on the user list, but I think it is relevant for
the discussion at hand. You all seem to regard all of the Struts taglibs
as one item, for which JSTL is an alternative. While this is certainly
true for the logic: and bean: tags, I have not seen a replacement for
the
html: form tags (that is, html:form and all the controls) in JSTL.
The user guide
(http://jakarta.apache.org/struts/userGuide/building_view.html#form_bean
s)
suggests we replace
input type=text name=username
value=%= loginBean.getUsername() /
with
html:text property=username/
Does the use JSTL camp prefer this,
input type=text name=username
value=c:out value=${loginBean.username}/
or am I missing some basic JSTL?
Shai.
PS: There is a documentation error there; the original JSP should be
input type=text name=username
value=%= loginBean.getUsername() %/
--^
Shai.
---
Confidentiality Notice: This email transmission may contain
confidential or legally privileged information that is intended
only for the individual or entity named in the e-mail address. If
you are not the intended recipient, you are hereby notified that
any disclosure, copying, distribution, or reliance upon the
contents of this e-mail is strictly prohibited. If you have
received this e-mail transmission in error, please reply to the
sender, so that arrangements can be made for proper delivery, and
then please delete the message from your inbox.
-
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: Simplifying DynaActionForms
Craig R. McClanahan wrote: Also, if we were to add getString() and getBoolean(), we should also add setString() and setBoolean() for the same reasons. Hey, I know this is an old conversation, but I just realized String[] getStringArray() and void setStringArray(String[] array) might be nice too, since multiselects are used fairly often in some applications (OK, in my application) Craig Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
parameter vs. set-property (was Re: Flexible form support)
Ted Husted wrote: IMHO, the general purpose parameter has been a useful feature of ActionConfig/ActionMapping and is worth applying elsewhere. We just have to be quick to remind people that if they outgrow the general purpose parameter, then they should start extending the base object and using set-property. (As people often do now.) I agree; set-property is my favorite Struts extension point :) However, I would like to point out that it doesn't work very well for the message-resources element. The reason for this is that set-property populates a MessageResourcesConfig object instead of the actual MessageResources object. Then in the ActionServlet, when the MessageResources object is initialized it is passed the parameter information but is not passed any set-property information: // here the resources are created, and passed the parameter MessageResources resources = factoryObject.createResources(mrcs[i].getParameter()); // here the resources are passed the return null info resources.setReturnNull(mrcs[i].getNull()); //!! here I think we should pass the MessageResourcesConfig getServletContext().setAttribute( mrcs[i].getKey() + config.getPrefix(), resources); What do you think? Would this be a reasonable enhancement request? Can I post it in BugZilla with patches? -Ted. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: parameter vs. set-property (was Re: Flexible form support)
Robert Leland wrote: Sgarlata Matt wrote: What do you think? Would this be a reasonable enhancement request? Can I post it in BugZilla with patches? Since you have talked about it on the struts-user group, and it looks like the existing system makes your life harder, then open a Bugzilla request. What ever committer looks at the bug request will determine if the patch will be applied or modified. [Patches] are always welcome and speed the process ! If possible patch against the current HEAD of struts source code. Use the diff -u old new. I also like to use 'diff -u 5 old new' just to be sure. I've never used CVS before so I don't know what you mean. What is the current HEAD of struts source code mean? The Jakarta site says cvs diff -u Main.java patchfile.txt is preferred. Can I use that instead? -Rob -- Matthew Sgarlata Senior Consultant Booz Allen Hamilton Inc. Work: 703-377-0871 Fax: 703-902-3608 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Module Inheritance Revisited
- Original Message - From: Joe Germuska [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 5:07 PM Subject: Re: Module Inheritance Revisited Matt: This does sound like kind of an abuse of modules (if you'll pardon the term...) Pardoned - I probably am abusing them :) Actually so far my approach is working very well for our project. Really the only bad thing is copying resource bundle properties, global-forwards, and global-exceptions, but we can verify that is done correctly before major milestones and releases. Shouldn't all of that structure be a layer separate from Struts? It seems to me as if knowledge items should be part of your data model, not tangled up in Struts/Controller-View structures. Yes, the knowledge items are in the model, but each knowledge item has different properties to display on various screens (view) and different business rules (controller). Further, I would suggest that if you are going to have trouble finding actions after a few days then maybe you're using actions in a very... er, idiomatic way? Hehe I think you misunderstood me. We would have problems finding them not because of naming conventions but rather because the programmers on my team tend to arrange their code in, to borrow a good phrase, idiomatic ways. Struts apps have lots of actions, and it's hard to keep them organized in some sort of intelligible order in a single configuration file. (Actually, it's not hard, but we don't quite have mechanisms in place to enforce this level of discipline... no CMM here yet). I think Struts is very flexible, and I think it's great to try to make it more so, and I won't even say that it's foolish to hope that Struts could be as flexible as to fit your model -- but wooo-eee, you're pushing it to the limit! I'm hearing Mr. Scott... she canna take no more, Cap'n! LOL! Joe Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resource Bundle Prototyping
Good point! I ran originally ran into the resource bundle problem a long time ago, and forgot that there are other application-wide settings that would be nice to inherit from module to module. 1) Declarative Exception Handling (global-exceptions) - in my application, each module treats exceptions the same way, so we end up copying the global-exceptions portion of the struts-config file from module to module. 2) Global Forwards - same deal with global forwards. We have a debug forward that we use when debugging Action classes that gets copied to every module(System.out.println isn't practical on some application servers, and we haven't implemented log4j yet, so debug isn't a great example, but I'm sure someone can think of a better one) Matt - Original Message - From: adam kramer [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 11:52 AM Subject: Re: Resource Bundle Prototyping On Wed, 6 Aug 2003, Sgarlata Matt wrote: Has there been any discussion of allowing resource bundles to inherit properties from other resource bundles? For the project I am working on, it would be nice if we had one resource bundle with application-level properties and also module-specific resource bundles which had all the properties of the application-level resource bundle plus additional ones specific to that module. I know you can specify multiple resource bundles per module in Struts, but the problem is that certain components (e.g. - the validator) always look for the default resource bundle. In some of my projects I have run into the same problem as well, and I'm sure others have. It would be nice to have either a core module that provided resources to all modules or atleast a way of specifying a way for a the default resource bundle in modules to inherit values from a core resource bundle as to avoid having to repeat values throughout an application and introduce chances for inconsistency and error. This might be done by specifying an application-wide resource bundle in struts configuration and then have those values within all other module resource bundles (inclding the default module). You could obviously overwrite the values in your module's def. bundle. This would seem an appropriate feature, unless there were other core resources that needed to be shared throughout modules. Then it would seem a module-type enhance would be appropriate. ahh, oh so vague. :) -adam k. - 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: Resource Bundle Prototyping
I definitely agree that there are some issues surrounding modularization in Struts. I think that is to be expected because Struts 1.1 strove very hard to maintain backward compatibility with Struts 1.0, which did not have modules at all. IMHO, the conceptual issue is that there seems to be no notion of a Struts application reflected in the code because all the modules are peers with equal status. The only difference I can tell between the default module and the other modules is that its URLs are shorter. Also, almost accidentally, if you happen to define the entry point of your application to map to the default module then you can put all your plugins (except the validator) here only instead of re-specifying them in every module. Or did you mean I'm not modularizing my app well? Maybe so, but I still think a notion of a Struts application could be beneficial. Matt - Original Message - From: Joe Germuska [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 12:18 PM Subject: Re: Resource Bundle Prototyping At 12:01 -0400 8/6/03, Sgarlata Matt wrote: Good point! I ran originally ran into the resource bundle problem a long time ago, and forgot that there are other application-wide settings that would be nice to inherit from module to module. 1) Declarative Exception Handling (global-exceptions) - in my application, each module treats exceptions the same way, so we end up copying the global-exceptions portion of the struts-config file from module to module. 2) Global Forwards - same deal with global forwards. We have a debug forward that we use when debugging Action classes that gets copied to every module(System.out.println isn't practical on some application servers, and we haven't implemented log4j yet, so debug isn't a great example, but I'm sure someone can think of a better one) Maybe this is just pointing out a need to better understand the relationships between modules? Although they work for many of us in a simple fashion, problems like yours (among others) seem to point out ways in which the modularization is not completely worked out yet. Just a thought. I'm in between major Struts projects at the moment, so I don't have anything fresh in my own head. Joe -- -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com If nature worked that way, the universe would crash all the time. --Jaron Lanier - 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: ActionForwards, et al (was SuccessAction)
Comment at the bottom of this message... - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 6:13 PM Subject: RE: ActionForwards, et al (was SuccessAction) On Tue, 12 Aug 2003, Mainguy, Mike wrote: Date: Tue, 12 Aug 2003 18:03:14 -0400 From: Mainguy, Mike [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: ActionForwards, et al (was SuccessAction) This conversation seems to be a by-product of looking at the Action classes as children of the servlet and consumers of messages instead of stand-alone entities. One intriguing way of dealing with this (IMHO) would be to consider elements as being able to Pull the required components out of some other area (Context?) (much like how the Turbine framework does). Instead of Chaining commands or passing a context to every execute(), you would make available a generic application infrastructure that you could pull your required components from. Really this is probably just a semantic difference as the implementation (in my mind) would probably be much the same, but, to me when you word it as something 'Pulling' something out of the Context it makes more sense (errr, I can visualize it better at least) than trying to guess what should be 'Passed' along. Comments? Doesn't pulling something from some application infrastructure imply that somebody else pushed it into that infrastructure? For example, if you expect to find the HttpServletRequest object in there, presumably the controller must have seeded that content. It's also perfectly reasonable for one Command in a Chain (in commons-sandbox/chain terms) to push something into the Context that another Command executed later will need. In terms of making the infrastructure available to callers, it's pretty clear how passing a context object around makes the infrastructure available to anyone who needs it. Are there other options for how you'd make the infrastructure available without passing it? I haven't thought of any. Sorry if this was already said, but couldn't you use JNDI if you wanted to use a pull approach? I'm not sure if that's a good idea or not, but I thought I would throw it out there. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simplifying DynaActionForms
Casting to String gets to be quite painful with many form properties. Unless I've forgotten/missed an easier way of dealing with DynaActionForms, I propose we add a DynaActionForm.getAsString(String) method that does this casting for us. This is a minor point, but how about DynaActionForm.getString(String) instead? This would be consistent with naming conventions in java.sql.ResultSet (I can't think of other places with convenience methods like this off the top of my head). Also, following along in the java.sql.ResultSet thinking, would you also have getters for the other wrappers around primitives and the Date and Calendar objects? This might just clutter the interface... I wouldn't ever personally use them in my app because almost every form property is a String. Matt Thoughts? David __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.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]
Resource Bundle Prototyping
Has there been any discussion of allowing resource bundles to inherit properties from other resource bundles? For the project I am working on, it would be nice if we had one resource bundle with application-level properties and also module-specific resource bundles which had all the properties of the application-level resource bundle plus additional ones specific to that module. I know you can specify multiple resource bundles per module in Struts, but the problem is that certain components (e.g. - the validator) always look for the default resource bundle. I can elaborate on why exactly I would like to see this feature if someone would like me to. Thanks, Matt
Re: Resource Bundle Prototyping
I don't think it would be necessary to break backward compatibility. One approach that maintains backward compatability is to define a new child element directly off the root struts-config element in the struts-config file. Here is an example: struts-config parent-modules parent-module name=module1 !-- beans 1 and 2 from module1 -- form-beans form-bean name=bean1/ form-bean name=bean2/ /form-beans !-- all forwards from module1 -- global-forwards/ !-- all exceptions from module2 -- global-exceptions/ message-resources/ /parent-module parent-module name=module2 !-- all beans from module2 -- form-beans/ global-forwards/ message-resources/ /parent-module /parent-modules !-- rest of config follows -- /struts-config This would allow me to define the application notion I want for my project by using a single parent-module element. It would also be flexible enough to accomodate users with different needs. Matt - Original Message - From: Joe Germuska [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 12:36 PM Subject: Re: Resource Bundle Prototyping At 12:30 -0400 8/6/03, Sgarlata Matt wrote: Or did you mean I'm not modularizing my app well? Maybe so, but I still think a notion of a Struts application could be beneficial. No, I meant nothing like that. IMHO, the conceptual issue is that there seems to be no notion of a Struts application reflected in the code because all the modules are peers with equal status. I'm pretty sure this was an explicit design intention, although the main reason may have been to make backwards compatibility more manageable (or maybe not -- I can't cite any place where this was discussed; I just have vague recollections). From reading the lists, it's clear that many people intuitively expect modules to be less walled off from each other. Maybe a smarter Modularization, but one which might break some compatibility, could be targetted for a 1.5 release, or some mid-point between 2.0, which has a lot of bigger changes marked for it. Or maybe compatibility can be preserved anyway. Joe -- -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com If nature worked that way, the universe would crash all the time. --Jaron Lanier - 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]
Module Inheritance Revisited
Found the thread... http://www.mail-archive.com/[EMAIL PROTECTED]/msg08910.html So 1.1 is out now, and people are using Struts modules. Someone said they wanted to hear how Struts users use 1.1 with modules, so here goes. I think Craig will cringe if he reads this ;) The application I work on is a knowledge management application with many different developers working on it. Each knowledge item in the application gets its own module (let's call it a knowledge module). For example, a knowledge item might be a document, or a project. There are also functional modules, such as related links or data access which allow the user to relate a document to a project, or assign access rights to a knowledge item, respectively. The knowledge modules are pretty self-contained. The functional modules get pretty tricky to implement since they want to access stuff in the knowledge modules. For example, when you link a document to a project you want to start from the document and then search for the project using the standard search interface for projects. This means some tricky routing to different modules. So if I'm having all this difficulty with functional modules, why bother with modules at all and not just make the entire application one module? Well, here is the reasoning I've used: - Each module is in its own directory and each module has few files associated with it, so a junior programmer can get familiar with all the files for a single module and feel like he or she knows that module. - There is less source control contention for configuration files because few changes need to be made to the web.xml file and the default struts-config file. - Module information is grouped together logically, and there is no way to mess it up. Ideally if we had one struts-config file people would group things logically by module, but the reality is people are lazy and will (for example) just put their newest action element at the end of the action-mappings and it will be impossible to find actions after a few days. - All the files for a module can be easily copied to another application and customized for that application's needs because they are grouped together (the JSPs have their own directory, and the complete configuration for the module is in the WEB-INF directory). Well I'm about out of reasons, maybe I was just using modules because they were there ;) Honestly if I was the only person working on the project, the added complexity of modules wouldn't be worth it and I would just use a single module. Matt - Original Message - From: Robert Leland [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 4:14 PM Subject: Re: Resource Bundle Prototyping adam kramer wrote: On Wed, 6 Aug 2003, Joe Germuska wrote: I'm pretty sure this was an explicit design intention, although the main reason may have been to make backwards compatibility more manageable (or maybe not -- I can't cite any place where this was discussed; I just have vague recollections). From reading the lists, it's clear that many people intuitively expect modules to be less walled off from each other. Maybe a smarter Modularization, but one which might break some compatibility, could be targetted for a 1.5 release, or some mid-point between 2.0, which has a lot of bigger changes marked for it. I am going to make an effort to look through the archives and find the reasoning behind the design of the current modules (unless someone out there can enlighten us all). And explore the code and docs to come up with some ideas for application-wide module features that won't break struts conventions, etc... The modules would be much more useful to me if they had a concept of application and module. There were some thoughts about module inheritance that were discussed last summer. To my knowledge though no real design work has been done. It does seem that resource inheritance is the #1 requested feature. There may be a Bugzilla enhancement request ticket on this. -Rob -adam k. - 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: DynaActionForm.getMap() change
I don't like the performance impact of creating a new wrapper instance on every call to getMap(), however -- that can happen lots of times in a page. It's probably possible to create the wrapper once and then cache it (to reduce the impact somewhat), but it is still a spurious object creation. I considered caching as well but thought the implementation might get a bit ugly. It also doesn't help the form.map.prop issue. I have an idea that avoids caching and spurious object creation, but does not fix the form.map.prop issue. The idea is to create a new FixedKeyMap class which delegates all methods and constructors to the HashMap class with the following exceptions: - put(), putAll(), remove(), and clear() throw UnsupportedOperationException - a new set method with the same signature as the put method is created, but it can only be used to override values of existing keys. So the end effect is that when the map is created the key set is fixed forever by the constructor. The map's values can change, but its keys cannot. It's ugly for a Java or JSP developer to change the bean's properties using the Map instead of the methods in the DynaActionForm class, but at least it shouldn't cause any strange exceptions to occur. I'm just throwing this idea out there... actually I prefer having DynaActionForm implement Map directly. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Make DynaActionForms implement java.util.Map?
Hello Struts developers,
Is there a bug report / enhancement request to make DynaActionForm implement
java.util.Map? This would allow the forms to be used intuitively with the JSTL
c:out tag.
If we have a DynaActionForm named projectType with a property called shortDesc we
could then do
c:out value=${projectType.shortDesc}/
instead of
c:out value=${projectType.map.shortDesc}/
The former is more intuitive. Someone asks about this distinction every day on the
taglibs-users list.
Thanks,
Matt
Re: Trouble in mapping the request params to Form bean!
I'm not sure if Struts takes care of automatic conversions, but you should only be counting on that behavior if you are doing client-side input validation. Otherwise if the user inputs, say, an invalid Date, the conversion will fail. There might also be a problem with automatic conversions if the user doesn't input anything (for example, passing an empty string to the java.math.BigDecimal construct causes an exception to be thrown), but again I'm not sure. I think it is a Struts best practice to use only String and String[] properties. Hope this helps, Matt - Original Message - From: Karikalan Kumaresan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 10:14 AM Subject: Trouble in mapping the request params to Form bean! Hi, I am using Struts 1.1, and having a Form bean which has different type of properties (Integer, String, Date), as far as I know, struts takes care of the automatic type conversion of the bean properties, but I am getting the following error am I missing something here, any help would be greatly appreciated. java.lang.IllegalArgumentException: argument type mismatch at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtils.j ava:1789) at org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtils.j ava:1684) at org.apache.commons.beanutils.PropertyUtils.setProperty(PropertyUtils.java:17 13) at org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:1019) at org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808) at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:1252) at org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.j ava:821) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:254) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) and it is running in tomcat 4.1.24 Thanks, Karikalan - 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: Controller and Actions
Hello again Daniel, I'm not as experienced with OO development in general as you are, but let me elaborate on the approach I took with Struts. It isn't as clean as an implementation might be with some of the other design patterns you discuss, but it is one approach. I really think it does do all of the things you listed in your scenario, so I included references to your scenario in parantheses. The system I am working on is a simple knowledge management system. Basically each knowledge item is some metadata stored in a database, usually with an associated external file (word document, excel spreadsheet, etc). Regardless of whether you are working with a document or a project knowledge item, you have to perform the same basic actions to it: add a new item, edit an existing item, save an item, and view an item. The add and edit actions both forward to a html form, the only difference being that when you are editing you need to read in the fields from the database and pre-populate the html form (6). The save and view actions both forward to a screen where all the information about the knowledge item is displayed, along with some other associated data (6). Obviously the save action is saving data in a database, and is having the Commons Validator validate the form (2, 5). Actually I've had some trouble with the validator, but it will at least do some validation. All 4 of these different actions use the same form bean, and extends from the same abstract action class (attached) which I defined so that I would not have to re-code all this behavior. In your case delegation might be more appropriate, but inheritance works OK for the project I am working on. So basically the way I approach Struts development is that if there is one bean with similar responsibilities (I read ahead to your reply to Brandon's email) I associate it with a single DispatchAction. There are some technical differences between the fields I need in different places, but in spirit I am talking about the same chunk of data every time I use the form. Finally, the LookupDispatchAction might be more appropriate for the application you described. It's a little complicated for our project so I haven't looked into it. This would take care of picking the action based on which button was clicked (3). If it any point an exception occurs, I leave it unchecked so that I can deal with it in the global-exception section of the struts-config file (4). The only item I didn't hit in your scenario is (1), but that is handled automatically by HTML, HTTP, the application server, Struts, etc. and is transparent to the developer. Matt PS - The attached abstract action class is for illustration purposes only. I removed some of the code we actually use for the sake of simplicity. - Original Message - From: Daniel Steudel [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 1:53 AM Subject: Re: Controller and Actions thx matt I agree that you should have several actions for a single form. Fortunately, you can do this with Strut's DispatchAction. I make extensive use of in the project I am working on. i honestly have to tell you i haven't heard of this opportunity. i checked it out but there are still some things i suggest as not being best praktice. I think everything you described in your 6 step scenario can be done with a combination of dispatch actions, the commons validator, and Strut's declarative exception handling. i don't agree with you here. i also think that you can work around with this setup but it is not satisfying. again the dispatchaction is only one action which makes you infexible. i think of actions as a potion of software you can put into various contexts. best example would be a form reset action which can be put on every view to reset the userinput. as far as i can see you have to provide a reset routine in every action to do so. if the reset action would be independent it would be possible to use this action in various contexts. furthermore you have only one form an action can deal with. this means for the different contexts you have to create different forms to adequately handle the userinput. if you look at swing actions deal with input themselves. i don't think processing input like that isn't possible on the web but what about callback methods or listener methods the controller (i mean the controlling portion of a view) has to implement? another thing is to channelise comunication between the componenst (view - action - model ) through the controller (not the struts-type controller). if you do so, you can compose components more easily i'd say. DeeasS You should check out the documentation on Jakarta's site or purchase one of the many books about Struts. The O'Reilly book is IMHO not so great, but at least it does a good job explaining all of the features of Struts so at least I knew where to look. Matt - Original Message - From: Daniel Steudel [EMAIL
Re: Controller and Actions
Hi Daniel, I agree that you should have several actions for a single form. Fortunately, you can do this with Strut's DispatchAction. I make extensive use of in the project I am working on. I think everything you described in your 6 step scenario can be done with a combination of dispatch actions, the commons validator, and Strut's declarative exception handling. You should check out the documentation on Jakarta's site or purchase one of the many books about Struts. The O'Reilly book is IMHO not so great, but at least it does a good job explaining all of the features of Struts so at least I knew where to look. Matt - Original Message - From: Daniel Steudel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 07, 2003 11:19 AM Subject: Controller and Actions hi folks, i am working on a project right now for which i figured out struts to be perfectly suitable. but as i looked at it a little closer i saw some issues in the struts way i don't agree with. the main problem is that you think of a 1-to-1 relation between a form and an action (i think so 'cause you send a form to an (action-)controller that handles the params and passes them to one action). i would say there could be various actions on one form. you can have several submit-buttons each considered as a separate action. so the action to be performed should be determined by the value of the submit-button. the other thing i would expect is a 1-to-n relation between (what i refere to as controller) a controller that handles form-data and views. so the process would be: 1. user sends data to controller 2. controller sets up form-bean and tells the form-bean to validate it self 3. controller desides which action is to be performed behalf of the pressed submit-button 4. action returns or fails whith an exception 5.1. on success tell form-bean to reload data and pass controll to the appropriate view 5.2. on failure don't reload form and pass controll to the appropriate view (to be descided on the exception) 6. view sends new content the point i came to this suggestion is, i have to deal with barrier-free internet (eg lynx-compatible sites). shure you can change the location the form is sent to by using JavaScript but not so in lynx. so am i completely wrong with my point of view? i would luv to know. DeeasS -- Sind Sie auch schon drin?? Wir bieten Lösungen rund ums Internet ... Daniel Steudel @-traction GbR - Informations- und Kommunikationssysteme www.attraction.de Leiterweg 43 71254 Ditzingen Telefon (07156) 959202 Fax (07156) 959201 Mobil (0160) 7 774 271 - 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]
