Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
--- Ted Husted [EMAIL PROTECTED] wrote: On Thu, 25 Mar 2004 08:22:48 -0600, Joe Germuska wrote: As I've been saying (a lot, it seems, lately) on struts-user, I think there are legitimate Struts JSP tags like html:messages that are not best replaced by JSTL. Any time Struts tools put resources in special locations in request or session scope, I think it's nice to have tags which know the special locations, instead of expecting people to dig in and find them. And, for example with html:messages, the message-property filtering is a useful feature that would require a lot of verbose JSTL to achieve the same goal. Another way to go would be to provide a API object in the request that the tags, or any other presentation technology, could use to access framework resources. In this way, no one else would need to the various special locations, only where to find the API object. This was the idea behind the ConfigHelper, which we put together when the Velocity/Struts tools was first being discussed. http://tinyurl.com/yshnp It's never been updated for modules, but if it were, the idea would be that it would return references to whatever resources were appropriate to a given module. From the perspective of a presentation technology, regardless of its nature, the ConfigHelper (or ActionContext) would be Struts, in the same sense that a JBDC driver appears to be the database. (Adapter/proxy patterns.) On Thu, 25 Mar 2004 20:09:08 -0800 (PST), David Graham wrote: Are we really still kidding ourselves that the taglibs are currently supported? No committer actively takes care of them. No one in the community responded to Ted's invitation to support them. We've all moved onto JSTL, JSF, Velocity, XSLT, etc. While the rest of the world migrates to newer/better technologies, we're stuck supporting tags that fewer and fewer people actually use. I don't use them myself, but I still know people who do. And some of those people help pay the bills :) I have and will support them by applying patches that people provide, as we just did by adding the module parameter. Moving the taglibs to their own subproject (at last!) will make a significant difference, since what does or does not happen with opt-taglibs won't directly affect core. If we moved to a context-based architecture (as above), it would help decouple the taglibs from the core, so the subprojects could be more independent, and level the playing field for other technologies. And, I'd do whatever it took to refactor the classic taglibs. IMO, it's almost irresponsible to distribute logic:iterate with a Struts minimum Servlet level of 2.4 where c:forEach is available. Things may change this year, but last summer I was still finding people at very large corporations who hadn't migrated to servlet 2.3. So, c:forEAch was not available to them. Hopefully that will change this year, and we'll find nearly everyone has finally found the budget to upgrade. This is why tags like logic:iterate are still useful for Struts 1.x. However, since Struts 2.x will be based on at least Servlet 2.3 where c:forEach is available, IMO logic:iterate has no useful purpose. This applies to other Struts tags but iterate is a good example. David Though, that's not going to get us off the compatibility train. The next thing will be whether they support servlet 2.4 for Struts 2.x :) Pity the world can't download Tomcat and be done it :( :) -Ted - 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]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
--- Peter A. Pilgrim [EMAIL PROTECTED] wrote: snip bean:size we need a simple tag lib action for JSP 1.2 and JSTL 1.0 to get the size of java.uitl.Collection until there is widespread support JSP 2.0 JSTL 1.1 The current proposal is for Struts 2.0 to be based on Servlet 2.4/JSP 2.0 so we don't need bean:size either. David Investigation continue with rest of Beans taglib ... -- Peter Pilgrim Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - 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]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
--- Kris Schneider [EMAIL PROTECTED] wrote:
Nope. logic:match does substring matching.
IMO, any tag that does not interact with Struts' core resources should
live in the Jakarta Taglibs project. This allows non-Struts projects to
benefit from the functionality while freeing Struts to focus on its core
features. Substring matching doesn't sound like a Struts specific
operation.
David
Quoting Tim Chen [EMAIL PROTECTED]:
...
logic:match no equalivant in JSTL 1.0 but exists String functions
in
JSTL 1.1
...
logic:match equivalent is c:if test=${foo.bar eq 'hello
world'}xxx/c:if
-Tim
Peter A. Pilgrim wrote:
Craig R. McClanahan wrote:
Quoting Peter A. Pilgrim [EMAIL PROTECTED]:
Joe Germuska wrote:
Whether the classic and el taglibs are one chunk or two
isn't
hugely important to me either -- I would prefer that this
decision be
made by developers who've done more work on that code to date.
However, I did find that when I patched
o.a.s.t.html.JavascriptValidator, I had to go and make a
corresponding change in the EL version. I suspect that changes
in
those two libraries are going to track pretty tightly. But
like I
said, I'm not pushing for this; just floating it...
Is there any reason that the EL tags wouldn't replace the
existing
tags
for Struts 2.0? Also, IMO, many of the tags can be removed
entirely for
2.0 because they've been replaced by more powerful counterparts
in
the
JSTL.
As I've been saying (a lot, it seems, lately) on struts-user, I
think there are legitimate Struts JSP tags like html:messages
that are not best replaced by JSTL. Any time Struts tools put
resources in special locations in request or session scope, I
think
it's nice to have tags which know the special locations, instead
of
expecting people to dig in and find them. And, for example with
html:messages, the message-property filtering is a useful feature
that would require a lot of verbose JSTL to achieve the same
goal.
So, I'd suspect even in 2.0 there will be arguments for a small
Struts taglib. But I am 100% on board with pushing people to use
the JSTL where it is really equivalent.
Joe
All
+1 Some Struts tags are indeed very great.
I also found the original html:options tag to really be useful
last year
at RBS generating HTML OPTIONS elements. Repeating the same thing
JSTL
c:if or c:when statment is verbose. If there not EL equivalent
of html:options, it will be on my todo list.
It's not just an issue of JSTL and EL-enabling Struts tags. JSF,
for
example,
has more powerful equivalents of html:options (f:selectItems --
among other
fancy things you can make it create hierarchical option lists by
emitting
optgroup very easily), as well as equivalents for html:messages
(h:message for a single field, h:messages for the general
messages).
So I guess what you are, in fact, saying that we should be using
JavaServer
Faces or looking to use it, for 2004/2005. One question are the JSF
tag
actions h:message and h:messages dependent on a JSF
implementation
or can they be used standalone?
Perhaps that is what we need to do as Developer. Write some kind of
feature
compatibility matrix.
Old Tag:New Tag : Description
==
html:messagesh:messages extends original behaviour and
can make it create hierarchical
option lists by emitting optgroup.
I presume there are some other Struts HTML tags that are
favourites
with
other people too.
Likewise, the Struts-Faces integation library has JSF-componetized
equivalents
for some of the Struts HTML tags (including messages) to make it
easier to use
as a drop-in replacement. I'd be interested in hearing
specifically
what other
favorite tags their are, to make sure that equivalent
functionality is
available to a JSF-based user of Struts.
logic:iterate superceded by JSTL
logic:forward superceded by JSTL
logic:redirect superceded by JSTL
logic:equal superceded by JSTL
logic:notEqual superceded by JSTL
logic:greaterThan superceded by JSTL
logic:greaterEqual superceded by JSTL
etc
logic:match no equalivant in JSTL 1.0 but exists String functions
in JSTL 1.1
bean:define replace with c:set
bean:size we need a simple tag lib action for JSP 1.2 and JSTL
1.0
to get
the size of java.uitl.Collection until there is widespread
support JSP 2.0 JSTL 1.1
Investigation continue with rest of Beans taglib ...
--
Peter Pilgrim
Craig
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
Re: Counting down to the 1.2.1 release (was RE: Making Struts Build Easier)
--- Martin Cooper [EMAIL PROTECTED] wrote: On Thu, 25 Mar 2004, [EMAIL PROTECTED] wrote: -Original Message- Do we want to wait for a Validator 1.1.2, or roll it with 1.1.1? I just fixed a show stopper bug today in validator in CVS and made an accompaning change in Struts CVS. I won't be able to be RM to for Validator until Mid April, so we need a volunteer. Otherwise, we'll need to roll back the JavaScriptTag.java and validator-rules.xml in struts to use validator 1.1.1. I can probably do the RM thing for Validator if someone else (David?) can do the doc and release note updates. Just let me know when we're ready to roll and I can take it from there. It looks like the RELEASE-NOTES.readme just points to the online Maven generated change log. If that's how we're doing release notes then all we need is to update the website and check out a few issues that came up on commons-user recently. I can probably get the docs ready this weekend. Thanks for volunteering to do the release, I've been swamped lately. David -- Martin Cooper - 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] __ 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]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
--- Arron Bates [EMAIL PROTECTED] wrote: --- Joe Germuska [EMAIL PROTECTED] wrote: Whether the classic and el taglibs are one chunk or two isn't hugely important to me either -- I would prefer that this decision be made by developers who've done more work on that code to date. However, I did find that when I patched o.a.s.t.html.JavascriptValidator, I had to go and make a corresponding change in the EL version. I suspect that changes in those two libraries are going to track pretty tightly. But like I said, I'm not pushing for this; just floating it... Is there any reason that the EL tags wouldn't replace the existing tags for Struts 2.0? Also, IMO, many of the tags can be removed entirely for 2.0 because they've been replaced by more powerful counterparts in the JSTL. As I've been saying (a lot, it seems, lately) on struts-user, I think there are legitimate Struts JSP tags like html:messages that are not best replaced by JSTL. Any time Struts tools put resources in special locations in request or session scope, I think it's nice to have tags which know the special locations, instead of expecting people to dig in and find them. And, for example with html:messages, the message-property filtering is a useful feature that would require a lot of verbose JSTL to achieve the same goal. So, I'd suspect even in 2.0 there will be arguments for a small Struts taglib. But I am 100% on board with pushing people to use the JSTL where it is really equivalent. Yep, notice I mentioned removing many tags and not *all* tags :-). There are certainly tags we should keep around but I just don't see a need for most of the logic and bean tags in Struts 2.0. Widely known is that the Struts tags sit under the nested tags. And that JSTL and EL cannot fill the shoes of the nested tags. If Struts doesn't want to support the taglibs, then thats a separate issue. Are we really still kidding ourselves that the taglibs are currently supported? No committer actively takes care of them. No one in the community responded to Ted's invitation to support them. We've all moved onto JSTL, JSF, Velocity, XSLT, etc. While the rest of the world migrates to newer/better technologies, we're stuck supporting tags that fewer and fewer people actually use. IMO, it's almost irresponsible to distribute logic:iterate with a Struts minimum Servlet level of 2.4 where c:forEach is available. David But for the nested tags to do what they do, they need the Struts tags including all the logic tags. I don't think that we'd drop all the tags, but as for letting some go that aren't in JSTL et al... -1 Btw: I've thought long and hard about how to get the nested concept into JSTL (to remove the dependancy on Struts), but it's just not a fit. The nested tags manage things as much for the trip back to the Struts servlet as much as making the viewing layout code easier. Nested tags live on Struts. I've watched these conversations, but just don't have the time for all the backround study it'd take to make worthy comment. But for the tags, things haven't changed. So, apologies for just piping in on familiar topics. I probably needed a pair of them fantastic gloves already mentioned... Cheers, Arron. David Joe - 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]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
--- Joe Germuska [EMAIL PROTECTED] wrote: snip Hope that helps. If we stick to our guns about avoiding dependencies on unreleased software, this won't come up again... it's not Maven's fault! Commons Validator is a special case because it's mostly used with Struts. The standalone user population is significantly smaller than the Struts Validator users. We decided that to get true testing of new Commons Validator versions we needed to distribute it with Struts builds. David 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]
Re: Separate Tiles From Struts?
When I first started poking around Jakarta, Struts and Tiles were separate projects and were in the process of being merged. I'm not sure why they were joined but Tiles wasn't a commons component, it was another Jakarta project. David --- Matt Raible [EMAIL PROTECTED] wrote: Anyone care to educate me on why Tiles is part of Struts (and not commons-tiles?). I'd like to respond to the following post (contents pasted below) with an educated reply. https://sourceforge.net/forum/message.php?msg_id=2488961 snip On the occasion: Do you happen to know why Tiles was integrated into the Struts codebase as of Struts 1.1, rather than kept as separate component with Struts integration? I've been wondering about this for quite a while... Tiles isn't really tied to Struts in a technical manner, as we see in our usage with Spring. So why is every other piece of reusable logic a Commons component but not Tiles? I'd really like to see Tiles being factored out of the Struts codebase again, possibly before the Struts 2.0 timeframe. /snip Thanks, Matt - 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]
RE: Counting down to the 1.2.1 release (was RE: Making Struts Build Easier)
--- Derek Richardson [EMAIL PROTECTED] wrote: I was recently told on the Commons list that Validator 1.1.1 is alpha-only. Is this not the case? How can a production 1.1.2 be released before 1.1.1 is production-ready? Using the httpd style versioning scheme, if 1.1.1 isn't production ready when it's cut then it will never be moved to production status. 1.1.2 would start out as alpha and potentially be labeled production if it successfully fixed the issues in 1.1.1. Note that Struts 1.2.1 isn't production either so including an alpha validator with it is no problem IMO. David -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 12:55 PM To: Struts Developers List Subject: Re: Counting down to the 1.2.1 release (was RE: Making Struts Build Easier) --- Ted Husted [EMAIL PROTECTED] wrote: On Wed, 24 Mar 2004 09:03:46 -0700, Matt Raible wrote: -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Well, did-ja have anything to add to the list, Matt? :) Nope - release, release!! The ones we have are resolvable, but, I'm thinking Martin has something up his sleeve yet ... Meanwhile, there's still the issue of our dependency on the Validator nightly http://tinyurl.com/394ht and how far we are from another Validator release ... There have been a few additions since Validator 1.1.1 and IMO 1.1.2 can be cut anytime. David -Ted. - 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] - 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]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
--- Joe Germuska [EMAIL PROTECTED] wrote: This makes it easy for the apps to extend a common Maven project.xml. We could still offer a single zip/tarball with all the applications WARs within. /apps - examples - mailreader - tilesPortal - userdb Now that I say it, the same approach might conceivably be used for el, taglibs, and faces. /taglibs - classic - el - faces But, the problem with binding the taglib packages too closely is that they would all have to be distribution-ready before we did a new roll of any. So, an ongoing refactoring in the classic taglibs could block a quick release of the faces taglib. I really want to try and avoid the hydraulic dependencies of the 1.1 era, where we had to have everything ready to release all at once :( I think you've already made the case for not pushing all the taglibs things together just because they are the same technology. struts-faces should be its own thing, I'm pretty certain. Joe suggested combining opt-el with opt-taglibs, though we'd have to be careful which dependencies are used to build what. (Which makes me think they are not the same deliverable. el might just have a dependency on taglib.) I don't actually use either one much myself, so I have no preferences myself. Whether the classic and el taglibs are one chunk or two isn't hugely important to me either -- I would prefer that this decision be made by developers who've done more work on that code to date. However, I did find that when I patched o.a.s.t.html.JavascriptValidator, I had to go and make a corresponding change in the EL version. I suspect that changes in those two libraries are going to track pretty tightly. But like I said, I'm not pushing for this; just floating it... Is there any reason that the EL tags wouldn't replace the existing tags for Struts 2.0? Also, IMO, many of the tags can be removed entirely for 2.0 because they've been replaced by more powerful counterparts in the JSTL. David 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]
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]
Re: [PROPOSAL] Struts infrastructure changes
--- Martin Cooper [EMAIL PROTECTED] wrote: The following is a set of proposed changes to the Apache infrastructure to accommodate the Struts move to an Apache top level project. The idea is to come up with a single agreed-upon set of changes that we can submit to the infrastructure folks as a single request, rather than submitting each one piecemeal. Your feedback is appreciated. Mailing Lists New mail domain: struts.apache.org The following lists are standard for an Apache TLP: user@ dev@ cvs@ (usually forwarded to dev@) pmc@ Moderator: Ted Husted (same as today) Existing subscribers need to be migrated. Old list addresses should be forwarded for some period of time. Web Site New virtual host: struts.apache.org Redirect from jakarta.apache.org/struts for some period of time. Writeable by group: struts (see below) Wiki New wiki: wiki.apache.org/struts Migrate pages from: StrutsProjectPages on old wiki (nagoya) Unix Group New group: struts Members: (Struts PMC members) Source Control Old CVS repo: jakarta-struts New CVS repo: struts Optional: Move to Subversion (IMO, not now, but we can discuss.) The tool support for subversion is not nearly as good as it is for cvs yet. It's probably a good idea to switch in the long term but I don't see any immediate benefits. Bug Database Optional: Move to Jira (IMO, now's as good a time as any.) I've expressed my opposition to this on commons-dev so I'll sum up my points here: 1. For me, part of the fun of developing OSS is using and supporting other OSS projects. Jira is not open source so it takes some of the fun away. 2. We've been fairly consistent with tracking corresponding bugzilla bug numbers in the cvs commit messages. This has proved extremely valuable when researching and fixing bugs. I would hate to lose that meta data. 3. I have no problem with bugzilla so it's a, if it isn't broken, don't fix it situation. David One other thing is that we'll want to get external mail archivers to switch to the new mailing lists once those are set up. I'm not clear on whether the infrastructure folks arrange that or we need to do it ourselves, but I'll ask when I submit the above. Anything else I missed? (There are a lot of internal changes we'll want to make as well, but I'm not trying to address those here.) -- Martin Cooper - 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]
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
--- Joe Germuska [EMAIL PROTECTED] wrote: At 2:48 PM -0500 3/14/04, Ted Husted wrote: I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. IMHO, the quickest way to sort out what we need to do with the Struts-Chain RequestProcessor is to get it out there as the nightly build. [Many hands make light work ;)] So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do anything resembling new development against the HEAD (1.3). I might do something like this over the weekend, depending on my time (then again, I may not at all!) But if I did, I'd want to see if anyone had any strong feelings, or fixes they thought they'd like to get in before a branch, or... ? Or should all of this wait until we get the move to struts.apache.org settled? I'm assuming we'll reorganize CVS as part of that, into struts-core, struts-taglib, etc... Speaking of that, can we/should we do anything to preserve CVS logs if we move files? Or will we start fresh? I think if we move the actual CVS files it will all be preserved, but I've never tried that. I have used the CVS log history many times when researching/fixing bugs so I'm very much against losing this data. David I'm interested in getting the Struts Chain stuff mainstreamed, but like I said, this may very well not be the weekend I start on it. In any case, I figured a branch would be cause for a little bit of discussion amongst committers. 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! Mail - More reliable, more storage, less spam http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL validation - anyone using it?
That's simply the result of another testcase that proves exception handling works as documented. Validator is logging the exception and passing it out to the caller. David --- Adam Hardy [EMAIL PROTECTED] wrote: On 03/13/2004 07:46 AM [EMAIL PROTECTED] wrote: From: Adam Hardy I provide URL validation on a page which saves links for users. I put together the latest build of commons-validator (1.1.2) and struts (1.2) to see what the URL validation is like. The class for server-side validation is in place, but the javascript doesn't exist. It works very strictly, too strictly for me. Most users will want to save links such as http://www.google.com http://jakarta.apache.org/ http://marc.theaimsgroup.com/?l=struts-userm=105511005106573w=2 This is definately a bug and they should have passed, I haven't run the unit tests against it in some time do they still pass ? My guess is that it might not be expecting the '/' after the domain name. This would probably only require a small tweak to the regular expression thats used. I would apply any patches that were submitted I'm running the tests on the Validator via ant and I get this exception straight away. I assume that the bad date is a test date that is meant to fail - but I can't figure out the reason why junit is falling over. I've only got brief experience with junit and I'm not finding the relevant code. Thanks for any pointers, Adam [echo] Running tests ... [java] . [java] ..F...F...ValidatorTest.formatDate() - Unparseable date: 2/30/1999 [java] . [java] Mar 15, 2004 9:49:58 AM org.apache.commons.validator.ValidatorAction executeValidationMethod [java] SEVERE: Unhandled exception thrown during validation: RUNTIME-EXCEPTION [java] java.lang.RuntimeException: RUNTIME-EXCEPTION [java] at org.apache.commons.validator.TestValidator.validateRaiseException(TestValidator.java:53) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] at java.lang.reflect.Method.invoke(Method.java:324) [java] at org.apache.commons.validator.ValidatorAction.executeValidationMethod(ValidatorAction.java:570) -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validator javascript taglib
The typical use case is to generate the static javascript once and store it in a file. I don't understand why you would need to generate the static javascript multiple times. David --- Adam Hardy [EMAIL PROTECTED] wrote: I have put the javascript taglib in its own JSP so that I can call it up with this: script src=staticjavascript.do type=text/javascript The result of staticjavascript.do is meant to be pure javascript, like in a javascript file, without script HTML. If the script tags are there, then the browser can't read the javascript. I changed the JavascriptValidatorTag source to get scriptLanguage=false to turn off the addition of these tags. It looks like the scriptLanguage attribute is only for putting the language=Javablah in the HTML though. I could put in another attribute, e.g. enclosingScriptTags. Would you like me to submit an enhancement? Adam -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts as an Apache Top Level Project
+1 TLP +1 Craig as VP David --- Martin Cooper [EMAIL PROTECTED] wrote: Following up on a brief thread on this list in December [1], Craig, Ted and I have put together a draft resolution to the board of directors [2], along with a cover letter [3], that would promote Struts to an Apache top-level project (TLP). The main reasons for moving to a TLP are described on the wiki [4]. In Craig's words, The short answer, though, is we will be in charge of our own releases (currently, the Jakarta PMC is the only body legally recognized to vote on releases of *any* software under Jakarta). In practice, we can really just continue doing what we've always done. As most of you are no doubt aware, several Jakarta sub-projects have already made the transition to TLPs, including Ant, Avalon, Gump, James, Log4J, Maven, OJB, and Torque. Most Jakarta PMC members seem to be in favour of the migrations, largely because a single PMC cannot possibly oversee a code base the size of all of Jakarta. If you're OK with Struts being a top-level Apache project, please respond to this thread with either a +1 or +0. Otherwise, please reply with your concerns. When we previously discussed this, it did not seem like anyone was opposed to the idea, but if anyone is, now is the time to speak up. The resolution as drafted lists the Struts Committers who could reasonably be considered active at this time. Of course, we should not put anyone on the PMC without their buy-in, so the final resolution would only list the Committers who responded to the Vote with a +1 or +0. The draft resolution also leaves the name of the Vice President blank. Craig seems like the logical candidate, and is willing to act in this capacity, but we wanted the VP selection to be a community decision. So, please also respond with your nomination for Vice President, Apache Struts. Here's my +1 on the resolution as drafted, and my +1 for Craig as Vice President. -- Martin Cooper [1] http://nagoya.apache.org/eyebrowse/SearchList?listId=[EMAIL PROTECTED]searchText=%22Why+you+*want*+to+be+on+the+PMC%22defaultField=subjectSearch=Search [2] http://www.apache.org/~martinc/struts/tlp/resolution.html [3] http://www.apache.org/~martinc/struts/tlp/cover.html [4] http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASL 2.0
I attempted to apply the patches but Eclipse wouldn't cooperate. I don't have any other cvs tools on my windows box, which is the only one with Struts development setup at the moment. David --- Ted Husted [EMAIL PROTECTED] wrote: Would anyone have a chance to apply Paul's patch this afternoon? http://issues.apache.org/bugzilla/show_bug.cgi?id=27137 I'm out of town and this might be a bear for me to commit over a 28.8 modem connection :) Otherwise, I'll try to do it later tonight. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Validation working, but not stopping action from processing
--- Matt Raible [EMAIL PROTECTED] wrote:
It's one of those days... As soon as I send something to this list, I
figure it out. The problem was my validationFailed forward was not
resetting the action parameter for my dispatch action and it was
hitting save even when it failed. I change the input attribute to
edit (removing the validationFailed forward) and it solved my problem.
If you're reading these - thanks for putting up with me. ;0)
I try to read all validator related posts and yours have been quite
entertaining ;-). Thanks for testing 1.2.0!
David
Matt
-Original Message-
From: Matt Raible [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 28, 2004 1:56 PM
To: '[EMAIL PROTECTED]'
Subject: Validation working, but not stopping action from processing
I'm using the 1.2.0 test build on Windows XP.
I have the following XDoclet-generated action-mapping:
action
path=/savePerson
type=org.appfuse.webapp.action.PersonAction
name=personForm
scope=request
input=validationFailed
parameter=action
unknown=false
validate=true
forward
name=validationFailed
path=/editPerson.do
redirect=false
/
forward
name=edit
path=.personDetail
redirect=false
/
/action
When I click on a button to save my form, the validation
kicks in - but it let's my Action continue to execute. I
thought that any validation errors were supposed to call
mapping.getInputForward()? Is that correct? I'm stumped.
Here's my save() method:
public ActionForward save(ActionMapping mapping, ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
if (log.isDebugEnabled()) {
log.debug(Entering 'save' method);
}
// Extract attributes and parameters we will need
ActionMessages messages = getMessages(request);
PersonForm personForm = (PersonForm) form;
boolean isNew = (.equals(personForm.getId()));
if (log.isDebugEnabled()) {
log.debug(saving person: + personForm);
}
// Exceptions are caught by ActionExceptionHandler
PersonManager mgr = (PersonManager) getBean(personManager);
personForm = (PersonForm) mgr.savePerson(personForm);
// add success messages
if (isNew) {
messages.add(ActionMessages.GLOBAL_MESSAGE,
new ActionMessage(person.added,
personForm.getFirstName() + +
personForm.getLastName()));
request.getSession().setAttribute(Globals.MESSAGE_KEY, messages);
return mapping.findForward(mainMenu);
} else {
messages.add(ActionMessages.GLOBAL_MESSAGE,
new ActionMessage(person.updated,
personForm.getFirstName() + +
personForm.getLastName()));
saveMessages(request, messages);
return mapping.findForward(edit);
}
}
The validation routes the user back to the form, but it also
calles mgr.savePerson and puts the message in the requestion.
So on my page, I end up with the following messages:
'First Name' is a required field.
'Last Name' is a required field.
Information for has been updated successfully.
Hopefully I'm just banging my head against the wall and it's
something simple...
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is TagUtils instance final?
--- Niall Pemberton [EMAIL PROTECTED] wrote: I don't understand why the instance of TagUtils has been made final: private static final TagUtils instance = new TagUtils(); It's simply following the Singleton pattern. I have no problems with changing this to allow clients to instantiate a TagUtils instance directly. David Isn't the logic behind having an 'instance' of TagUtils so that if someone want to change an aspect of TagUtils behaviour they can extend it and override a particular method? Otherwise why not just have a bunch of static methods in TagUtils? Does anyone have opinions on changing this so that TagUtils implementation could be customized? Niall __ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
--- Paul Sundling [EMAIL PROTECTED] wrote: One possible question is from the new boilerplate: Copyright [] [name of copyright owner] Is it just The Apache Software Foundation, like in the 1.1 license? That would be my guess. I think that's correct. The documentation uses that string in the examples. David The one reference to Struts in the previous license version was related to the section on use of the trademark name. I think that's dealt with in a more general way in the new license. Paul Sundling David Graham wrote: The exact license details can be found here: http://www.apache.org/dev/apply-license.html David --- Karr, David [EMAIL PROTECTED] wrote: Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan At 1:49 PM -0600 2/20/04, Joe Germuska wrote: Just a few things: * What about the new Apache license? Technically, it doesn't need to change if we release before March 1st, but we're mighty close to that, so perhaps we should switch now? +1 from me too; wasn't someone offering to do it a few weeks ago? I should amend this: + 0 from me; I don't have time to do it now, and probably won't soon enough that I'd want to delay 1.2.0 until it gets done. 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] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - 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] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
Thanks for volunteering! I will review and apply the patch once it's entered in bugzilla. David --- Paul Sundling [EMAIL PROTECTED] wrote: David Karr emailed me, so I'll take care of the licenses this weekend. I have a social engagement today, so I'll take care of it on sunday. Paul Sundling David Graham wrote: --- Paul Sundling [EMAIL PROTECTED] wrote: One possible question is from the new boilerplate: Copyright [] [name of copyright owner] Is it just The Apache Software Foundation, like in the 1.1 license? That would be my guess. I think that's correct. The documentation uses that string in the examples. David The one reference to Struts in the previous license version was related to the section on use of the trademark name. I think that's dealt with in a more general way in the new license. Paul Sundling David Graham wrote: The exact license details can be found here: http://www.apache.org/dev/apply-license.html David --- Karr, David [EMAIL PROTECTED] wrote: Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan At 1:49 PM -0600 2/20/04, Joe Germuska wrote: Just a few things: * What about the new Apache license? Technically, it doesn't need to change if we release before March 1st, but we're mighty close to that, so perhaps we should switch now? +1 from me too; wasn't someone offering to do it a few weeks ago? I should amend this: + 0 from me; I don't have time to do it now, and probably won't soon enough that I'd want to delay 1.2.0 until it gets done. 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] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - 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] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - 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] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
--- Martin Cooper [EMAIL PROTECTED] wrote: On Fri, 20 Feb 2004, Ted Husted wrote: Assuming it was all right with everyone, I'm setting the freeze date for 1.2.0 for tomorrow (Saturday) night. I'm updating the release plan. There are still a lot of enhancement patches that we haven't applied, but I think those can wait for later in the 1.2.x series. I do intend to start marching down that list and either accepting or declining whatever patches people have submitted. So, I'm commenting out that section for the purpose of this release. All the other criteria have been met, and I believe we are ready to go. Martin, would you be able to take it from there, or is there any thing else I can do? Just a few things: * What about the new Apache license? Technically, it doesn't need to change if we release before March 1st, but we're mighty close to that, so perhaps we should switch now? +1 * There was a brief discussion not too long ago about whether we should be building this release against released versions of Commons components or the nighlies. Since, in theory at least, this release could be promoted to a Final release, I assume the former? At this point I don't see any reason to ever build against commons nightlies unless we're using some unreleased feature. IMO, Struts shouldn't use unreleased commons features because we'll end up in a 1.1 situation where we're waiting for commons releases. The exception would be for alpha releases like Validator where it only needs testing before getting a GA label. Several of the Commons components we depend on have released since we last did, so we may want to update the versions in our dependency list. Collections is a particularly ugly situation. Do we upgrade to 3.0 and break existing Struts apps requiring 2.x? Or, do we stay at 2.x and break apps needing 3.0? David * The Cactus tests won't run for me, for some reason. When I start the tests, everything looks fine as it starts up, but then it just sits there doing nothing. They used to work, but I can't recall what I might have changed to break it. Anyone have any ideas? Obviously, I don't want to create a release and not be able to run the tests! -- Martin Cooper -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] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] 1.2.0 Release Plan
The exact license details can be found here: http://www.apache.org/dev/apply-license.html David --- Karr, David [EMAIL PROTECTED] wrote: Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan At 1:49 PM -0600 2/20/04, Joe Germuska wrote: Just a few things: * What about the new Apache license? Technically, it doesn't need to change if we release before March 1st, but we're mighty close to that, so perhaps we should switch now? +1 from me too; wasn't someone offering to do it a few weeks ago? I should amend this: + 0 from me; I don't have time to do it now, and probably won't soon enough that I'd want to delay 1.2.0 until it gets done. 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] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: html:text disable attribute invalid.
I must be missing something. What in that link indicates disabled is not valid for a text input? David [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://www.w3.org/TR/html4/interact/forms.html#h-17.4 Looking at the above reference it appears that the disable attribute is illegal for type=text, is this correct ? If so should we remove this attribute, as opposed to deprecating it ? -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online
RE: string concatenation
Struts has many dependencies already and I'd like to avoid adding one with
lang. Why not just size a large StringBuffer and trade memory for speed?
David
--- Martin Cooper [EMAIL PROTECTED] wrote:
Rather than add a new string utility class to Struts, which isn't really
where it should belong, I think we'd be better off just using this:
http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/StringUti
ls.html#join(java.lang.Object[])
Alternatively, you could suggest (on the commons-dev list) adding a
variation of your StringHolder class, based on the join() method above,
to
Commons Lang.
--
Martin Cooper
-Original Message-
From: nishant kumar [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 14, 2004 5:46 PM
To: [EMAIL PROTECTED]
Subject: string concatenation
hi,
I have a performance tuning suggestion which i think will greatly
impact the performance of struts html tags.
String concatenation using StringBuffer is definitely much
better than
using the plus operator but there are scenarios where there are much
better ways than using StringBuffers. Actually struts html tags fall
in
those scenarios.
So let me give you an example. this is the code from
renderFormStartElement method of FormTag.
StringBuffer results = new StringBuffer();
results.append(form);
results.append( name=\);
results.append(beanName);
results.append(\);
results.append( method=\);
results.append(method == null ? post : method);
results.append(\ action=\);
str = results.toString();
pageContext.getOut().write(str);
Now lets list the issues with this.
1. first presizing this buffer is quite difficult (avoided in this
case). here the buffer starts with size 16 and doubles each time the
size is exceeded. This causes unnecessary creation of new char arrays
and redundant copy of data whenever resizing happens.
2. whenever append is called data is copied from the passed string to
the end of stringbuffer.
3. finally the whole concatenated data is again copied into another
string.
4. and then in the end this string is written to a writer, another
copy,
which is the only copy required.
so even if you had presized the stringbuffer correctly, you have
copied
the same data thrice instead of just once. And you also create two NOT
needed objects.
so here is the solution i propose. have a class holding an array of
Strings and keep appending strings to this array and finally print
this
array to the writer. something like this.
private String[] data = new String[256];
private int size = 0;
public StringHolder append(String str){
ensureCapacity(this.size + 1);
this.data[this.size++] = str;
return this;
}
public void writeTo(Writer out) throws IOException{
for (int i = 0; i this.size; i++){
if (this.data[i] != null){
out.write(this.data[i]);
}
}
}
this way only the last copy takes place and you also avoid creating so
much garbage.
i have attached StringHolder class which does the above task and also
the FormTag after making necessary modification to fit in this class.
From the code of FormTag you can see that you need to make quite few
changes to get great benefit.
i have also attached a better implementation of
ResponseUtils.filter(String) method. the logic is on the same lines as
above.
thanks,
nishant
--
nishant kumar [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: string concatenation
--- Martin Cooper [EMAIL PROTECTED] wrote:
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 15, 2004 1:01 PM
To: Struts Developers List
Subject: RE: string concatenation
Struts has many dependencies already and I'd like to avoid adding one
with
lang. Why not just size a large StringBuffer and trade memory for
speed?
We already have a dependency on Lang, albeit indirectly, so why not take
advantage of it?
I don't believe that's correct. What component has a dependency on lang
that we use? We need it for testing but it's not included in the Struts
distro.
Frankly, I disagree with the push I see from some folks (including Craig
on
commons-dev recently) to reduce dependencies between components by
duplicating functionality. The whole point of Commons is to avoid
duplication, so why are people pushing back against using the successful
components that we helped create here in Struts?
In the cases I know of the usage of other components is very limited and
not needed. Examples are Digester and BeanUtils using one class from
collections in very few places when we would be better off dropping
collections and using standard Java collections.
David
--
Martin Cooper
David
--- Martin Cooper [EMAIL PROTECTED] wrote:
Rather than add a new string utility class to Struts, which isn't
really
where it should belong, I think we'd be better off just using this:
http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang
/StringUti
ls.html#join(java.lang.Object[])
Alternatively, you could suggest (on the commons-dev list) adding a
variation of your StringHolder class, based on the join() method
above,
to
Commons Lang.
--
Martin Cooper
-Original Message-
From: nishant kumar [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 14, 2004 5:46 PM
To: [EMAIL PROTECTED]
Subject: string concatenation
hi,
I have a performance tuning suggestion which i think will greatly
impact the performance of struts html tags.
String concatenation using StringBuffer is definitely much
better than
using the plus operator but there are scenarios where there are
much
better ways than using StringBuffers. Actually struts html tags
fall
in
those scenarios.
So let me give you an example. this is the code from
renderFormStartElement method of FormTag.
StringBuffer results = new StringBuffer();
results.append(form);
results.append( name=\);
results.append(beanName);
results.append(\);
results.append( method=\);
results.append(method == null ? post : method);
results.append(\ action=\);
str = results.toString();
pageContext.getOut().write(str);
Now lets list the issues with this.
1. first presizing this buffer is quite difficult (avoided in this
case). here the buffer starts with size 16 and doubles each time
the
size is exceeded. This causes unnecessary creation of new char
arrays
and redundant copy of data whenever resizing happens.
2. whenever append is called data is copied from the passed string
to
the end of stringbuffer.
3. finally the whole concatenated data is again copied into
another
string.
4. and then in the end this string is written to a writer, another
copy,
which is the only copy required.
so even if you had presized the stringbuffer correctly, you have
copied
the same data thrice instead of just once. And you also create two
NOT
needed objects.
so here is the solution i propose. have a class holding an array
of
Strings and keep appending strings to this array and finally print
this
array to the writer. something like this.
private String[] data = new String[256];
private int size = 0;
public StringHolder append(String str){
ensureCapacity(this.size + 1);
this.data[this.size++] = str;
return this;
}
public void writeTo(Writer out) throws IOException{
for (int i = 0; i this.size; i++){
if (this.data[i] != null){
out.write(this.data[i]);
}
}
}
this way only the last copy takes place and you also avoid
creating so
much garbage.
i have attached StringHolder class which does the above task and
also
the FormTag after making necessary modification to fit in this
class.
From the code of FormTag you can see that you need to make quite
few
changes to get great benefit.
i have also attached a better implementation of
ResponseUtils.filter(String) method. the logic is on the same
lines as
above.
thanks,
nishant
--
nishant kumar [EMAIL PROTECTED
Re: deprecate org.apache.struts.taglib.html.ErrorsTag?
--- Joe Germuska [EMAIL PROTECTED] wrote: There's been quite a bit of confusion on the struts-user list this week about the relationships between ActionErrors, ActionMessages, html:errors, and html:messages. Is there any reason not to deprecate org.apache.struts.taglib.html.ErrorsTag and slate it for future removal, to remove one more piece from the puzzle? The errors tag provides a way to display a message in one line instead of the 3 or more required by the messages tag. So, I'm -1 on deprecating errors but I do think we should come up with a way to get the best of both into one tag. David 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: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Browser-specific attrs for html tags (was: [Bug 26795])
--- Joe Germuska [EMAIL PROTECTED] wrote: At 9:28 AM -0800 2/9/04, Hubert Rabago wrote: This probably won't be the last request for an attribute which turns out to be browser specific. Perhaps the html taglib can include some mechanism to allow developers to add other attributes. You can always subclass the tag and change the TLD file. This seems like a much simpler solution to me. +1 And for the record I am a big -1 on changing Struts tags to support non-standard HTML. IMO, if you want to support just IE (which is invariably the cause for these type of requests), you shouldn't get any help from Struts. David 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: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clean Up conf/share
--- [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is there any reason we can't delete: struts-config_1_0.dtd -- Users should upgrade to at least Struts 1_1 dtd tiles-config.dtd -- This is for pre struts tiles. validation_1_1.dtd -- This moved to commons-validator pre struts 1.1 validator-rules_1_1.dtd -- This moved to commons-validator pre struts 1.1 web-app_2_2.dtd -- Don't know why we carry around web-app dtd's web-app_2_3.dtd I agree that most of these should be removed but I think the webapp dtds are used when Struts uses Digester to parse web.xml. David -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
--- Niall Pemberton [EMAIL PROTECTED] wrote: Graham OK, I decided to look further into your suggestion, but didn't get very far and I think its because mask doesn't work. I know it works because I use it in my apps :-). I started with a simple expression of [\d,]* to validate that the input only contains numbers or a comma. Whatever I input though validator always passed it as valid. ORO's test applet is really helpful when testing regexs. Try putting ^ at the front and $ at the end of the pattern. ORO seems to need these to work properly unlike Java 1.4 regexs. David Looking into validator it uses Perl5Util.match(pattern, value) This utility uses the Perl5Matcher.contains(value, pattern) method which only checks that the value contains the pattern - not that matches (it says so in the Perl5Util documentation). Isn't this the wrong thing to do - shouldn't validator be using the Perl5Matcher.matches(value, pattern) method. I had a look at commons validator test thinking this must be tested for and I must be mis-understanding it - but mask seems to be the one thing there are no tests for - and there don't seem to be any in struts either for FieldChecks.validateMask()) Anyway, am I right - is this a bug, or am I just using it wrongly? Niall P.S. If I am right, then it implies no one is using mask and I think thats an argument for my simpler number validation. - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 Thanks Niall Robert Leland wrote: So using mask won't work ? (my syntax below is probably not correct) field property=amount depends=required,mask arg0 key=sale.amount / var var-namemask/var-name var-value\d,\d\d0\:\(\d,\d\d0\)/var-value /var /field I need to validate numbers which are formatted and have posted a patch to bugzilla which enhances validator the existing number validations to do this. This patch allows an optional numberPattern variable to be specified for the existing byte, short, integer, long, float and double validations. For Example: field property=amount depends=required,integer arg0 key=sale.amount / var var-namenumberPattern/var-name var-value#,##0:(#,##0)/var-value /var /field If the pattern is specified, then java.text.DecimalFormat is used to parse the number and check if it is valid (catering for Locale). I have also posted a patch to add a new section the Validator User Guide which describes all the standard suppiled validations and shows examples of usage, including using the new numberPattern variable. Thanks in advance for any feedback. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
--- Niall Pemberton [EMAIL PROTECTED] wrote: I agree with both of you! Not having JavaScript implementation shouldn't be an issue - if people want it then someone would come up with it. However, because the approach I took was to modify the exiting number validations (byte, short, long, integer, float, double) then it means that where there is JavaScript validation (not all of them seem to have) these will now fail if a pattern is used, because they don't take into account the pattern. I would put some additional time on this, if a committer was willing to implement it. But since David Graham has said he is -1 on this, doesn't that effectively make this enhacement request dead? There wasn't a vote so my -1 is more of an indication that I don't like the idea. Mask is the most flexible validation that allows many things like formatted number validations. If you can't get your regex to work you might try writing a custom validation action that uses DecimalFormat. If that works you could post a patch to bugzilla. I encourage you to get the regex to work though because it will make life easier in the long run :-). David Niall Richard Hightower wrote ... I agree about that sticky wicket, but There are already validation rules that do not have client-side support (via JavaScript). At least this type of stuff would be nice in the contrib area. Ted Husted wrote ... In principle, I'd agree with Rick, since these type of patterns are the standard way of doing this sort of thing on the Java platform. But, the sticky wicket is lack of a JavaScript implementation. People would expect an implementation like this to include client-side support, as the other validations do. -Ted. On Thu, 15 Jan 2004 20:54:17 -0700, Richard Hightower wrote: Niall, I don't get a vote. I am not a committer. But if I did I would vote +1 on the idea (I have not studied your implementation). I can write regular expressions in a pinch, but why not support all of the java.text.* in the validator rules (including currencey). I like the idea. Rick Hightower Developer Struts/J2EE training -- http://www.arc-mind.com/strutsCourse.htm Struts/J2EE consulting -- http://www.arc- mind.com/consulting.htm#StrutsMentoring -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 5:38 PM To: Struts Developers List Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] OK so how can it be done with mask? also, it doesn't get more basic than numbers...if it can be done with mask, but its complicated, doesn't ease of use cut any ice? Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 Thanks Niall Robert Leland wrote: So using mask won't work ? (my syntax below is probably not correct) field property=amount depends=required,mask arg0 key=sale.amount / var var-namemask/var-name var-value\d,\d\d0\:\(\d,\d\d0\)/var-value /var /field I need to validate numbers which are formatted and have posted a patch to bugzilla which enhances validator the existing number validations to do this. This patch allows an optional numberPattern variable to be specified for the existing byte, short, integer, long, float and double validations. For Example: field property=amount depends=required,integer arg0 key=sale.amount / var var-namenumberPattern/var-name var-value#,##0:(#,##0)/var-value /var /field If the pattern is specified, then java.text.DecimalFormat is used to parse the number
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
--- Niall Pemberton [EMAIL PROTECTED] wrote: Hey thanks for your help - what you suggested worked (i.e. using ^[\d,]*$) - I was using the ORO demo, but if you don't put the right stuff in:-) OK, I'm picking up regex slowly - so this works because ^ is for the beginning of a line and % is for the end of a line. I think you meant $ instead of % but yes that's correct. Apologies for the doesn't work slander then - but wouldn't it be better to use Perl5Matcher.matches(value, pattern) and then there would be no need to specify the ^ and $ characters at the start and end - simpler and less confusing? This could be done and would be backward compatible. I really haven't looked at the differences between matches() and contains() so I don't know if it's backwards compatible. You could try changing it and let us know what happens. David Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 1:39 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] --- Niall Pemberton [EMAIL PROTECTED] wrote: Graham OK, I decided to look further into your suggestion, but didn't get very far and I think its because mask doesn't work. I know it works because I use it in my apps :-). I started with a simple expression of [\d,]* to validate that the input only contains numbers or a comma. Whatever I input though validator always passed it as valid. ORO's test applet is really helpful when testing regexs. Try putting ^ at the front and $ at the end of the pattern. ORO seems to need these to work properly unlike Java 1.4 regexs. David Looking into validator it uses Perl5Util.match(pattern, value) This utility uses the Perl5Matcher.contains(value, pattern) method which only checks that the value contains the pattern - not that matches (it says so in the Perl5Util documentation). Isn't this the wrong thing to do - shouldn't validator be using the Perl5Matcher.matches(value, pattern) method. I had a look at commons validator test thinking this must be tested for and I must be mis-understanding it - but mask seems to be the one thing there are no tests for - and there don't seem to be any in struts either for FieldChecks.validateMask()) Anyway, am I right - is this a bug, or am I just using it wrongly? Niall P.S. If I am right, then it implies no one is using mask and I think thats an argument for my simpler number validation. - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 Thanks Niall Robert Leland wrote: So using mask won't work ? (my syntax below is probably not correct) field property=amount depends=required,mask arg0 key=sale.amount / var var-namemask/var-name var-value\d,\d\d0\:\(\d,\d\d0\)/var-value /var /field I need to validate numbers which are formatted and have posted a patch to bugzilla which enhances validator the existing number validations to do this. This patch allows an optional numberPattern variable to be specified for the existing byte, short, integer, long, float and double validations. For Example: field property=amount depends=required,integer arg0 key=sale.amount / var var-namenumberPattern/var-name var-value#,##0:(#,##0)/var-value /var /field
Re: Push find 'unknown' ActionConfig into ModuleConfigImpl.findActionConfig?
--- Joe Germuska [EMAIL PROTECTED] wrote: I'm still a little gun-shy about changing core struts classes. I think the below is the right thing to do, but I thought I'd see first. ModuleConfigImpl.findActionConfig(String path) currently looks for an exact match of the path, and then uses the wild-card matching. However, it does not honor the unknown setting of action configs. That fallback is implemented in the RequestProcessor. I'd propose moving that from the RequestProcessor into the ModuleConfigImpl. This would then also involve removing a similar fallback that I committed to the struts-chain AbstractSelectAction class yesterday. How would removing it from RequestProcessor affect backwards compatibility? Could subclasses be relying on the fallback being there? Does anyone object? I mentioned this in my posting about struts-chain, but didn't get any responses on this piece. Similarly, I believe that the findException(Class clazz) method in ActionMapping should be pushed up into ActionConfig so that its fallback strategy of looking for superclass exception handlers is available. Is there any controversy to doing this? How annoyed would people be if I had just made these changes and committed them rather than asking for opinions? It's nice to discuss major changes first but most of the time you can just commit a change and wait for someone to speak up if they disagree. David 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! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action Config wild cards -- why not use regular expressions?
Unless there's a solid use case, I'd prefer to leave things as they are. You're right that only Validator uses ORO and the plan for Validator 2.0 is to replace it with the standard java.util.regex system which is twice as fast. Since Struts 2.0 will depend on Java 1.4 we could add regex action mapping then if there was a use for it. David --- Joe Germuska [EMAIL PROTECTED] wrote: Since Struts already depends on jakarta-oro, is there a reason not to use it for doing pattern-based mapping, rather than the home-grown methodology that's in the current builds? I don't have a use case for it yet, but since I was a perl hacker before I came to Java, I speak regex reasonably fluently, so it seems to me more useful to have the full power of regular expressions available. If there are strong feelings in favor of the status quo, I think it would be easy enough to make matcherClassName a property of ModuleConfigImpl and support pluggable matchers. I guess technically, only Validator depends on jakarta-oro; I might be persuaded that that's a reason to keep from adding it to the core, maybe... 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! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the different parameter counts?
--- Paul Sundling [EMAIL PROTECTED] wrote: I'd be interested in creating a patch for that. I always thought it was abitrary having some number of arguments like that myself. :) I think David is right on needing the single Object version, which is probably pretty common. To imagine why, just remember when sun tried to deprecate ServletRequest().getParameter(). I'll be busy all this week, but I could attempt it next week. At that point I'll also send an update on some other minor stuff I'd volunteered to do and any related feedback I needed. The strategy for MessageResources is to remove it from Struts and migrate to commons resources for messaging. I think I already updated the commons resources version to not include the 2,3,4,5 parameter method variants. David Paul Sundling Larry Meadors wrote: Other than some confusion, it is not a big deal, but it seems odd to me that they are different. Am I missing something? Is there a reason for not adding the five parameter version to the MessageResources method? IMO, there should be 3 versions of the method: accepting no replacement args, accepting one replacement arg, accepting an array of replacement args. The 4 or 5 arg methods seem arbitrary. I think you are right and that seems like a simple solution. But I wonder if even the one replacement arg is worth the extra code. The tag always calls the array version of the method, and the extra parameters to getMessage() buy you nothing because the methods simply convert the parameters to arrays, which can be done in-line anyway! :-) Clearly, it is not a pressing issue because it works. I think the tag is fine because it can be messy to pass arrays in jsp, but these two methods are the only ones that are actually needed: - getMessage(String, Object[]) - getMessage(Locale, String, Object[]) The rest is fluff and IMO should be deprecated in 1.2 and removed in the next release. ;-) Larry - 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] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deprecated: ActionError
The ActionError class is deprecated, not any of the tags. html:errors and html:messages work with ActionMessages and ActionErrors objects. If you look at the javadocs you'll notice that ActionErrors is fully replaced by ActionMessages and ActionError is fully replaced by ActionMessage. ActionForm.validate() is the one place where you should still use ActionErrors. David --- Mark Lowe [EMAIL PROTECTED] wrote: Sorry I don't usually post this group but is there actually a sensible replacement for action errors yet? That messages stuff still falls short of offering the same level of slickness that action errors does, perhaps this is due to he html:errors tag but i personally and i imagine others all that messagesPresent nasty mess. There's still no clear means of accessing a single property of the messages vector/array/list (whichever it is). I've asked this question a few times on the user list, but what exactly is the replacement for action errors and the accompanying tags. logic:messagesPresenet bla bla is disgusting and there's no obvious way to drill to the property in the common situation of wanting to display an error by a form element. Sorry wont post again, but its a tad irritating that something this useful is being deprecated in favor of some rancid camel's jism of an alternative. Cheers Mark On 13 Jan 2004, at 14:15, Matthias Wessendorf wrote: Hi, i watched at the sources and figured out, that ActionError is deprecated so that i have to use ActionMessage. Okay. The add() in ActionErrors is also deprecated, because of first. fine. So i watched the Validator-Sources (class FieldChecks) i saw there ist ActionMessages in use for errors. for the deliverd Methods. So i looked at our validate() in ActionForm, but there is still ActionErrors. So i wondered, why the validator uses Messages and the validate() uses Erros... and also i saw, that the validator gets initialized with an ActionErrors-object in: Resources.initValidator(); inside of initValidator() this happends: validator.setParameter(ACTION_ERRORS_PARAM, errors) but key for errors is this: private static String ACTION_ERRORS_PARAM = org.apache.struts.action.ActionMessages; the first parameter of setParameter() is called: parameterClassName. so the errors gets initialized as an ActionMessages-object, isn´t? so question: why is the ActionErrors not deprecated? in release-notes i saw: Although not removed, in many cases you should replace the deprecated ActionErrors with the preferred ActionMessages to ensure correct operation. why not in all? it would be fine, to know this ;-) greetings Matthias Matthias Weßendorf Email: mailto:[EMAIL PROTECTED] URL: http://www.wessendorf.net - 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] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Deprecated: ActionError
--- Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi David, yes i saw, so i wondered, why the validate() doesn´t return a ActionMessages. and so i wanted to know the reason for this. It can't change because it would break backwards compatibility. That's why Rob has proposed a new doValidate() method that returns ActionMessages. I'm not sure whether that would increase or decrease the confusion around this issue. Internally, Struts only references ActionMessages because its the superclass of ActionErrors. The same is true for ActionMessage vs. ActionError. The validate method is the last remaining place that uses ActionErrors in Struts. The proposed move to Commons Resources would remove ActionMessages from Struts so the validate method signature would have to change again once that was completed. David greetings -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 13, 2004 6:27 PM To: Struts Developers List Subject: Re: Deprecated: ActionError The ActionError class is deprecated, not any of the tags. html:errors and html:messages work with ActionMessages and ActionErrors objects. If you look at the javadocs you'll notice that ActionErrors is fully replaced by ActionMessages and ActionError is fully replaced by ActionMessage. ActionForm.validate() is the one place where you should still use ActionErrors. David --- Mark Lowe [EMAIL PROTECTED] wrote: Sorry I don't usually post this group but is there actually a sensible replacement for action errors yet? That messages stuff still falls short of offering the same level of slickness that action errors does, perhaps this is due to he html:errors tag but i personally and i imagine others all that messagesPresent nasty mess. There's still no clear means of accessing a single property of the messages vector/array/list (whichever it is). I've asked this question a few times on the user list, but what exactly is the replacement for action errors and the accompanying tags. logic:messagesPresenet bla bla is disgusting and there's no obvious way to drill to the property in the common situation of wanting to display an error by a form element. Sorry wont post again, but its a tad irritating that something this useful is being deprecated in favor of some rancid camel's jism of an alternative. Cheers Mark On 13 Jan 2004, at 14:15, Matthias Wessendorf wrote: Hi, i watched at the sources and figured out, that ActionError is deprecated so that i have to use ActionMessage. Okay. The add() in ActionErrors is also deprecated, because of first. fine. So i watched the Validator-Sources (class FieldChecks) i saw there ist ActionMessages in use for errors. for the deliverd Methods. So i looked at our validate() in ActionForm, but there is still ActionErrors. So i wondered, why the validator uses Messages and the validate() uses Erros... and also i saw, that the validator gets initialized with an ActionErrors-object in: Resources.initValidator(); inside of initValidator() this happends: validator.setParameter(ACTION_ERRORS_PARAM, errors) but key for errors is this: private static String ACTION_ERRORS_PARAM = org.apache.struts.action.ActionMessages; the first parameter of setParameter() is called: parameterClassName. so the errors gets initialized as an ActionMessages-object, isn´t? so question: why is the ActionErrors not deprecated? in release-notes i saw: Although not removed, in many cases you should replace the deprecated ActionErrors with the preferred ActionMessages to ensure correct operation. why not in all? it would be fine, to know this ;-) greetings Matthias Matthias Weßendorf Email: mailto:[EMAIL PROTECTED] URL: http://www.wessendorf.net - 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] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com
Re: Checkstyle headers
The copyright dates apply to each file so you can't just update all of them to read the same. Files containing Apache Group are not valid Apache 1.1 licenses and need to be fully replaced with a valid version. David --- Paul Sundling [EMAIL PROTECTED] wrote: I've created the a regular expression version of the license file and did in fact find a bunch of inconsistencies with the license. Here are the most popular ones: starting at line 2: Don't have all the CVS variables like Revision, Date and Header starting at line 26: mispelled acknowledgement starting at line 38: use of names (instead of name) starting at line 39: Apache Group (instead of Apache Software Foundation) starting at line 10: different copyright dates, including single years and a variety of year combinations All of these are pretty straightforward as far as how to fix them. except for line 10. Would it be good to update all of them to have the same date ranges (2000-2004) or just use a regular expression to account for the combinations? I assume LICENSE.txt itself should be updated to 2004 in any case. Let me know ASAP which way to go and I'll have a patch pronto. Since I've gone to all the trouble of a regexp version of the license I may as well fix the problems. It seems to me that if the license in the file is meant to represent the copyright dates of the project, I should change the files. If the copyright dates are meant to represent the individual files, then I should leave them alone. So vote for : 1. regexp expression in CheckStyle.xml and leave dates alone in the source files 2. update all the dates to the same range in the source files Paul Sundling P.S. Here are all the combinations for reference: * Copyright (c) 1999-2001 The Apache Software Foundation. All rights * Copyright (c) 1999-2001 The Apache Software Foundation. All rights * Copyright (c) 1999-2002 The Apache Software Foundation. All rights * Copyright (c) 1999-2003 The Apache Software Foundation. All rights * Copyright (c) 1999-2003 The Apache Software Foundation. All rights * Copyright (c) 1999-2003 The Apache Software Foundation. All rights * Copyright (c) 1999 The Apache Software Foundation. All rights * Copyright (c) 1999 The Apache Software Foundation. All rights * Copyright (c) 2000-2003 The Apache Software Foundation. All rights * Copyright (c) 2000-2004 The Apache Software Foundation. All rights * Copyright (c) 2001-2003 The Apache Software Foundation. All rights * Copyright (c) 2002-2003 The Apache Software Foundation. All rights * Copyright (c) 2003-2004 The Apache Software Foundation. All rights * Copyright (c) 2003 The Apache Software Foundation. All rights * Copyright (c) 2003 The Apache Software Foundation. All rights * Copyright (c) 2003 The Apache Software Foundation. All rights - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 26036] - Remove author tag and consolidate under volunteer.html
I got an error email response from the apache mail server because the commit message was so large so I don't think struts-dev will receive notification. The patch and commit worked flawlessly though. David --- [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26036. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26036 Remove author tag and consolidate under volunteer.html [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-10 21:05 --- Fixed...thanks for the patch! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 26036] - Remove author tag and consolidate under volunteer.html
--- Paul Sundling [EMAIL PROTECTED] wrote: That's probably just as well. Otherwise everyone would get like 385 commit messages.Glad to hear it went OK. No, it's just one huge commit email because I committed all the changes at once. Thanks again for the patch. David Paul Sundling David Graham wrote: I got an error email response from the apache mail server because the commit message was so large so I don't think struts-dev will receive notification. The patch and commit worked flawlessly though. David --- [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26036. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26036 Remove author tag and consolidate under volunteer.html [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-10 21:05 --- Fixed...thanks for the patch! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven checkstyle report
--- Joe Germuska [EMAIL PROTECTED] wrote: 1. License file check errors: There is a check to make sure all the source code begins with the license. This is generating errors because the copyrights don't all follow the same years as what it expects to find. It does lead me to question how the years in the copyrights are updated. This is now 2004 and I wonder if any files have 2004 in them for instance. There are at least two approachs to fix the checkstyle issue: Option 1 (easy way) we modify conf/qa/CheckStyle.xml and add 10 to ignoreLines (already has 2,3,4,5). I can submit a patch for that today if there is a go ahead. Option 2 we could make another copy of the license file with a regular expression for the years in the file. I'm leaning towards option 1 on this myself and it seems consistent with solutions that have been applied in the past. I agree, option 1 is much simpler. 2. Tab errors: It has an error for tabs in the files. Option 1 we remove the tabs check from checkStyle. Option 2 we replace tabs with spaces and do a quick visual check to see how everything lines up. Which approach to take here isn't as obvious. How important is it wether there are tabs or spaces? That's not really my call, but I'm willing to take care of it either way. This is the stuff religious wars are made of; it is true, though, things like diff work much better if indentation is done consistently, whichever character is used. I don't recall if there's an official preference in Struts, but I imagine someone will pipe in if it's important to them. If it turns into a big debate, better to disable the tabs check, because as you say, it'll improve the signal-to-noise ratio in the checkstyle reports. We need to keep the tab check because we only use spaces in Struts code. David Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com We want beef in dessert if we can get it there. -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven status
We have duplicate documentation files in the maven xdocs directory and in the usual docs directory. I updated the docs version of volunteers.xml today and am not looking forward to updating the xdocs version of the same file. What is the status of the Maven build and when are we completely switching? Are we even updating the Maven files? Maintaining two versions of the documentation is a pain and will lead to one of the versions becoming outdated. David __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @author tags in Struts code
--- Paul Sundling [EMAIL PROTECTED] wrote: If the group was interested in removing all author tags and consolidating all the names onto volunteer.html I would be willing to make a tar of patches or whatever format is most convenient. If you're interested, let me know if that would be useful and I'll try to give you 24 hour or less tournaround time. I'd probably have to ask for couple questions and then I'd submit it through bugzilla. It's in the realm of busy work, but I'm very detail oriented and pretty good with a CLI. :) I'm certainly interested and could find the time to apply your patches. We use cvs diff -u format for the patch files. Unless anyone objects to removing @author tags, go ahead and create a bugzilla enhancement ticket and attach your patch files to that. David Paul Sundling David Graham wrote: --- Paul Sundling [EMAIL PROTECTED] wrote: http://jakarta.apache.org/struts/userGuide/index.html has a list of contributors on the side. http://jakarta.apache.org/struts/userGuide/release-notes.html has a much smaller list of contributers. Those are just the people who contributed to that page on the site. The title Contributors is misleading. We should probably remove those names if we remove the @autor tags. Then of course, there's authors in individual javadocs. I probably wouldn't have added my author tag if there wren't already several already in the file. If you remove the author tags, maybe you could add those to that main contributer page. That would take care of people like me who have an author tag, but aren't listed. That's what I was thinking as well. At least so far, I probably don't deserve a listing with only two very minor patches and one implemented suggestion, but it would still be nice. :) Hopefully, I'll be able to contribute more meaningfully in the near future. Every person that provides a patch that's committed to the Struts code or docs deserves to be listed. Every contribution, no matter how small, is greatly appreciated! I've attached a list of all author tags in all their 41 permutations (other than spaces) in case you wanted to do that and remove the author tags. There's about 468 author tags instances if you plan on removing them. Thanks for the list. It will certainly help identify people missing from the contributors page. Even better would be to create a patch for the volunteers page that adds the missing people :-). Paul Sundling PS you can share this with the list if you think any of this info is helpful. In the future you should send comments like this directly to struts-dev so more people can comment and volunteer for changes. David David Graham wrote: --- Paul Sundling [EMAIL PROTECTED] wrote: Now you've got me curious. Which specific page you mean, since I've noticed various pages with different contributor lists? What sort of criteria are used to figure out if someone deserves a listing? I'm referring to this one: http://jakarta.apache.org/struts/volunteers.html What are the others you've seen? If there are duplicates, we should probably combine them into one page. Providing a patch for code or docs qualify someone to be listed on the site. David - * @author Berin Loritsch* @author Giacomo Pati* @author Pierpaolo Fumagalli* @author Stefano Mazzocchi* @author Anthony Kay* @author Arron Bates* @author Cedric Dumoulin* @author Craig McClanahan* @author Craig R. McClanahan* @author David Geary* @author David Graham* @author David Wintefeldt* @author David Winterfeldt [probably the correct one]* @author Dominique Plante* @author Don Brown* @author Don Clasen* @author Eddie Bush* @author Erik Hatcher* @author Florent Carpentier* @author James Mitchell* @author James Turner* @author Jea-noel Ribette* @author Jeff Hutchinson* @author Jimmy Larsson* @author Joe Germuska* @author Leonardo Quijano* @author Luis Arias * @author Marius Barduta* @author Martin Cooper* @author Martin F N Cooper* @author Michael Westbay* @author Mike Schachter* @author Niall Pemberton * @author Oleg V Alexeev* @author Paul Sundling* @author Ralph Schaer* @author Robert Leland* @author Rob Leland* @author Scott Carlson* @author Steve Raeburn* @author Ted Husted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @author tags in Struts code
--- Paul Sundling [EMAIL PROTECTED] wrote: I can see a lot of valid points in the article. I also don't buy the positive side regarding author tags helping point out who to go to for help on a particular file. Whatever the final decision, the philosophy should be documented on the web site in the section where it talks about how to help. There are however two reasons why I think such artifacts as author tags are good (although I think CVS comments are better if consistent). 1. For non-committers, it gives us warm fuzzies. It's like a little flag that says I actually made my contribution to open source, like more of us out there should. You can't go in CVS and see that people like me added a patch, unless a committer actually takes time to actually mention it without an author tag. If there were some template text, like Based on a patch contributed to ASF by [EMAIL PROTECTED] related to bugzilla # . in the CVS log I think that would be good enough. Most of the time when patches are applied the contributor is mentioned in the cvs commit message. All commits dealing with bugzilla are tagged with something like Fixes PR 1234 so you can go to the bugzilla page for more info. We also maintain a list of contributors on the website for everyone to see, not just those browsing the javadocs. Even though I've had a VERY VERY minor contribution, it was quite a rush to have an author tag on a minor support file. It made me feel like a part of the project and it made me want to get more involved. [I'm getting into unit testing, so I figure I might make contributions there first down the line.] I would never want to cause any resentment against those doing the brunt of the work or claim that I'm on the same level. At the same time, it's nice to have a little reminder somewhere that I'm making a contribution, however small. 2. There should be some tracking for the origins of code in case we ever get attacked by a company like SCO. Maybe there's already some cross referencing system that I'm not aware of between bugzilla and CVS that already takes care of this. I guess this is counter to legal protection under the ASF umbrella. Let's say I work at Top Secret Corp or Run By Lawyers Inc. and I submit a patch that my employer would see as infringing code. It's good code and one of committers (David Graham for instance, since I'm replying to his message) commits it into CVS. It now looks like David was the source for the code and when Top Secret Corp lawyers started sniffing around it'd be harder to find out the true source. I would guess this might end up being a major issue depending on how the SCO law suit ends. This is another good reason to not accept patches through struts-dev and only through bugzilla. When the committer commits the code they will tag it with a bugzilla ticket number. Bugzilla keeps track of who the patch came from so questions like the above never come up. David Paul Sundling David Graham wrote: The @author javadoc tag topic has been discussed on commons-dev recently and Ted brought it up in a recent struts-dev thread so I thought it might be nice to get the Struts community's opinion on it. Some arguments against @author tags by Greg Stein can be found here: http://tinyurl.com/yrlhu I'm not too concerned about the legal issues because I don't think there are any. I think it's a good idea to remove all of the tags rather than each person removing their own so that the remaining tags don't misrepresent who did most of the work (kind of an all or nothing deal). Comments? David __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DigestingPlugIn
--- Joe Germuska [EMAIL PROTECTED] wrote: I know I've asked this before, and forget how it turned out, so please forgive me for asking again :) Would it be possible to do an example usage of the DigestingPlugin that sets up static servlet context attributes, as is done by the MemoryPlugIn in the MailReader Example? Of course, if you're still out of town, don't worry about responding right away. This can wait. I had done something like it a little before DigestingPlugin was committed, but it faced the challenge that LabelValueBean didn't have a no-arg constructor, and so was hard to use with Digester. I believe I committed a fix for that issue some time ago. In case the commits weren't announcement enough, I changed the example application so that instead of creating the serverTypes list of LVBs in the MemoryDatabasePlugIn, that list is now created by the DigestingPlugIn. When I have some more time, I'll look for a place in the walking tour to add some information, although work is about to get real busy again. How would people feel about putting the XML digester rules for the label value beans into the Struts JAR? I can see the argument that it's not really core, and I wouldn't fight about it, but I can see where it would be convenient. Not only is it not core functionality but it forces you to use a certain XML structure for loading LVB objects. I'd rather let users decide how their XML looks when using Digester to load objects. David For now, I just put it in WEB-INF, which makes the struts-config a little cleaner (because I changed DigestingPlugIn to default to looking in the servlet context if the source of either the data XML or digester XML is not specified). Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com We want beef in dessert if we can get it there. -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logic:Equal
--- Kamal Gupta [EMAIL PROTECTED] wrote: Hi, I have a list which has some values which i get from database. I want to loop through the list and get values which are not duplicated for this i think the best way in struts is to use logic:equal. Please post this question to struts-user. The best way to do this is with the JSTL's c:if tag, not with logic:equal. David Can some one please send me some example on the same Regards Kamal Gupta - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/web/tiles-documentation/examples/tiles footer.jsp
--- Martin Cooper [EMAIL PROTECTED] wrote: Is there a reason for removing Cedric's copyright? As I understand it, based on the language in the CLA, Cedric is entitled to keep his own copyright there, if he so desires. Regardless of whether he's entitled I think this change was appropriate. Struts is a community effort and I don't believe we should start adding individual copyrights to the pieces we code. Much of Struts could say copyright Craig R. McClanahan but it doesn't. That's a small but important reason Struts is so popular and fun to work on. So, if only Cedric can remove the copyrights we should ask him directly and hope he'll agree :-). David -- Martin Cooper On Wed, 7 Jan 2004 [EMAIL PROTECTED] wrote: rleland 2004/01/07 13:14:40 Modified:web/tiles-documentation/common footer.jsp web/tiles-documentation/examples/tiles footer.jsp Log: remove Cerdics personal Copyright and leave only Apache Copyright Revision ChangesPath 1.3 +1 -3 jakarta-struts/web/tiles-documentation/common/footer.jsp Index: footer.jsp === RCS file: /home/cvs/jakarta-struts/web/tiles-documentation/common/footer.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- footer.jsp29 Dec 2002 21:20:52 - 1.2 +++ footer.jsp7 Jan 2004 21:14:40 - 1.3 @@ -2,9 +2,7 @@ div align=center font color=#023264 size=-1 -em Copyright copy; 2000-2003, Apache Software Foundation /em - br -emand Cedric Dumoulin /em +em Copyright copy; 2000-2004, Apache Software Foundation /em /font /div html:img page=/images/struts-power.gif align=right border=0/ 1.2 +0 -2 jakarta-struts/web/tiles-documentation/examples/tiles/footer.jsp Index: footer.jsp === RCS file: /home/cvs/jakarta-struts/web/tiles-documentation/examples/tiles/footer.jsp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- footer.jsp6 Jul 2002 01:13:50 - 1.1 +++ footer.jsp7 Jan 2004 21:14:40 - 1.2 @@ -2,8 +2,6 @@ div align=center font color=#023264 size=-1 em Copyright copy; 2001, Apache Software Foundation /em - br -emand Cedric Dumoulin /em /font /div img src=%=request.getContextPath()%/images/struts-power.gif align=right border=0 - 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] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
@author tags in Struts code
The @author javadoc tag topic has been discussed on commons-dev recently and Ted brought it up in a recent struts-dev thread so I thought it might be nice to get the Struts community's opinion on it. Some arguments against @author tags by Greg Stein can be found here: http://tinyurl.com/yrlhu I'm not too concerned about the legal issues because I don't think there are any. I think it's a good idea to remove all of the tags rather than each person removing their own so that the remaining tags don't misrepresent who did most of the work (kind of an all or nothing deal). Comments? David __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STATUS LOG] 30 Dec 2003 - Jakarta-Struts
Several of the items here can be automated with Maven (ie. cvs activity). Unless the whole thing can be automated, I'm -0 on doing this. I personally don't have any time to contribute to these status reports and my hunch is that they will fall into disrepair. Save the status reports for managers, not fun volunteer projects :-). David --- Ted Husted [EMAIL PROTECTED] wrote: I thought it might be helpful to start publishing regular status reports, so here's a proposed format. This might be something that we would post to both lists, and also maintain this in CVS, to keep a running log of changes. * Releases * Showstappers * Recent Changes * Roadmap * Bugzilla * Subscriptions * Threads * CVS Activity * Committers -Releases- * Stable release: 1.1 (29 June 2003). * Next anticipated release: 1.2.0 * Anticipated time-frame (if any): Next thirty days, if pending issues can be resolved. -Showstoppers- * The 1.2.0 candidate should resolve Bugzilla [#233255, #23292, #25134, #28524, #25855, #25861] before release. -Recent Changes- * 2003-12-30 - struts-nested: Added write attribute, and styleClass for completeness. * 2003-12-29 - struts-faces: Various updates regarding the JSF Final Draft and to prepare for Tiles support. * 2003-12-22 - DispatchAction: Add detection of recursive calls. * 2003-12-21 - Change to use typical welcome.do - welcome.jsp approach; Use name rather than attribute in configuration, per documented and common practice; Use action form of html:link * 2003-12-21 - Add rest of form to fr.CA formset to correct operation. * 2003-12-17 - struts-jericho: Whiteboard directory for Struts-Jericho, a working proposal for Struts 2.x. * See also: http://jakarta.apache.org/struts/userGuide/release-notes.html -Roadmap- * Struts 1.x will remain based on Servlet 1.2/JSP 1.1 (evolution). * Struts 2.x will be based on Servlet / JSP 2.0 (revolution). * For more see http://jakarta.apache.org/struts/status.html. -Bugzilla- * Open problem reports: 6 [#23255 .. #25861] * Open enhancement reports: 210 [# 866 .. #25860] * Open LATER reports:17 [#17977 .. #25759] -Mailing list subscriptions- * User 1955 * user digest: 923 * Dev: 719 -Significant threads- * Dev list discussions of whether and when to apply to the ASF for top-level project status http://tinyurl.com/2kkcq. * Several threads regarding Struts 2.0 feature set. A preliminary whiteboard has been posted http://cvs.apache.org/viewcvs.cgi/jakarta-struts/contrib/struts-jericho/. -CVS Activity- * Total Commits: 89 Total Number of Files Changed: 401 -Active Committers- * Craig R. McClanahan (craigmcc at apache.org) * Ted Husted (husted at apache.org) * Rob Leland (rleland at apache.org) * Cedric Dumoulin (cedric.dumoulin at lifl.fr) * Martin Cooper (martinc at apache.org) * Arron Bates (arron at apache.org) * James Holmes (jholmes at apache.org) * David M. Karr (dmkarr at apache.org) * David Graham (dgraham at apache.org) * James Mitchell (jmitchell at apache.org) * James Turner (turner at blackbear.com) * Steve Raeburn (sraeburn at apache.org) * Don Brown (mrdon at apache.org) * Joe Germuska (germuska at apache.org) ### - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pagePattern
--- Ted Husted [EMAIL PROTECTED] wrote: I was setting up a working test for pagePattern in an application that doesn't use module (the Mailreader Example). It doesn't seem to recognize a pattern like /pages$M$P where it the same application it does recognize a forwardPattern like /do$M$P. I think I see where the problem might be, but I really need a baseline modules application to proceed. We broke the register portion of MailReader out to demonstrate multiple configs and then wildcard actions. I'm thinking we (meaning I) should finish the job and make the register portion a separate module. Thoughts? Objections? Alternatives? This has been a problem with modules all along. I don't use them because nobody seems to be actively supporting this feature aside from the occasional bugfix. IMO, the current implementation isn't coherent enough to prevent new bugs popping up (you have to look all over the code base to see if you've broken modules). I think it's a great idea to add some examples to test against. David -Ted. __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pagePattern
--- Ted Husted [EMAIL PROTECTED] wrote: Hey, here's an alternative: How about combining the exercise-taglib, validator, and upload applications in to single application three modules? That way we can avoid unnecessary complications to the MailReader, eliminate two redundant sets of JARs, share the LocaleAction without making it a standard Action, and have a shared module example to tinker with. +1 While it is nice to have logically separate apps, the benefits of combining them are compelling. The combined app should probably have a start page with links to the 3 different modules for clarity. I still think we need a stock LocaleAction, but that could also be made part of a separate distribution with some other goodies that many people find helpful but might not be suitable for the actions package. We should discuss LocaleAction in its own thread. I'm not necessarily opposed to putting it in the standard actions package but I'd like to have an explanation, use cases and design review before we add it. David Since I want to address the pagePattern and other module reports for 1.2.0, and need a test-bed, I'm going to have a go at combining the aforementioned gang of three. -Ted. On Fri, 02 Jan 2004 07:18:19 -0500, Ted Husted wrote: I was setting up a working test for pagePattern in an application that doesn't use module (the Mailreader Example). It doesn't seem to recognize a pattern like /pages$M$P where it the same application it does recognize a forwardPattern like /do$M$P. I think I see where the problem might be, but I really need a baseline modules application to proceed. We broke the register portion of MailReader out to demonstrate multiple configs and then wildcard actions. I'm thinking we (meaning I) should finish the job and make the register portion a separate module. Thoughts? Objections? Alternatives? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/actions LocaleAction.java
I don't think the reason for this change is valid. If you only want to
use
this action in examples and tests it doesn't belong in the standard
actions package which allows it to be used in applications and requires
support.
The action is an ok example but it's not generally seful enough to warrant
promotion to the main Struts distro. More importantly, the code isn't
ready for the main distro as it catches Exception and hardcodes the
success forward name.
David
--- [EMAIL PROTECTED] wrote:
husted 2004/01/01 05:45:49
Added: src/share/org/apache/struts/actions LocaleAction.java
Log:
Move LocaleAction from Validator example webapp to standard Actions
package, so that it can be used in other examples and tests.
Revision ChangesPath
1.1
jakarta-struts/src/share/org/apache/struts/actions/LocaleAction.java
Index: LocaleAction.java
===
/*
* $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/actions/LocaleAction.java,v
1.1 2004/01/01 13:45:49 husted Exp $
* $Revision: 1.1 $
* $Date: 2004/01/01 13:45:49 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2000-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above
copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowledgement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software
itself,
*if and wherever such third-party acknowlegements normally
appear.
*
* 4. The names The Jakarta Project, Struts, and Apache Software
*Foundation must not be used to endorse or promote products
derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their name, without prior written
*permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/
package org.apache.struts.actions;
import java.util.Locale;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import org.apache.commons.beanutils.PropertyUtils;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.struts.Globals;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
/**
* Implementation of strongAction/strong that changes the user's
* @link(java.util.Locale and forwards to a page, based on request
level
* parameters that are set (language, country, amp; page).
*
* @author David Wintefeldt
*/
public final class LocaleAction extends Action {
/**
* Commons Logging instance.
*/
private Log
Re: tinyurl.com [was: Re: cvs commit: jakarta-stru...]
--- James Mitchell [EMAIL PROTECTED] wrote: Maybe its just me or I'm missing something here, but do we have to use tinyurl.com? I'm not sure I like the idea of relying on a 3rd party for web resource address translation. If continue using this service and something happened and tinyurl.com was not available, we would lose many valuable references such as the one below. Perhaps we could utilize some other means of shortening long URLs, or at least something we have more control over. Your thoughts? -1 on using tinyurl in Struts javadocs and documentation. I can't think of any valid reason not to specify the real url in our docs. David On Thu, 1 Jan 2004 [EMAIL PROTECTED] wrote: husted 2004/01/01 14:39:59 Modified:src/share/org/apache/struts/taglib/bean WriteTag.java Log: Add notes regarding discovering localized notations, per research by Jason Lea. Revision ChangesPath 1.31 +12 -5 jakarta-struts/src/share/org/apache/struts/taglib/bean/WriteTag.java Index: WriteTag.java === RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/bean/WriteTag.java,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- WriteTag.java 1 Jan 2004 19:27:19 - 1.30 +++ WriteTag.java 1 Jan 2004 22:39:59 - 1.31 @@ -316,7 +316,14 @@ /** * Format value according to specified format string (as tag attribute or * as string from message resources) or to current user locale. - * + * + * When a format string is retrieved from the message resources, + * codeapplyLocalizedPattern/code is used. For more about localized + * patterns, see http://tinyurl.com/33y54. (To obtain the correct + * value for some characters, you may need to view the file in a + * hex editor and then use the Unicode escape form in the + * property resources file.) + * * @param valueToFormat value to process and convert to String * @exception JspException if a JSP exception has occurred */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- James Mitchell Software Developer / Struts Evangelist http://www.struts-atlanta.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cc struts-dev
This is just a friendly reminder to add [EMAIL PROTECTED] to the cc list on any bugs you assign to another address. Otherwise, struts-dev won't get notified of changes to the bug. David __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bugzilla changes
Ted, Why were many bugs said to be marked LATER but then changed to FIXED? Also, some bugs were marked FIXED and I didn't see any corresponding commit messages with the fixes. I've gone through some of these and changed them to LATER but there are so many that I wanted make sure I wasn't missing something. David __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - 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)
--- Don Brown [EMAIL PROTECTED] wrote: On Thu, 18 Dec 2003, PILGRIM, Peter, FM wrote: snip / What kind of Spring Framework classes would you want to use in Struts 2.0? The BeanWrapper and the BeanFactory are interesting ideas. An example of configuring commons DBCP is given http://www.springframework.org/docs/lightweight_container.html I am not convince however of the requirement for BeanFactory. I can understand if you need to have massive XML configuration and need to dynamic generate Beans (objects) at run-time. It is great but other than that I can really view to the advantage inverse of control there that Struts or Commons BeanUtils combine Digester could not do itself. Struts is great because it concentrates on doing one thing well MVC. I wouldn't want it to branch out go into a generic framework space e.g Avalon, Expresso, Keel, Spring, Pico etc. The major design difficulties are abstract away the request and response objects from the controller actions, and also configuration of any other front-end objects you need along the way. To a certain extent Commons Chain and its context leads the way regarding the former. I see Spring as helping Struts be better structure its internal components, specifically using a BeanFactory implementation. It would not replace struts-config in any way or even be exposed directly the a Struts application. The struts-chain request processor implementation makes it easy for Struts apps to plug in IoC frameworks themselves. I totally agree Struts shouldn't become some generic IoC framework, hence my suggestion of using Spring. The reason I think IoC is important for Struts 2.0 is for easier unit testing, more componentized development, easier to plug in alternate implementions of components like file upload, better dependency management, less object references, and easier for the advanced user to extend Struts in interesting ways. Notice these advantages are targeted for Struts developers and advanced Struts users. The IoC topic deserves its own thread. Spring is bloated. It contains a DAO layer, JDBC helper library, Web MVC framework, IoC support, etc. I don't think we should be lugging around Spring inside of Struts. There are also non-technical aspects of Spring that have lowered my opinion of it. If we want IoC inside of Struts we should look at something lighter weight like HiveMind. I'd also like some focused concrete examples of how IoC would benefit Struts internals before we decide to go that route. David Don -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why you *want* to be on the PMC
I have some real basic questions: 1. Why is it better to be a top level Apache project rather than part of Jakarta. 2. What are the requirements for becoming a top level project? Any URLs/info is appreciated. David --- Craig R. McClanahan [EMAIL PROTECTED] wrote: Quoting James Mitchell [EMAIL PROTECTED]: On Thu, 18 Dec 2003, Craig R. McClanahan wrote: snip/ If/when Struts becomes a TLP, I'm going to recommend that we do exactly what Ant, James, and Maven (for example) did: * Maintain a link on the Jakarta home page under Related * Install a webserver redirect from http://jakarta.apache.org/struts to http://struts.apache.org. Is there anything holding us back from going TLP? I seem to remember only a few brief discussions on the dev listand that was quite a ways back. Presuming a positive vote from the committers, we'd have to make a formal proposal to the ASF Board (like the Ant, Maven, ... communities did, so we can use their proposals as a sample) and get it accepted. Included in the proposal would be things like who the PMC members would be, and who we'd suggest as the PMC chairperson (because this person becomes an ASF officer, it has to be appointed by the board). The largest issue around preparing the proposal is likely to be a definition of what the scope of the project will be. James Mitchell Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why you *want* to be on the PMC
--- Craig R. McClanahan [EMAIL PROTECTED] wrote: Quoting Ted Husted [EMAIL PROTECTED]: Craig R. McClanahan wrote: Presuming a positive vote from the committers, we'd have to make a formal proposal to the ASF Board (like the Ant, Maven, ... communities did, so we can use their proposals as a sample) and get it accepted. Included in the proposal would be things like who the PMC members would be, and who we'd suggest as the PMC chairperson (because this person becomes an ASF officer, it has to be appointed by the board). The largest issue around preparing the proposal is likely to be a definition of what the scope of the project will be. We could dodge the bullet and just follow Cocoon precedent: define the scope of Apache Struts to be Apache Struts :) So, do we invite the non-Java implementations of the same concept in, or do we say nah, we're a Java project? I'm not personally much interested in the non Java solutions, but a cross-language framework would be somewhat unusual. I'm also not interested in non-Java Struts implementations. Any other implementation could only share struts-config.xml and none of our current code. There would be 2 separate and largely independent group of developers so I don't see the need to include them in Struts. David Craig http://apache.org/foundation/records/minutes/2003/board_minutes_2003_01_22.txt Otherwise, any language we come up with is sure to overlap with other Apache offerings, and we end up having to create some type of frameworks project, along the lines of the Database or Web Services projects. http://apache.org/foundation/records/minutes/2002/board_minutes_2002_07_17.txt http://apache.org/foundation/records/minutes/2003/board_minutes_2003_01_22.txt If we did decide to do something, I'm not opposed to either course. The former would be less work, but the latter might have greater long term benefits. In the latter case, I suppose we'd ask Tapestry and Turbine if they wanted to join us as frameworks.apache.org (or whatever). I looked over the Board status reports for db and webservices, but it's hard to tell whether these new umbrellas are working any better than Jakarta. If anyone is involved with the communities, and has something to share, please do. On balance, I would lean toward the position that the Struts community is large and robust enough to justify its own TLP, and see if the Board agrees. One thing I would like to bring up in the context of a TLP Struts is the idea of also hosting a php implementation of Struts. Several people have been trying to do this (google struts php). Since php is also an Apache product, it would be a natural thing for a top-level ASF Struts project do to. A framework similar to Struts, Maverick, already has a php implementation, which proves it can be done. Of course, there is also the matter of JSR 223 http://jcp.org/en/jsr/detail?id=223. There is *alot* of interest in using MVC in php-land, and a Struts implementation could help coalesce that interest into a stable community. -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] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
--- Ted Husted [EMAIL PROTECTED] wrote: So, there were a few more outstanding reports that I thought we would have. http://tinyurl.com/ysx3x Notice that 12 of the 29 bugs are custom tag related proving once again how badly we need to move them into their own distro. Six have patches, which I will try to apply tomorrow. Most of the others are reports about problems I may not know how to fix. I can thing of four ways to deal with these: (1) mark reports without proposed solutions enhancements IMO, we shouldn't start making up new definitions of enhancement just to accomodate our release schedule. (2) mark unresolved problem reports LATER (like before) +1 on marking as LATER. (3) change the release plan so we can leave them open (4) forgo the release indefinitely On a related topic, would anyone call any of these showstoppers. No, I think we can release as planned. David -Ted. Ted Husted wrote: I've amended the date on the (now venerable) 1.2.0 release plan for this weekend. http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html I believe the release notes are in good shape now. I already marched through most of the stale 1.0/1.1 tickets, and can mop up the rest in short order. I imagine there will be a few patches that we can apply, but I've carved out some time to work on such. Note that I've left room in the release plan for the idea of multiple managers. If someone were up for sheparding the tests, especially the example application testing, I'd welcome the help. Someone else could also sign up for the final tag, roll, and announce part of the job. Of course, if everyone is busy, I'll be happy to muddle through on my own. :) Since this is a x.0 release, the plan calls for a majority vote. Here's my +1 -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts EL Distro
The binary Struts build includes struts-el in the contrib directory. Why does struts-el/lib include the commons-*.jars and JSTL jars? The common jars are already distributed with the standard Struts build and the JSTL jars should be downloaded separately. Considering the frequency of Struts downloads and our large 21MB distro size, removing these duplicate jars will save Apache a considerable amount of bandwidth. David __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - 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)
--- Vic Cekvenich [EMAIL PROTECTED] wrote:
And even a simple DAO interface, to be used optionaly be people, so
they can go back and forth from iBatis to Hibreante or what ever.
I started the Mapper project in the commons for this exact reason. It
doesn't belong in Struts.
http://jakarta.apache.org/commons/sandbox/mapper/
David
And build Struts on top of HiveMind or similar. (IoC and Services... and
XML).
If just the MVC interfaces are defined, then several implemenations can
ship. One implemtation would be backwards compatible.
Once could be SOAPActionImpl.
Action's execute should take a Map as signature argument. This way we do
not have Req/Resp tie in, but anything comes in.
Ex: execute(Map arg) { .. }
A good 1st step is to have a TilesAction and Action have same signature
for execute.
.V
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
+1 David --- Ted Husted [EMAIL PROTECTED] wrote: I've amended the date on the (now venerable) 1.2.0 release plan for this weekend. http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html I believe the release notes are in good shape now. I already marched through most of the stale 1.0/1.1 tickets, and can mop up the rest in short order. I imagine there will be a few patches that we can apply, but I've carved out some time to work on such. Note that I've left room in the release plan for the idea of multiple managers. If someone were up for sheparding the tests, especially the example application testing, I'd welcome the help. Someone else could also sign up for the final tag, roll, and announce part of the job. Of course, if everyone is busy, I'll be happy to muddle through on my own. :) Since this is a x.0 release, the plan calls for a majority vote. Here's my +1 -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
--- Ted Husted [EMAIL PROTECTED] wrote: The mean number of milestones for a Jakarta stable release seems to be five or six. So, it would not be unusual for us to get 1.2.4 before hitting a General Availability grade. That could be because products using this versioning/release system don't spend as much time making sure it's bullet proof. Struts 1.2.0 isn't much different than 1.1 so it wouldn't surprise me if we reached GA before 5 or 6 point releases. David -Ted. [EMAIL PROTECTED] wrote: Were we still planning on using Validator 1.1.1 when it is released ? It's getting a little confusing, since I removed it, and called for a release Vote. The vote isn't scheduled to complete until Sunday Noon. And Struts source will be frozed at Saturday Midnight. -Rob - 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] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running Struts Cactus tests with Ant
--- James Mitchell [EMAIL PROTECTED] wrote: Any chance someone wants to throw together a step-by-step-build-struts-with-maven.readme? cd your-struts-dir maven build Anything much more complicated than that defeats the purpose of using Maven. David Anyway, maybe I just need an Ant trick to give me better feedback about why it's failing -- it's probably something very routine. I do know that the same test case passes when I run it in Maven. Thanks in advance for any tips... Joe start.tomcat.41: [java] Dec 16, 2003 3:38:21 PM org.apache.coyote.http11.Http11Protocol init [java] INFO: Initializing Coyote HTTP/1.1 on port 8080 [java] Starting service Tomcat-Standalone [java] Apache Tomcat/4.1.29 [java] log4j:WARN No appenders could be found for logger (org.apache.struts.util.PropertyMessageResources). [java] log4j:WARN Please initialize the log4j system properly. [java] Dec 16, 2003 3:38:31 PM org.apache.coyote.http11.Http11Protocol start [java] INFO: Starting Coyote HTTP/1.1 on port 8080 run.test: [junit] Running org.apache.struts.action.TestActionMessage [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.075 sec [junit] Testsuite: org.apache.struts.action.TestActionMessage [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.075 sec [junit] Testcase: testActionMessageWithNoValue took 0.039 sec [junit] Testcase: testActionMessageWithAStringValue took 0.001 sec [junit] Running org.apache.struts.action.TestActionMessages [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.06 sec [junit] Testsuite: org.apache.struts.action.TestActionMessages [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.06 sec [junit] Testcase: testEmpty took 0.025 sec [junit] Testcase: testNotEmpty took 0.005 sec [junit] Testcase: testSizeWithOneProperty took 0.001 sec [junit] Testcase: testSizeWithManyProperties took 0.001 sec [junit] Testcase: testSizeAndEmptyAfterClear took 0 sec [junit] Testcase: testGetWithNoProperty took 0.013 sec [junit] Testcase: testGetForAProperty took 0 sec [junit] Testcase: testAddMessages took 0.001 sec [junit] Running org.apache.struts.action.TestActionServlet [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.782 sec [junit] Testsuite: org.apache.struts.action.TestActionServlet [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.782 sec [junit] Testcase: testInitDestroyInternal took 1.771 sec [junit] Caused an ERROR [junit] Error instantiating class [org.apache.struts.action.TestActionServlet([testInitDestroyInternal], [null])] [junit] javax.servlet.ServletException: Error instantiating class [org.apache.struts.action.TestActionServlet([testInitDestroyInternal], [null])] [junit] at org.apache.cactus.server.AbstractWebTestCaller.getTestClassInstance(AbstractWebTestCaller.java:459) [junit] at org.apache.cactus.server.AbstractWebTestCaller.doTest(AbstractWebTestCaller.java:148) [junit] at org.apache.cactus.server.AbstractWebTestController.handleRequest_aroundBody0(AbstractWebTestController.java:130) [---% snip stack trace %] [junit] Testcase: testInitDestroyInternal stop.tomcat.41: [java] Stopping service Tomcat-Standalone [java] Dec 16, 2003 3:38:47 PM org.apache.coyote.http11.Http11Protocol destroy [java] INFO: Stoping http11 protocol on 8080 Catalina:type=ThreadPool,name=http8080 BUILD FAILED /Users/germuska/Development/jakarta/jakarta-struts/build-tests.xml:236: Test org.apache.struts.action.TestActionServlet failed Total time: 50 seconds This same test -- James Mitchell Software Developer / Struts Evangelist http://www.struts-atlanta.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Attachment to bug 866
The problem was that the bug was assigned to Ted and [EMAIL PROTECTED] wasn't added to the CC list. I've fixed this so we get emails when this bug is updated. David --- Hubert Rabago [EMAIL PROTECTED] wrote: Last night I uploaded an attachment to bug 866 (Clean Way to Add Parameters to Redirecting Forward). It allows Action objects to add redirects like these: ActionRedirect redirect = new ActionRedirect(mapping.findForward(doRedirect)); redirect.addParameter(param1,value1); redirect.addParameter(param2,2); redirect.addParameter(param3,3.0); return redirect; I'm sending this message because that notice seemed to have been skipped by bugzilla (probably because that particular item doesn't have an associated milestone target), and I thought you guys might like to know. There's also an attachment for testing ActionRedirect. Hubert Rabago __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Joe Germuska as a Struts Committer
+1 Joe has, refreshingly, backed up suggestions with working code :-). David --- Martin Cooper [EMAIL PROTECTED] wrote: Joe has been involved in the Struts community for some time now, and has been a great contributor on the -dev and -user lists, as well as in the bug database. I believe Joe would be a great asset to the team, and that it's time we invited him to join us as a Struts committer. Here's my +1. -- Martin Cooper __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getDataSource deprecate
--- Vic Cekvenich [EMAIL PROTECTED] wrote: Consider if it be good idea to sometime in the future mark getDataSource as deprecated. I think Struts 2.0 is a good time to remove the DataSource support from Struts. Containers are now fully capable of easy JNDI DataSource configuration and will only get better by 2.0. Having a Struts way of doing DataSources is proving to be confusing for users. David .V __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback on the Dec 1 nightly build
--- stu robertson [EMAIL PROTECTED] wrote: First, thanks for the quick followup last week on the readyness of builds including ValidWhen. I started testing our application against this build this morning. The one would-be showstopper for us (although we work around it) is that the current snapshot of commons-collections has a number of serialization bugs. We're using decorators fairly extensively for type-safety. Since they're not serializable, they cause NotSerializableException when returned from stateless session EJBs. We're currently using a collections 3.0 build that we've modified to make these serializable. But the Struts 1.2 nightly comes with the broken version. Why are we distributing nightly builds of commons components that we rely on? IMO, unless we need the very latest features of commons package X we should ship nightly Struts builds with the last released version of X. David This bugzilla search shows the bugs we're working around: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Commonscomponent=Collectionsshort_desc=serializableshort_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitorder=%27Importance%27 The other thing I've noticed is that the validator includes a number of DTDs that don't seem to match the files they ship with. validator-rules.xml references the DTD http://jakarta.apache.org/commons/dtds/validator_1_1.dtd;, and the distribution ships with 2 local DTDs for the validator, validator-rules_1_1.dtd and validation_1_1.dtd. Neither of these match the reference in the rules.xml file. Developing behind our firewall, local DTDs are many developers' only option for validation. If I modify the rules.xml file to reference either of these DTDs, errors appear. Are these old DTDs, or am I missing something? Stu Robertson __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven test run
--- Steve Raeburn [EMAIL PROTECTED] wrote: I've updated the Maven build to generate some documentation. Use 'maven site' to generate it. I copied the documentation over from docs to xdocs. There are some differences between the tags expected by the Maven xdoc transofrmation and our existing XSL transformation. It's causing some funky formatting at the moment, but it will be fixable. I've noticed the following so far: - chapter elements are not recognized. I've changed them to section for now. - Block code examples need to be wrapped in a source tag. See index.xml for an example. - Many (all?) of the anchors aren't operational I've also been experimenting with customization of the site. Main changes are in project.properties, but I've also added a custom JSL stylesheet (struts.jsl) which would allow complete control over the generated site. You might find the current look familiar ;-) TODO: - Figure out the best way to migrate the xml docs (essentially change the source docs or change the JSL stylesheet) - Generate tlds and taglib documentation - Look into using the multi-project plugin to build webapps contrib - Play with the Cactus plugin to get the other tests running Anyone who wants to explore Maven, feel free to dive in :-) You're going to delete the old versions in /doc right? We certainly don't want to maintain 2 versions of our docs. It would be good not to lose the cvs history on all of these in the moves to xdocs so maybe we can just move the files in the filesystem on cvs.apache.org instead of just checking in brand new versions in xdocs? David Steve -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: November 28, 2003 3:10 PM To: Struts Developers List Subject: Re: Maven test run Steve, would it be possible to merge what you started here with the current Maven build? -Ted. Steve Raeburn wrote: In the spirit of rolling up sleeves, this is the result of a very quick look at Maven: http://www.apache.org/~sraeburn/maven/index.html I'll keep playing with this for now, because it's not fit to be checked in yet and I've only built the core /src/share files. There's also more work to do in configuring the various reports. Don't expect all the links to work, or any of the reports to be correct (though already, some of them look useful). Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Junit in Action - http://www.manning.com/massol/, Struts in Action - http://husted.com/struts/book.html, JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512. - 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] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven test run
--- Steve Raeburn [EMAIL PROTECTED] wrote: At the minute, I've just copied the docs over to see how it would work out. My opinion is not bad, but more work required. As far as I'm concerned, the Maven build is still experimental and not ready for primetime. It might be an option to build the website from Maven in the (very) near future, but I think we'll need to do some restructuring before the library build will work with Maven. (Separate out the taglibs, web apps, contribs into separate sub-projects). I don't think we should let the Mavenization process hold up the 1.2.0 release. There's a lot of changes waiting to get out and I think it best not to combine those with a change in the build process. Hopefully, we can integrate it into the build as we move forward through 1.2.x. For maintenance purposes, the live documentation is still in docs. Don't bother trying to maintain xdocs yet. I hope we'll be able to translate the docs in place maintain the history. Ok, I was confused by the duplication. Thanks for clarifying that. David I'm not sure the end is in sight yet, but I'm now more confident now that the end is achievable with Maven :-) Steve -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: November 29, 2003 12:31 PM To: Struts Developers List Subject: Re: Maven test run David Graham wrote: You're going to delete the old versions in /doc right? We certainly don't want to maintain 2 versions of our docs. It would be good not to lose the cvs history on all of these in the moves to xdocs so maybe we can just move the files in the filesystem on cvs.apache.org instead of just checking in brand new versions in xdocs? If we're ready to convert the documentation to Maven, then we could just point the xdoc plugin at our doc directory by setting the maven.docs.src property. http://maven.apache.org/reference/plugins/xdoc/properties.html I'm OK with doing this, but it should be a deliberate decision, and we should probably have an actual vote. Of course, there is still some work to do, and I can help with that over the next week. But I think the end is in sight :) -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] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUG fix for org.apache.struts.taglib.html.JavascriptValidatorTag
Thanks for the fix idea. It would have been better if you posted this
directly to the bugzilla ticket though.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24516
David
--- Igor Marchenko [EMAIL PROTECTED] wrote:
Hello all.
BUG
---
I use Struts's ValidatorPlagin in client validation manner. It generates
an
JavaScript Array of field checks to made. Example:
function validatorRuleName () {
this.aa = new Array(...));
this.ab = new Array(...));
this.ac = new Array(...));
this.ad = new Array(...));
this.ae = new Array(...));
...
this.do = new Array(...));
...
this.in = new Array(...));
...
}
But do and in is JavaScript reserved words. Therefore if there is
quite
a few field who need validation this.do and this.in appears (this is
syntax error).
FAST FIX
Override org.apache.struts.taglib.html.JavascriptValidatorTag#getNextVar
method as here:
private String getNextVar(String input) {
return _+(input==null?0:(Integer.parseInt(input.substring(1))+1));
}
DEEPER FIX
--
It's clear,
org.apache.struts.taglib.html.JavascriptValidatorTag#getNextVar
method is not needed. Remove them at all and correct
org.apache.struts.taglib.html.JavascriptValidatorTag#doStartTag method
correspondingly.
Replace next lines
String jscriptVar = null;
jscriptVar = this.getNextVar(jscriptVar);
results.append(
this.
+ jscriptVar
+ = new Array(\
+ field.getKey()
+ \, \
+ message
+ \, );
with
int jscriptVar = 0;
results.append( this.)
.append(jscriptVar++)
.append( = new Array(\)
.append(field.getKey())
.append(\, \)
.append(message)
.append(\, );
OTHER WORDS
---
I check both fix ways with big number (more than 100) of checks on one
page.
Big thanx for all Struts developers.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/util MessageResources.java
When changing Struts' messaging classes we also need to update
commons-resources with identical changes. Otherwise, we'll end up getting
frustrated users and duplicate bug reports when Struts starts using
commons-resources.
David
--- [EMAIL PROTECTED] wrote:
martinc 2003/11/27 14:14:51
Modified:src/share/org/apache/struts/util MessageResources.java
Log:
Make sure getMessage(String) goes through the local implementation,
rather
than bypassing it and therefore skipping the default locale handling.
PR: 22252
Submitted by: msc at ivu.de
Revision ChangesPath
1.20 +5 -5
jakarta-struts/src/share/org/apache/struts/util/MessageResources.java
Index: MessageResources.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/MessageResources.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- MessageResources.java 9 Sep 2003 04:33:12 - 1.19
+++ MessageResources.java 27 Nov 2003 22:14:51 - 1.20
@@ -204,7 +204,7 @@
*/
public String getMessage(String key) {
-return this.getMessage((Locale) null, key);
+return this.getMessage((Locale) null, key, null);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: TagUtils.encodeURL performance
UTF-8 is used because it's recommended in the URLEncoder javadoc: http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLEncoder.html David --- yasuhiko yoshikawa [EMAIL PROTECTED] wrote: I do not think always passing UTF-8 as character encoding type is right behavior. As far as I can tell, there is no such requirement to mandate(or even recommend) UTF-8 as character encoding type in the HTML4 specification (and relevant RFCs). A while ago, I submitted a patch that enables the encoder to take character encoding name as second parameter. I see no reason why the character encoding is done with UTF-8. Using UTF-8 as character encoding type works only if the html documents sent from the application are encoded in UTF-8, but many i18n applications use 'native' character encodings (like Shift_JIS, Big5, EUC-KR etc) instead, for variety of reasons. The issue was recently discussed on the mailing list of Japanese struts user's. And we found that, for example, html:link tag's parameter populating functionality has been unusable for many of us because it ignores the response's character encoding and uses UTF-8 to get the bytes for url encoding. --- Robert Leland [EMAIL PROTECTED] wrote: Pierre Maury wrote: The patch would need to be usable with different encoding types. Why? The Java 1.3 version doesn't accept an encoding type and we always pass UTF-8 to the 1.4 version. This memory storage seems like a small price to pay for the improvement, but I would like to hear from other commiters. I'm not a big fan of this because there are much bigger performance optimizations to be had in other layers of a Struts app but I won't stop anyone from applying a clear and *tested* optimization. David -Rob Hi, I think there is a performance issue with org.apache.struts.taglib.TagUtils.encodeURL(String). Attached to this mail, four java classes that demonstrate and solve the problem. You may run EncoderTest to compare the timings of the original struts code with a faster encoder. On my computer encodeURL takes about 0.2ms. This does not look like a big issue, but encodeURL is called by computeUrl for each parameter name and each parameter value. The web site I'm working on displays products lists. There an average 3 links per product and 20 products per page + 20 other links. Each of this links takes four parameters. Total encodeURL time per page amounts to : (3*20+20)*(4*2)*0.2 = 128ms ! At the same time, the struts action + the JSP page takes about 200ms. The attached encoder is at least 50 times faster. By using this encoder on my application, the troughput was greatly improved. If you are interrested, I can submit a patch Pierre Maury - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Yasuhiko Sakakibara [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2.0 Resurrected
--- Ted Husted [EMAIL PROTECTED] wrote: With the long weekend coming up, I was thinking of rolling up my sleeves and doing whatever needs to be done to cut 1.2.0. Anyone one aware of any serious showstoppers? Nope, the commits have been relatively infrequent and I haven't seen anything serious. Rob has been fixing up Validator issues so it will be great to get these released in 1.2.0. David While under the current scheme, any release has the potential to make the General Availability grade, I would anticipate that 1.2.0 will end up being a simple milestone release, and we'll have to cut a few more before we get to GA. But, I'd like to start the ball rolling. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TagUtils.encodeURL performance
--- Robert Leland [EMAIL PROTECTED] wrote: Pierre Maury wrote: The patch would need to be usable with different encoding types. Why? The Java 1.3 version doesn't accept an encoding type and we always pass UTF-8 to the 1.4 version. This memory storage seems like a small price to pay for the improvement, but I would like to hear from other commiters. I'm not a big fan of this because there are much bigger performance optimizations to be had in other layers of a Struts app but I won't stop anyone from applying a clear and *tested* optimization. David -Rob Hi, I think there is a performance issue with org.apache.struts.taglib.TagUtils.encodeURL(String). Attached to this mail, four java classes that demonstrate and solve the problem. You may run EncoderTest to compare the timings of the original struts code with a faster encoder. On my computer encodeURL takes about 0.2ms. This does not look like a big issue, but encodeURL is called by computeUrl for each parameter name and each parameter value. The web site I'm working on displays products lists. There an average 3 links per product and 20 products per page + 20 other links. Each of this links takes four parameters. Total encodeURL time per page amounts to : (3*20+20)*(4*2)*0.2 = 128ms ! At the same time, the struts action + the JSP page takes about 200ms. The attached encoder is at least 50 times faster. By using this encoder on my application, the troughput was greatly improved. If you are interrested, I can submit a patch Pierre Maury - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts throwing away exceptions
Graham Leggett [EMAIL PROTECTED] wrote: Hi all, I ran into this problem a while back, worked around it, but now it is back. Something has gone haywire with a struts web application I am trying to debug. When accessing an URL, I get an HTTP 400 error, with the explanation The request sent by the client was syntactically incorrect ().. From my last experience with this problem, it turned out then to be a NullPointerException with no reason string - thus the empty string between the brackets. The problem is, the original exception has been thrown away by struts, so I have no clue where to start looking for the problem. What makes you think Struts is throwing away the exception? What was the stack trace for the NPE? David The cause of this issue is that all messages, including HTTP error codes, are being logged via commons-logging, which in this case has gone haywire along with the application. The correct behaviour IMHO in a situation where struts is in a broken state, is to pass the exception along with the HTTP error code to the servlet container, thus removing an enormous source of frustration for struts developers where a problem is reported seamingly by tomcat, but with no clue where the problem came from. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard
Re: [struts-chain] Where to now?
--- Craig R. McClanahan [EMAIL PROTECTED] wrote: Quoting Don Brown [EMAIL PROTECTED]: I added what I gathered was the last missing piece to struts-chain, file upload support. I'm really interested in doing whatever it takes to get this up and running as a viable alternative to the RequestProcessor. Cool! From here, I see the following needs to be done: - Unit tests (big one) Here is where the chain's nature is going to help -- it's pretty straightforward to write unit tests for each individual command, call the execute method, and evaluate the results, because most commands simply perform some transformation on the information in the Context being passed around. - Tiles support Definitely going to be needed for a production release. - Portlet implementation Yep. In my copious spare time :-) I'll try to download Pluto and start playing with this. - Documentation What is the status of commons-chain? Are there any outstanding issues that need to be sewn up? There are no outstanding bugs that I'm aware of. Unit test coverage is currently not all there, and the Portlet and Faces implementations of WebContext still need to be fleshed out. I think I will tackle the unit tests next. Tiles support should be pretty straightforward, some copy/paste. Craig had some ideas of how to support the Portlet API, which I'll leave to him until I can learn more about it. The documentation is the least important, at this stage, but it does help bring to light rough spots. Finally, what is that status on Struts 1.2? Could an early test version be put in for early adopters? One thing we'd talked about doing early in 1.2 was switching to commons-resources (which is also currently in the sandbox and would need to be promoted along with commons-chain). If we're going to do that (and I think we should), it should really be before the first 1.2 release. commons-resources is pretty solid as well, but a JDBC-based resources implementation included out of the box would be really really handy. -0 only because resources has been sitting for a while and I don't want to hold up Struts 1.2 for a feature that would be nice to have but isn't really necessary for a resources 1.0 release. IMHO, resources should plan on cleaning up any existing design issues and releasing 1.0. I really think we should ship Struts 1.2 with either resources or chain but not both. We'll end up with another 1.1 once we start including more than 1 major change per release. I don't have the time right now to get resources or chain included for Struts 1.2 so I won't veto however you want to proceed. David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Suggestion: way to execute code after form.validate(mapping, request) fails, but before forward to input
--- Mike Kienenberger [EMAIL PROTECTED] wrote:
I'm using Struts 1.1.
I want to execute code only if validation fails, but before the forward
to
the input action.
Unfortunately, it seems that RequestProcessor.processValidate() has
tightly-coupled these two activities, leaving no way for such activity
to be
triggered.
At first, I thought I could subclass RequestProcessor and set a boolean
variable before calling processValidate() and check it on doForward(),
executing my code if the variable was set, but this will probably fail
in a
multithreaded environment. Even if I could make this work by
temporarily
setting attributes on my request, it'd still be an ugly hack.
I don't see any reasonable solution to my problem other than subclassing
RequestProcessor, copying processValidate() into it, and making my
change
there, which seems likely to break after a struts upgrade.
I'd like to recommend that in some future struts version that
RequestProcessor.processValidate() provide a hook for executing code
between
failed validation and forwarding to the input mapping.
In fact, it seems to me that this whole section of code
==
// Has an input form been specified for this mapping?
String input = mapping.getInput();
if (input == null) {
if (log.isTraceEnabled()) {
log.trace( Validation failed but no input form
available);
}
response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
getInternal().getMessage(noInput,
mapping.getPath()));
return (false);
}
// Save our error messages and return to the input form if
possible
if (log.isDebugEnabled()) {
log.debug( Validation failed, returning to ' + input +
');
}
request.setAttribute(Globals.ERROR_KEY, errors);
if (moduleConfig.getControllerConfig().getInputForward()) {
ForwardConfig forward = mapping.findForward(input);
processForwardConfig( request, response, forward);
} else {
internalModuleRelativeForward(input, request, response);
}
==
should be moved to the equivalent of a
RequestProcessor.processValidateFailure() method which could then be
subclassed.
Sounds like a good candidate for a command in the future Struts Chain
reimplementation of the RequestProcessor.
David
-Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml
Vic, We are tired of your conspiracy theories, flames, gratuitous self-promotion, and generally poor behavior. Your conduct has been absurd and offensive to people that donate their valuable time to the ASF. Your actions on theserverside.com and the Jakarta general mailing list qualify, IMO, as grounds for banning you from the lists. You do not deserve promotion on any ASF sponsored site including Struts. Before composing your next flame I encourage you to consider how your behavior has affected the ASF community and start becoming a positive contributor. David --- Vic Cekvenich [EMAIL PROTECTED] wrote: This is what broke it: http://theserverside.com/home/thread.jsp?thread_id=22337 It was aleged that code was takem from someplace that was not allowing it and placing it into Apache code base! ASF seems to be saying we took the design and are re-implementing it. Whatever. Shame on you for ... aparently... supporting it. I guess it's good for comercial vendors such as Sun, but it is bad for Open Source. I think ASF and Sun are a bit to close. I guess another brick. .V Craig R. McClanahan wrote: Quoting Vic Cekvenich [EMAIL PROTECTED]: Was that called for Craig? Yep. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Conversion to ToStringBuilder
--- Craig R. McClanahan [EMAIL PROTECTED] wrote: Quoting David Graham [EMAIL PROTECTED]: I think we inherit the dependency on commons lang from some other component. Our use of lang's features is very limited and my preference is to keep it that way. Regardless, toString() is easy to implement without ToStringBuilder. Last time I looked, ToStringBuilder was the only dependency we have on commons-lang. I'd much rather do a little more work in our toString() methods and dump the dependency if that's actually the case, unless there's some compelling need for any of the other c-l methods. Craig We're using some of lang's String methods in the test cases because we're not on Java 1.4. David __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Conversion to ToStringBuilder
--- Norm Deane [EMAIL PROTECTED] wrote: Ok. The nice thing about ToStringBuilder is that it ensures consistency across all your toString methods and provides the ability to adopt a new toString style without changing a lot of code. I don't see the need for this. toString() implementations must vary depending on their use. For example, List implementations generally use [item1,item2] while other classes just want to output some debugging information. David -- Norm Deane MIS Consultant Vanderbilt University (615) 322-7855 [EMAIL PROTECTED] -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Thursday, November 06, 2003 10:26 AM To: Struts Developers List Subject: Re: Conversion to ToStringBuilder I think we inherit the dependency on commons lang from some other component. Our use of lang's features is very limited and my preference is to keep it that way. Regardless, toString() is easy to implement without ToStringBuilder. David --- Norm Deane [EMAIL PROTECTED] wrote: I was thinking about adding a toString method to ModuleConfigImpl that used ToStringBuilder but I noticed some of the other config objects have toString methods that do not use ToStringBuilder. Anyone object to me writing a patch that converts the existing toString methods to use ToStringBuilder and adding one to ModuleConfigImpl? --Norm -- Norm Deane MIS Consultant Vanderbilt University (615) 322-7855 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - 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] __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contributing Code
--- [EMAIL PROTECTED] wrote: It is my understanding (and please correct me if mistaken) that when one has modified/improved/extended some portion of Struts, it is to be submitted here for consideration. Thus, my little extension: I modified validator-rules.xml so that if a form field is specified as required in validation.xml which is a radio button in the HTML, the JavaScript will actually validate it. I read many differing opinions on whether or not one should validate radio buttons (always default one to checked was the usual answer) however I felt that should one wish to, one should be able to do such validation. You can open a bugzilla enhancement ticket for commons validator because all the javascript has moved over there. Attach any patches to the ticket and don't send them to the mailing list because they will get lost. David It has been tested in IE 6.0 and Mozilla Firebird 0.7, and I am hoping that further testing will reveal good browser compatibility. Forgive me if this is the wrong forum for such discussion. Best, Alvin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote]Disable bugs for Struts 1.0
+1 David --- Robert Leland [EMAIL PROTECTED] wrote: I would like to propose disabling filing of NEW bugs for Struts 1.0, I know BugZilla 2.16.3 can do this not sure about 2.14.2 Bugs filed against 1.0 are a waste of time for committers and for reporters. Only bugs filed against 1.1 final, or the nightly builds have any hope in being addressed. If there were patches included with the reciently reported 1.0 enhancements, I might feel differently. As it is NEW Struts 1.0 BugZilla reports are just Noise that I filter out. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 24202] - Javascript validation fails for single radio and single checkbox
--- [EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2003-10-31 15:27 --- You should never be rendering only a single radio button because it's a huge usability issue. The user can never uncheck a single radio button once they've checked it. In this case, you should probably be using a different form control like a select box. These are excellent points, and the question becomes is this boundary condition a useability should or a technical must. HTML spec is no help, I looked. It talks about sets, but doesn't define set as two or more. It also talks about this specific usability problem. I'm having horrible visions of someone doing a query driven voting application using radio boxes... Those aside, IMHO think the utility of having the trivial case handled in the framework is more useful than having application logic check for it, and is generally worth a useability tradeoff. I'm -0 on adding single radio button support to validator. I won't add it myself but won't stand in the way of someone who wants to spend the time. Good usability is *always* a requirement on my projects and never takes a backseat to laziness. Poor usability is one of my biggest pet peeves on major websites. IMO, the correct thing to do in this case is to not display a form control at all. There's only one choice so just display that choice and tell the user that's what they're getting. David Ernie Argetsinger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] conditionals again
--- Greg Reddin [EMAIL PROTECTED] wrote: The next step might be to try and integrate something like Struts Workflow and/or Tiles into the RequestProcessor chain and see what the various Chains look like. I get about a day every three weeks to look at this, but Tiles is what I'm working on. I'll share early and often. BTW, there's about five ways to submit code here. Would you prefer an email attachment, a bugzilla ticket, or some other way? Bugzilla with attached cvs diff -u formatted patches. David Though, regardless of what happens with the Struts RequestProcessor (a *very* complicated bit of business logic), I'm finding Chain to be a very useful interface to an application's business layer. Yes, I'm looking that direction as well. Greg - 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]
Re: [chain] conditionals again
--- Greg Reddin [EMAIL PROTECTED] wrote: David Graham wrote: --- Greg Reddin [EMAIL PROTECTED] wrote: BTW, there's about five ways to submit code here. Would you prefer an email attachment, a bugzilla ticket, or some other way? Bugzilla with attached cvs diff -u formatted patches. But, this is new stuff, nothing to diff... Then you would attach the .java files. David Greg - 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]
Re: Deprecating DiskMultipartReqwuestHandler and friends
+1 for deprecating. David --- Martin Cooper [EMAIL PROTECTED] wrote: Hi folks, Any objection to deprecating DiskMultipartRequestHandler and its associated classes? This was the default file upload handler in Struts 1.0, but was replaced by CommonsMultipartRequestHandler for 1.1 and beyond. It was, and is, buggy, and I'm sure nobody has any interest in maintaining it now that we're using Commons FileUpload to do the heavy lifting. Just asking up front so that I don't have to go back and remove a boatload of deprecations if it turns out that somebody wants to keep it. ;-) -- Martin Cooper - 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]
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]
RE: XMLEncoder class
http://www.google.com/search?q=java.beans.XMLEncoder David --- Mike Jasnowski [EMAIL PROTECTED] wrote: Didn't you just answer your own question? -Original Message- From: Zakaria khabot [mailto:[EMAIL PROTECTED] Sent: Thursday, October 09, 2003 11:52 AM To: Struts Developers List Subject: XMLEncoder class Hi wich package contains the class java.beans.XMLEncoder thanks Zakaria KHABOT Ingénieur d'état Réseaux informatiques MFIE/CGED Tel : +212 62 46 10 29 E_mail : [EMAIL PROTECTED] - 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]
Re: Possible Struts/StrutsTestCase bug
--- Mark McBride [EMAIL PROTECTED] wrote:
I may have found a problem using Struts/StrutsTestCase with OC4J(9.0.4).
Background: I'm running a StrutsTestCase that works in Resin 2.x but
when
ran in OC4J I get a NullPointerException from
org.apache.struts.util.RequestUtils.java line 1806. The problem I found
with both the RequestUtils.java and CactusStrutsTestCase.java are
illustrated below.
The problem can be found in two places. The first is in
CactusStrutsTestCase.java line 417:
String moduleName = (String)
request.getAttribute(Common.INCLUDE_SERVLET_PATH);
if (moduleName.endsWith(/))
moduleName = moduleName.substring(0,moduleName.lastIndexOf(/));
In resin 2.X this runs correctly with moduleName being initialized to
even if the attribute is not found.
In oc4j 9.0.4 request.getAttribute returns null when an attribute is
not
found. When moduleName.endsWith gets executed a NullPointerException is
thrown.
The second is in org.apache.struts.util.RequestUtils.java introduced in
line 1783 blows up on line 1806:
On line 1783 (same fundamental problem as the first error):
String matchPath = (String)
request.getAttribute(RequestProcessor.INCLUDE_SERVLET_PATH);
// matchPath is set to in resin matchPath is null in oc4j
if (matchPath == null) {
matchPath = request.getServletPath();
}
return getModuleName( matchPath, context);
Both calls to request.getXXX return an empty string in resin. In oc4j
null
is returned.
The error is surfaced on line 1806:
while (prefix.equals() ((lastSlash = matchPath.lastIndexOf(/))
0)) {
Since the call to getModuleName passes in null, matchPath.lastIndexOf
throws a NullPointerException.
Good news is that this is open-source and I can hack the code for myself
=). I'm curious of all the other sections of code in struts that make
the
assumption that the request object will return an instantiated object
and
not null.? It appears that the servlet 2.3 specification specifies
that
returning null is the correct servlet implementation.
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletRequest.html#getAttribute(java.lang.String)
What is the best way to file bugs for both struts and strutstestcase?
Struts bugs are entered into bugzilla: http://nagoya.apache.org/bugzilla/
StrutsTestCase is an independent SourceForge project.
Both of the containers you mentioned are non-free which really limits what
we can do to test the problem. I believe the majority of us are using
Tomcat because it's the free reference implementation of the Servlet and
JSP specs. Tomcat should implement the specs *exactly* so if it fails
there, it's most likely a Struts bug.
David
Thanks in advance!
-Mark
__
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]
Re: The Forrest Option
--- Ted Husted [EMAIL PROTECTED] wrote: Don Brown wrote: Further, deciding between Forrest and Maven isn't an either/or situation. There exists a Forrest plugin for Maven and it would be easy to integrate Maven's reports into a Forrest site build. .../ If we did decide to go with Forrest, I'm willing to convert the old site over and help handle any integration. I'm most definately not an expert at Forrest, but am familiar with Cocoon and thankfully, Forrest is pretty easy. +1 This sounds like a nice stepping stone. We can try Forrest now and migrate the build to Maven as soon as someone is ready to volunteer for that. Outside of the Jakarta Commons Sandbox, Forrest and Maven are equally popular among other Apache products. Using both might be the best of both worlds. Or it may be a complete nightmare. So then we would have Forrest, Maven, and Ant builds all competing for attention. I am definitely against using multiple build processes; let's just pick one and stick with it. The Forrest features Don mentioned aren't significant to me and I'm already familiar with Maven so I'm leaning towards Maven but I really don't care as long as the build is as easy as maven jar or equivalent. But please let's not try to maintain multiple build processes. David -Ted. - 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]
Re: The Forrest Option
--- Robert Leland [EMAIL PROTECTED] wrote: Don, I have one request and that is to leave the existing maven files in place since they do currently generate a web site with the reports. I must be confused with the several projects I'm working on. So, Maven is already setup in Struts to run the builds? If so, why are we going to add Forrest to the builds? Why not just start building the site and distro with Maven? David Craig R. McClanahan wrote: Don Brown wrote: I know the discussion on whether to use Forrest or Maven to generate the Struts website was a few weeks back, but unfortunately, at the time, I was too busy to participate. I'd like to lay out a case for Forrest, not to insist Struts uses it, but rather to make sure the decision is made with all the available information. In short, Forrest offers these benefits over Maven's website generation: - Multiple output formats including PDF and HTML - SVG to PNG rendering - Built for handling and aggregating multiple XML sources like RRS (soon wiki and Docbook) - Power and features of Cocoon including charting, web services integration, scripting support, etc. Further, deciding between Forrest and Maven isn't an either/or situation. There exists a Forrest plugin for Maven and it would be easy to integrate Maven's reports into a Forrest site build. To me, the key feature of Forrest is the first one listed, multiple outputs. This is especially useful for documentation as PDF is much better than HTML for printing for the many users that like hard copies. Finally, Forrest content is built to be presented in not only multiple output formats, but multiple skins. To demonstrate this, I've quickly redone the Struts site into Forrest format (which is very similiar to the current format thanks to the xhtml work of late). I've only converted the menu and the main page, which should be sufficient. Please note, this examples are not polished and only serve to demonstrate the skinability of Forrest. Krysalis style: http://www.twdata.org/dakine/site/ Avalon/Tigris style: http://www.twdata.org/dakine/site1/ Forrest/XML Apache style: http://www.twdata.org/dakine/site2/ If we did decide to go with Forrest, I'm willing to convert the old site over and help handle any integration. I'm most definately not an expert at Forrest, but am familiar with Cocoon and thankfully, Forrest is pretty easy. Looking at the potential here, I'm inclined to suggest we accept Don's offer to help set this up -- although perhaps at first in a standalone directory structure that can be undone if we discover that we don't like it. One advantage is that we can do it without having to migrate the build system to Maven first. As for skins, I sure like the Avalon/Tigris or Krysalis examples, and sure wonder why the Forrest developers chose the native style they ship with, when they could do something as nice looking as either of these. But, if I understand what you're saying, skins is essentially a runtime (when you're generating the HTML) choice; we don't have to make an irrevocable decision at any point in time. Don Craig - 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] __ 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]
Re: The Forrest Option
--- Ted Husted [EMAIL PROTECTED] wrote: Chris Gastin wrote: I have to agree with David. Lets find one way to do it and make it simple, if a build process can be. I have worked a little with Maven, and it seems tobe simple. I am not knocking Forrest. I have not had a chance to look into it. If that is more simple than Maven then I am all for it. Lets not make the build process this awful process. I think everyone would agree with that. We're not talking about the build process as a whole. The Forrest Option refers only to website maintenance and documentation. Since Don's ready to sign-up for Forrest, we should start by trusting his judgment and be ready to give this a try. That's what it means to be a Committer. Make the decision, do the work. At this point, no one is raising their hand and offering to migrate us to Maven. Until someone does, Maven does not seem like a valid objection. Rob mentioned something about Struts being setup for Maven already and I asked for clarification. If that's true then I see no point in complicating things with another build tool. Also, it seems that Maven in some ways is a superset of Forrest functionality. It handles the website plus the jar builds. The more tools involved means it's harder to understand the build process which limits the number of people willing to put up with it and work on Struts. My personal goal (and I hope the group's as well) is to have *one* easy to use tool that builds all of Struts. I don't care if this is Ant, Maven, or Forrest as long as it's only one of them. David Though, a valid, technical objection would be that the website and the build (except for the current Cactus snafu) ain't broke, so we don't need to fix it. Steve's got everything running as valid XHTML. We're still using the original Apache look, but then so is the vast majority of other Apache projects. If we dusted off the struts-lib distribution (which appeared and disappeared during the last beta cycle), the quick-start concerns would be answered. Certainly, it would make sense to start new development on Forrest and/or Maven. If we spun off taglibs or rolled up our sleeves on 2.0, then we'd definitely want to make a decision there. (Based primarily on who was willing to do the work.) And, we do have Forrest running on the SourceForge site, so things like RSS feeds and WikiDocs could be tried there first to see how helpful they really are. (I must admit, I'm intrigued.) -Ted. - 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]
Re: The Forrest Option
--- Don Brown [EMAIL PROTECTED] wrote: On Wed, 1 Oct 2003, David Graham wrote: snip / Rob mentioned something about Struts being setup for Maven already and I asked for clarification. If that's true then I see no point in complicating things with another build tool. Also, it seems that Maven in some ways is a superset of Forrest functionality. It handles the website plus the jar builds. Forrest is not a build tool. If we went with Maven, Forrest would just be another plugin, just like most people use the default site building plugin. The more tools involved means it's harder to understand the build process which limits the number of people willing to put up with it and work on Struts. My personal goal (and I hope the group's as well) is to have *one* easy to use tool that builds all of Struts. I don't care if this is Ant, Maven, or Forrest as long as it's only one of them. I agree, but if a Forrest plugin for Maven is used, you still use one tool to build all of Struts. Great, that sounds like we can get the features of Forrest while still using one tool. Thanks for the explanation. David Don David Though, a valid, technical objection would be that the website and the build (except for the current Cactus snafu) ain't broke, so we don't need to fix it. Steve's got everything running as valid XHTML. We're still using the original Apache look, but then so is the vast majority of other Apache projects. If we dusted off the struts-lib distribution (which appeared and disappeared during the last beta cycle), the quick-start concerns would be answered. Certainly, it would make sense to start new development on Forrest and/or Maven. If we spun off taglibs or rolled up our sleeves on 2.0, then we'd definitely want to make a decision there. (Based primarily on who was willing to do the work.) And, we do have Forrest running on the SourceForge site, so things like RSS feeds and WikiDocs could be tried there first to see how helpful they really are. (I must admit, I'm intrigued.) -Ted. - 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] __ 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]
Re: The Forrest Option
--- Ted Husted [EMAIL PROTECTED] wrote: David Graham wrote: Rob mentioned something about Struts being setup for Maven already and I asked for clarification. If that's true then I see no point in complicating things with another build tool. Also, it seems that Maven in some ways is a superset of Forrest functionality. It handles the website plus the jar builds. The more tools involved means it's harder to understand the build process which limits the number of people willing to put up with it and work on Struts. My personal goal (and I hope the group's as well) is to have *one* easy to use tool that builds all of Struts. I don't care if this is Ant, Maven, or Forrest as long as it's only one of them. David Yes, but the goals around here are achieved by people willing to do the work. I agree with you but it would be nice to have some kind of consensus around the direction the build is going. I trust Don's judgement that Forrest is a good tool to use but I didn't want the build to increase in complexity. We can apparently plug Forrest into a Maven build which I think is great. There's only so much time we each have to spend on Struts. I'd rather not spend much time learning the build process. David If Rob wants to do the work of migrating to Maven, for whatever reason, that's fine with me. A lot of people I respect use Maven, it can't suck that badly. If Don wants to do the work of migrating to Forrest, that's fine too. A lot of people I respect use Forrest, so it can't suck that badly either. But, if we're just looking for a one-tool solution that builds all of Struts, we already have one. To change a page in the docs, you edit the corresponding XML page. To add to the menu, edit the project.xml for that directory. Run the Ant target. Done. If we want Struts to be even easier to build for newbies, then we should bring back the struts-lib distribution. Download that with the source, and you were ready to rock. -Ted. - 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]
Re: [Validator] FieldChecks Serializable?
I don't believe there is any reason it needs to be serializable because objects of that class are never created and saved in other objects. We're just in the habit of making things Serializable in case they go into the session. David --- Brandon Goodin [EMAIL PROTECTED] wrote: I asked this question on the user list yesterday and received no reply. So I figured this is the more appropriate place to ask. Why does org.apache.struts.validator.FieldChecks implement Serializable when it has nothing but static methods and static final instance variables? Just curious. Brandon - 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]
Re: Maven is Wicked!
--- PILGRIM, Peter, FM [EMAIL PROTECTED] wrote: I have been very busy unable to catch with Struts Dev list. Anyway I was fighting with Turbine/JCS trying to compile with Ant, I was literally beating myself up looking at these dependencies, then I read in a forum somewhere Use Maven. I used Maven. Oh my goodness. Whoop! There it is. Why does Struts not a build tool like Maven yet. Because you haven't supplied patches to change the build to use it :-). I agree with you, Maven is pretty neat. David -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - 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]
Re: The Forrest Option
I haven't used Forrest but Maven was pretty darn easy to get going. All I had to do was download it and run maven jar or maven site:generate. It handled all of the dependencies by itself. Assuming Forrest is as easy to use as Maven, I don't really care which we use. I do prefer to maintain a site LF that is fairly consistent with other Jakarta projects so the Avalon style linked below looks good. David --- Don Brown [EMAIL PROTECTED] wrote: I know the discussion on whether to use Forrest or Maven to generate the Struts website was a few weeks back, but unfortunately, at the time, I was too busy to participate. I'd like to lay out a case for Forrest, not to insist Struts uses it, but rather to make sure the decision is made with all the available information. In short, Forrest offers these benefits over Maven's website generation: - Multiple output formats including PDF and HTML - SVG to PNG rendering - Built for handling and aggregating multiple XML sources like RRS (soon wiki and Docbook) - Power and features of Cocoon including charting, web services integration, scripting support, etc. Further, deciding between Forrest and Maven isn't an either/or situation. There exists a Forrest plugin for Maven and it would be easy to integrate Maven's reports into a Forrest site build. To me, the key feature of Forrest is the first one listed, multiple outputs. This is especially useful for documentation as PDF is much better than HTML for printing for the many users that like hard copies. Finally, Forrest content is built to be presented in not only multiple output formats, but multiple skins. To demonstrate this, I've quickly redone the Struts site into Forrest format (which is very similiar to the current format thanks to the xhtml work of late). I've only converted the menu and the main page, which should be sufficient. Please note, this examples are not polished and only serve to demonstrate the skinability of Forrest. Krysalis style: http://www.twdata.org/dakine/site/ Avalon/Tigris style: http://www.twdata.org/dakine/site1/ Forrest/XML Apache style: http://www.twdata.org/dakine/site2/ If we did decide to go with Forrest, I'm willing to convert the old site over and help handle any integration. I'm most definately not an expert at Forrest, but am familiar with Cocoon and thankfully, Forrest is pretty easy. Don - 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]
RE: XHTML Web site updates
--- Steve Raeburn [EMAIL PROTECTED] wrote: -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: September 29, 2003 3:46 AM To: Struts Developers List Subject: Re: XHTML Web site updates +1 as to the new sidebar approach. I'm quite pleased with the way all this turned out. I hope you'll also like the new table formatting for taglibs and task lists :-) And now the downside to using tableless css webpages... Take a look at the taglibs api pages in mozilla. The borders don't show up quite right (maybe a mozilla bug?). Also, the new ApacheCon image overwrites the content to the right of it in Opera (the borders are correct though :-). We need to be more sensitive to webpage changes now that we're using html that browsers may not implement correctly or consistently. These particular issues are no big deal though. David I should just do this myself, but if you had a moment, could you slip in a link to ApacheCon at the top of our sidebar, like the one at the Jakarta site. They've asked all the Apache projects to do this. Technically, we're not the project, Jakarta is, but since we kinda get our share of hits ... Done. I also took the opportunity to tidy up the web site files, removing the obsolete versions that were still kicking around. The web site should now match what's in CVS, with the addition of the 1.02 UserGuide and Javadocs. In case I've been overzealous, I've archived the old site at http://cvs.apache.org/~sraeburn/site-archive-20030929/ Regarding the archived 1.02 docs - there doesn't seem to be a link to them anywhere. Shall I add one? Also, we don't have the current release (1.1) docs on the site which might be confusing for some users. Do we want to maintain docs for the current version as well, and add appropriate links? Steve -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] __ 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]
RE: XHTML Web site updates
--- Steve Raeburn [EMAIL PROTECTED] wrote: -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: September 29, 2003 12:08 PM To: Struts Developers List Subject: RE: XHTML Web site updates And now the downside to using tableless css webpages... Take a look at the taglibs api pages in mozilla. The borders don't show up quite right (maybe a mozilla bug?). I'm not sure what you mean about the borders. They look ok in Moz 1.5a on Windows. Here's what I'm seeing ... http://cvs.apache.org/~sraeburn/tables.gif It is intentional that the table border is slightly thicker than the internal cell borders. If you don't like it, that's another discussion :-) It must be a problem in the windows mozilla version I was using. It looks normal with the linux version. The borders would disappear for streches and then return to normal. Also, the new ApacheCon image overwrites the content to the right of it in Opera (the borders are correct though :-). I've altered the layout so it should be able to accommodate the ApacheCon logo down to smaller screen sizes. Should also correct the IE float problem that Mike mentioned. We need to be more sensitive to webpage changes now that we're using html that browsers may not implement correctly or consistently. These particular issues are no big deal though. David More of a screen size issue than a browser compatibility issue. You guys need to put in requisitions for bigger monitors and I need to make sure I check at 800x600 :-) Thanks for spotting the problem. Actually, I was viewing it on a massive 21 inch screen at a decent resolution at the time :-). David Steve - 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]
Re: [VOTE] Accept patches to make html taglib more extensible
--- Sgarlata Matt [EMAIL PROTECTED] wrote:
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.
+1. I've done some checking on this in the past but another round is
probably needed.
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.
-1. As I've stated previously, I don't think the Struts tags should
support emitting non-standard HTML.
David
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]
__
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]
