Re: Counting down to the 1.2.1 release (was RE: Making Struts Build Easier)
On Wed, 24 Mar 2004 22:33:50 -0800 (PST), Martin Cooper wrote: 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. How about if we shoot for the Validator this weekend and then Strus 1.2.1 next weekend. That would give us a chance to update the site for some of the new TLP changes and give Martin a chance to do his taxes :) -Ted. - 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?)
On Fri, 26 Mar 2004, Ted Husted 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. Upgrading the container, though, is only half the story. That will allow the developers to use newer technologies in new parts of the application, but doesn't necessarily mean that the budget will be available to migrate existing large applications to a different set of JSP tags. That's where the real rub lies, IMHO. -- Martin Cooper 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Test Test
Testing new mail setup ... sorry for the noise. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27831] - Struts runs on Trifork 3.3 with No additional steps required
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27831. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27831 Struts runs on Trifork 3.3 with No additional steps required [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-03-28 04:03 --- Done. Thank you. (Change will not appear on the website until the next time it is updated) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27961] - struts.jsl patch so that Maven build will create taglib documentation pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27961. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27961 struts.jsl patch so that Maven build will create taglib documentation pages [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2004-03-28 05:10 --- Marking as enhancement since Maven is not yet the official build mechanism. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27964] - struts.jsl patch so that Maven build includes contributors box
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27964. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27964 struts.jsl patch so that Maven build includes contributors box --- Additional Comments From [EMAIL PROTECTED] 2004-03-28 05:10 --- Marking as enhancement since Maven is not yet the official build mechanism. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27964] - struts.jsl patch so that Maven build includes contributors box
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27964. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27964 struts.jsl patch so that Maven build includes contributors box [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2004-03-28 05:11 --- Marking as enhancement since Maven is not yet the official build mechanism. - 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?)
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. 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]
StrutsContext/ConfigHelper (was Re: Making Struts Build Easier)
At 7:00 AM -0500 3/26/04, Ted Husted wrote: 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. I love this. I actually hadn't seen it before. We had talked briefly a few days ago about a StrutsContext as the argument to Action.execute() and Renderer.render() -- but it looks to me like this class is everything I would expect that one to be... Unless it was assumed that StrutsContext would implement o.a.c.chain.Context, which may be a good idea -- haven't thought about it that much. Where is this actually being used now? Just in the Velocity tools? I think the struts-chain stuff might be clearer if they all passed a ConfigHelper instance along instead of each needing to know the context key under which various items would be found. I'm assuming from the design of the struts-chain commands that someone may have thought there was a good reason to keep that more flexible -- perhaps for interaction with unforeseen commands -- but sometimes I think that makes it more complicated than it needs to be. 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]
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]
DO NOT REPLY [Bug 27943] - resource files for non-default modules not loading correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27943. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27943 resource files for non-default modules not loading correctly [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-03-26 15:20 --- The fix posted for bug #27332 fixed this problem. *** This bug has been marked as a duplicate of 27332 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27332] - The bundle attr do not have subapp resolution.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27332. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27332 The bundle attr do not have subapp resolution. [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-03-26 15:20 --- *** Bug 27943 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27384] - Add support for other keys in saveMessages functions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27384. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27384 Add support for other keys in saveMessages functions --- Additional Comments From [EMAIL PROTECTED] 2004-03-26 15:50 --- Greg, If you type in the word bug in front of 26668, e.g., bug 26668, bugzilla makes it a hyperlink to that bug report. At least, I hope so. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26668] - errors messages tags enhancement: make them show only errors/messages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26668. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26668 errors messages tags enhancement: make them show only errors/messages --- Additional Comments From [EMAIL PROTECTED] 2004-03-26 15:51 --- For easy access, here is a direct link to bug 27384. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FIFO ordering of ActionErrors
I sent this to struts-user with no responses. I thought I would try here
before posting a bug report.
Hi listers,
I have been working on this issue for the last couple of days but haven't
found any satisfactory answers through the usual channels (mailing list
archives, API, and some source code perusal as well).
As I understand it, post struts 1.1, ActionErrors were supposed to keep
their FIFO ordering. I have tried a nightly from 2004-01-27 and just
recently 2004-03-23 and here's what I experience:
* all of my forms extend ValidatorForm
* In one of those forms I override the validate method which first makes a
call to super.validate() and captures the errors returned from it
* If the above call returns any errors, I wanted to stick a prefix
(or suffix) message in front of the errors shown by validator. For the
sake of simplicity, the rest of discussion will focus on adding a suffix
message (as its a lot easier to describe how I added the suffix message).
So, instead of seeing the regular (boring :-)) messages from validator
like:
* 'Postal Code' is a required field.
* 'City' is a required field.
the user would instead see:
* 'Postal Code' is a required field.
* 'City' is a required field.
* Invalid and/or incomplete input. Please provide the correct information
as instructed:
Here's a look at the errors object from the debug log before the insertion
of the suffix message.
{
postalCode=[errors.required[Postal Code, null, null, null]],
city=[errors.required[City, null, null, null]]
}
(BTW, to make the message appear before the other ones as a prefix, I had
to create a new errors object, add the prefix error and then add the
original erorrs to it).
So the following code line example just tries to add an ActionMessage
with resource errors.validator.prefix [sic] at the end.
So, after making my super.validate() call, I added a call to:
errors.add(ActionMessages.GLOBAL_MESSAGE,
new ActionMessage(errors.validator.prefix));
I would have expected the above line to just add a 3rd property at the
end. Unfortunately, the errors object now looks like:
{
postalCode=[errors.required[Postal Code, null, null, null]],
org.apache.struts.action.GLOBAL_MESSAGE=[errors.validator.prefix[]],
city=[errors.required[City, null, null, null]]
}
(Notice the GLOBAL_MESSAGE property stuck in the middle)
With the result being that the user sees:
* 'Postal Code' is a required field.
* Invalid and/or incomplete input. Please provide the correct information
as instructed:
* 'City' is a required field.
Did I understand the FIFO capability of ActionErrors incorrectly, or is
there a bug in my code (or struts)? If this helps any, postalCode is one
of the only few fields that I have discovered in all of my forms which
bubbles up to the top.
Any help is appreciated.
Thanks,
--
Haroon Rafique
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
FW: html:text -- value attribute won't take rtexprvalue
Hi, I'm new to Struts and have searched without luck on this one: I have an html:text ... that I'm simply trying to put a runtime expression into, like % String rtexpr = bob; % html:text property=searchType value=%=rtexpr % And instead of interprestting the rtexprvalue bob, it actually displays the string %=rtexpr % as the value on the screen. If I just type a string into the value field, like this: html:text property=searchType value=please it works just fine. I looked into struts-html.tld and the value parameter of the text tag is set up to accept runtime expression values, so I don't know what's going wrong. The really strange and frustrating part is that if I try the line I really need to use: html:text property=searchType value=%=request.getAttribute(searchType) % The page breaks on this error: Attribute searchType has no value Totally frustrated:[ I have no idea what I'm doing wrong. Can anyone help? Thanks!, Jim [EMAIL PROTECTED] This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: html:text -- value attribute won't take rtexprvalue
From: Bender, James [mailto:[EMAIL PROTECTED]
I'm new to Struts and have searched without luck on this one:
I have an html:text ... that I'm simply trying to put a runtime
expression into, like
% String rtexpr = bob; %
html:text property=searchType value=%=rtexpr %
And instead of interprestting the rtexprvalue bob, it
actually displays
the string %=rtexpr % as the value on the screen. If I
just type a
string into the value field, like this:
html:text property=searchType value=please
James, did you post this on struts-user yet? Unless there's more to it
than I initially see, I think it belongs over there rather than the
developers list.
If I did it right, the reply-to is set there.
The usual way to do this is to populate the Form property in your Action
code, and then when you forward to the JSP containing the html:text
tag, Struts will render the HTML for the form element, including the
value. Note that Struts automatically populates the form from the
request attributes when the user submits the form. I'm not sure whether
you're trying to pre-populate, or to redisplay user input.
This assumes that you are forcing users to go through the Action (not
letting them go directly to the JSP). More information will help us
here, I'm avoiding answering your actual question since you did say
you're new to Struts...
If you do find yourself needing to pull things out of the
request/session, the Struts-EL tags will be useful-- html-el:text
property=searchType value=${someVal} /
--
Wendy Smoak
Application Systems Analyst, Sr.
ASU IA Information Resources Management
-
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?)
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 - 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]
Re: StrutsContext/ConfigHelper (was Re: Making Struts Build Easier)
On Fri, 26 Mar 2004 07:56:11 -0600, Joe Germuska wrote: I love this. I actually hadn't seen it before. We had talked briefly a few days ago about a StrutsContext as the argument to Action.execute() and Renderer.render() -- but it looks to me like this class is everything I would expect that one to be... Unless it was assumed that StrutsContext would implement o.a.c.chain.Context, which may be a good idea -- haven't thought about it that much. Where is this actually being used now? Just in the Velocity tools? I think the struts-chain stuff might be clearer if they all passed a ConfigHelper instance along instead of each needing to know the context key under which various items would be found. I'm assuming from the design of the struts-chain commands that someone may have thought there was a good reason to keep that more flexible -- perhaps for interaction with unforeseen commands -- but sometimes I think that makes it more complicated than it needs to be. Joe The ConfigHelper was never actually used by Velocity Tools, except to show where all the bodies were buried. I very much doubt that anyone is actually using it right now. Like a lot of things, it's just continuation of many things that we've done all along. We already put the ActionMapping in the request. This puts Struts in the request :) I've renewed development of this class over to Commons Chain, where work has begun on a Struts MailReader for Commons Chain example application. http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/chain/apps/mailreader/ I think in the 1.3 era, where Commons Chain is part of the core, we could in fact base an ActionContextBase on a.o.c.chain.ContextBase. There could also be a clean-room interface that exposed things like Messages and Mappings and Validators (oh my!), to a business Command, but not the http interface or contexts. -Ted. On Fri, 26 Mar 2004 07:00:57 -0500, Ted Husted 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.) - 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?)
...
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 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?)
Nope. logic:match does substring matching.
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/
-
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?)
You're right (as usual ;))
I was using the String taglib in addition to the JSTL 1.0 taglib to do
the test. (duh)
Although looking at it now.. there isnt any support for begin and ends
in that neither.
-Tim
Kris Schneider wrote:
Nope. logic:match does substring matching.
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: StrutsContext/ConfigHelper (was Re: Making Struts Build Easier)
Quoting Joe Germuska [EMAIL PROTECTED]: At 7:00 AM -0500 3/26/04, Ted Husted wrote: 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. I love this. I actually hadn't seen it before. We had talked briefly a few days ago about a StrutsContext as the argument to Action.execute() and Renderer.render() -- but it looks to me like this class is everything I would expect that one to be... Unless it was assumed that StrutsContext would implement o.a.c.chain.Context, which may be a good idea -- haven't thought about it that much. Where is this actually being used now? Just in the Velocity tools? I think the struts-chain stuff might be clearer if they all passed a ConfigHelper instance along instead of each needing to know the context key under which various items would be found. I'm assuming from the design of the struts-chain commands that someone may have thought there was a good reason to keep that more flexible -- perhaps for interaction with unforeseen commands -- but sometimes I think that makes it more complicated than it needs to be. Wouldn't the context object used by struts-chain contain everything you might need in Velocity-land? It would be a shame to invent a second context object if we're going that direction anyway and it can meet your needs. Joe Craig - 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?)
With JSTL 1.1 (JSP 2.0), you get a set of string manipulaton functions (which
Peter was referring to) that includes:
fn:contains(string, substring)
fn:startsWith(string, prefix)
fn:endsWith(string, suffix)
In addition, you also get a length function that operates on collections and
strings:
fn:length(input)
Where input can be: String, array of objects or primitives, Collection,
Iterator, Enumeration, or Map.
Quoting Tim Chen [EMAIL PROTECTED]:
You're right (as usual ;))
I was using the String taglib in addition to the JSTL 1.0 taglib to do
the test. (duh)
Although looking at it now.. there isnt any support for begin and ends
in that neither.
-Tim
Kris Schneider wrote:
Nope. logic:match does substring matching.
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
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: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
+1. Just keeping the functionality facts straight...
Quoting David Graham [EMAIL PROTECTED]:
--- 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
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Quoting Peter A. Pilgrim [EMAIL PROTECTED]: 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? The h:message and h:messages tags are both JSF components, so they require a JSF implementation -- but *any* JSF implementation will do, because they are standard. 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. In this particular case, you'll note that I included s:message in the Struts-Faces integration library. It is a JSF component, but it has semantics like the html:message tag (for example, it looks things up in a Struts MessageResources object instead of resource bundles the way that the standard JSF components work). For the same reason, I included JSF-ized versions of html:base, html:errors, html:form, html:html, html:javascript, html:stylesheet, and bean:write in order to make transition of existing apps very easy. If there's any useful tags I missed that don't already have obvious JSF replacements, I'd be happy to add them as well. 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 Superceded is definitely true for new development. It would be unfair, though, to existing applications to drop them in a 1.x release, however, because it would prevent existing apps from being to upgrade without an expensive rewrite. 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
Re: FIFO ordering of ActionErrors
On Today at 11:15am, HR=Haroon Rafique [EMAIL PROTECTED] wrote: HR I sent this to struts-user with no responses. I thought I would try HR here before posting a bug report. HR I have found the problem in src/share/org/apache/struts/action/ActionMessages.java and I'll be posting a bug report shortly. -- Haroon Rafique [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27992] New: - FIFO ordering in ActionErrors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27992.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27992
FIFO ordering in ActionErrors
Summary: FIFO ordering in ActionErrors
Product: Struts
Version: Nightly Build
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Controller
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I had posted to the struts-user list at:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg97016.html
and struts-dev list at:
http://marc.theaimsgroup.com/?l=struts-devm=108031774812299w=2
I think I may have discovered a bug in
src/share/org/apache/struts/action/ActionMessages.java
ActionMessages are supposed to have FIFO ordering (as evidenced by the
presenence of property iOrder in the class ActionMessageItem). However, I
discovered a case whereby the ActionMessages would lose their order.
Let's say validator returned some errors (I'll only show property keys and their
order):
{postalCode[Order=1],number[Order=0]}
As you can see they are in a weird order which is okay since its a HashMap and
order is not guaranteed.
Now, if I created another ActionErrors object with only 1 message:
{org.apache.struts.action.GLOBAL_MESSAGE[Order=0]}
and then tried to add using something like:
newErrors.add(oldErrors);
it would correclty keep the order and it would become something like:
{postalCode[Order=1],org.apache.struts.action.GLOBAL_MESSAGE[Order=0],number[Order=2]}
So, struts is behaving correctly so far. It kept the order of the GLOBAL_MESSAGE
0 and created higher sequential order numbers for the other 2 added properties.
However, unfortunately there are several other places later on in the struts
sequence where an empty ActionErrors object is combined with what was returned
from the validate() method. And this is where, automagically, the Order numbers
start their sequencing all over again and become:
{postalCode[Order=0],org.apache.struts.action.GLOBAL_MESSAGE[Order=1],number[Order=2]}
The reason for this is that the properties() method only sends back an iterator
to the unsorted HashMap. Instead it should send something back which is sorted
according to the order of the properties (similar to how its done in the get()
method).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27992] - FIFO ordering in ActionErrors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27992. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27992 FIFO ordering in ActionErrors --- Additional Comments From [EMAIL PROTECTED] 2004-03-26 20:34 --- Created an attachment (id=11014) patch to fix the FIFO ordering of ActionMessages - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StrutsContext/ConfigHelper (was Re: Making Struts Build Easier)
On Fri, 26 Mar 2004 11:32:20 -0800, Craig R. McClanahan wrote: Quoting Joe Germuska [EMAIL PROTECTED]: Wouldn't the context object used by struts-chain contain everything you might need in Velocity-land? It would be a shame to invent a second context object if we're going that direction anyway and it can meet your needs. I'm not sure that Joe's a Velocity Tools user himself. I believe he was just picking up on my reference. Right now, the Velocity Tools expose several different objects that roughly equate to the Struts taglibs. So you can expose the tool you need, in the same way you can import the taglib you need. Taken together, these tools have most of the functionality that we might find in a full-featured ActionContext. Another term for such tools would be view helpers. Nothing fancy. Just a JavaBean, really. There's a nifty loading mechanism though, so you load up whatever tools of your own that might be needed. (Say, a database access tool.) If an ActionContext were exposed in the request, it's true that something like the Velocity Tools for Struts probably wouldn't be needed. A surprising amount of functionality would also be exposed to JSLT, JSF, and any other view technology out there. (Say, Jelly for example.) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27992] - FIFO ordering in ActionErrors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27992. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27992 FIFO ordering in ActionErrors --- Additional Comments From [EMAIL PROTECTED] 2004-03-26 20:40 --- The above attachment is my naive attempt at fixing the problem of FIFO ordering of ActionMessages. Few things to note: * I created a new class called PropertyOrder (no javadoc comments yet :-() * added a new Comparator propertyComparator * modified properties() method to returned a sorted set of properties based on their order Like I said, this is my first patch for struts, so please be gentle. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27992] - FIFO ordering in ActionMessages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27992. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27992 FIFO ordering in ActionMessages --- Additional Comments From [EMAIL PROTECTED] 2004-03-26 21:01 --- I'll admit I'm not giving this my undivided attention, but if you just want to use a map that returns an entrySet iterator in FIFO order, couldn't you use Commons Collections SequencedHashMap? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27992] - FIFO ordering in ActionMessages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27992. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27992 FIFO ordering in ActionMessages --- Additional Comments From [EMAIL PROTECTED] 2004-03-26 23:26 --- Joe, Wasn't there a discussion recently with some committers saying they wanted to remove the dependancy on commons collections because of changes in version 3.0 that were not backward compatible? I can't remember, but was a decision made either way on that? Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27992] - FIFO ordering in ActionMessages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27992.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27992
FIFO ordering in ActionMessages
--- Additional Comments From [EMAIL PROTECTED] 2004-03-26 23:27 ---
I don't mean to be negative about your code because I'm impressed you found the
cause of the problem and came up with a solution without any help from the user
or developer lists, but I had a look at your patch and have the following
comments:
Rather than adding a second Comparator and a new inner class would it not be
better to just add property to the existing ActionMessageItem inner class.
That way, the properties() method could just do a very similar process to the
existing get() method?
So what I'm suggesting is:
1) Add a property variable to the ActionMessageItem inner class along with
setProperty() and getProperty methods and change the constructor to also
take property.
2) In the add(property, message) method change where the ActionMessageItem is
instantiated to add the property to the constructor
3) Change the properties() method to sort the ActionMessageItems in a similar
way to the get() method, but use the new getProperty() method in
ActionMessageItem to build a List of property names. Something like:
// do sort stuff first as per get() method
// Create list of properties
for (int i = 0; i actionItems.size(); i++) {
ActionMessageItem ami = (ActionMessageItem)actionItems.get(i);
results.add(ami.getProperty());
}
return results.iterator();
Niall
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27992] - FIFO ordering in ActionMessages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27992.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27992
FIFO ordering in ActionMessages
--- Additional Comments From [EMAIL PROTECTED] 2004-03-26 23:59 ---
Hi Niall,
No offence taken. I knew my attempt was more of a brute force fix rather than
an elegant best practise. So, what you say makes sense (regarding adding
property to the inner class).
Quoting your code:
// do sort stuff first as per get() method
// Create list of properties
for (int i = 0; i actionItems.size(); i++) {
ActionMessageItem ami = (ActionMessageItem)actionItems.get(i);
results.add(ami.getProperty());
}
return results.iterator();
Since a property can have more than one AMI attached to it, we should check for
uniqueness of the entries in the results ArrayList.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27992] - FIFO ordering in ActionMessages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27992. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27992 FIFO ordering in ActionMessages --- Additional Comments From [EMAIL PROTECTED] 2004-03-27 00:17 --- If you look at the add(property, message) method, it only creates a new AMI for the property if it doesn't exist, otherwise it adds the message to the existing AMI's list. So what I'm saying is I don't think you need to check uniqueness, because I believe the AMI is unique for a property. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27992] - FIFO ordering in ActionMessages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27992. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27992 FIFO ordering in ActionMessages --- Additional Comments From [EMAIL PROTECTED] 2004-03-27 01:25 --- Created an attachment (id=11018) New patch with Niall's suggestions. Obviates the earlier patch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
test
pls ignore - 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?)
On Tue, 23 Mar 2004 20:52:03 -0800 (PST), Martin Cooper wrote: So, there are pros and cons both ways, of course. Now we just need to make a decision and move on it. ;- If all the deliverables are in a single module, is there a way that we can generate a separate changelog for each one? http://maven.apache.org/reference/project-descriptor.html#repository -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27943] New: - resource files for non-default modules not loading correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27943. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27943 resource files for non-default modules not loading correctly Summary: resource files for non-default modules not loading correctly Product: Struts Version: 1.1 RC1 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Validator Framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, I am trying to have my application use modules and I followed the examples in the Struts documentation for creating the modules. Each module has its own config file. I am also having each config file reference its own resource file with a message-resources tag. The resource file for the default module is loading ok but for some reason, the resource files for the other modules are not loading correctly. For example, if I have modules mod1 and mod2 where mod1 is the default module and I have a jsp in mod2 that is trying to use something from the resource file of mod2, I am getting very weird errors where it will only display the value for the first key and it can't find the values for the other keys. This happens even if I am trying to reference this same key twice in the same page (the first reference is ok but the second is not). If I have mod1 use the same resource file as mod2 (thereby having it loaded by the default module), everything is ok. The problem here seems to be that resource files for the non-default modules are not loading correctly. Obviously they are loading to an extent because I am able to get the value for the first key that I reference from them, just nothing else. - 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)
--- 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?)
At 6:30 AM -0800 3/25/04, David Graham wrote: 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. Whoops. I read Is there any reason that the EL tags wouldn't replace the existing tags for Struts 2.0? as Is there any reason that the JSTL tags wouldn't replace the existing tags for Struts 2.0? which was wrong. I kind of thought 2.0 would be revolutionary enough that it wouldn't be as simple as just replacing one set of classes with another, but I guess we'll just have to see what gets written! 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]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
At 7:44 AM -0500 3/25/04, Ted Husted wrote: On Tue, 23 Mar 2004 20:52:03 -0800 (PST), Martin Cooper wrote: So, there are pros and cons both ways, of course. Now we just need to make a decision and move on it. ;- If all the deliverables are in a single module, is there a way that we can generate a separate changelog for each one? http://maven.apache.org/reference/project-descriptor.html#repository You can specify a submodule in the repository URL. The project.xml for struts-chain demonstrates this, and I just confirmed that it does what you'd think it would. Run maven site in contrib/struts-chain and then open target/docs/changelog-report.html You'll see that it's limited to struts-chain changes. 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]
RE: struts-workflow (Re: OT: Struts JSR?)
1:There is no overlap as there does not seem to be any development going on about WorkFlow area in struts. I think you are correct; people seem to be gravitating to struts-workflow. This makes my life easier now that I know there is no overlap. I'm not sure which of the above you'd like to resolve to make more planning. I think (1) is a non-issue; (2) should be deferred until someone has a use-case for it, and (3) -- well, we're going to work on moving the commons-chain based request processor into the Struts core shortly after we deal with migrating Struts to a TLP. But it works enough right now that you could probably begin exploring using it for Struts-Workflow. My main confusion was about planning for next major release as it has to be inline with Struts API. So it looks like commons-chain based request processor is the way to go. I will start work on it as soon as I am finished with migration of the workflow-extension to source forge. I'm interested in both chain and workflow, so you might be able to con me into helping out a little bit 8^) Joe, if you are interested you are more than welcome to join.Any helping hands are more than welcome, especially since I have been tied with my current project for last couple of months and have not been able to move forward the way I would have liked to. I am in the process of deciding the roadmap/any missing features/enhancements. One of the ideas I have picked up recently on this list was from Craig's mail (about continuation) snip The most important feature that [workflow] includes, but is not present in [chain], is the idea that is formally known as a continuation -- you can describe a single flow of commands that (if you're building a webapp) requires more than one HTTP interaction with the client. /snip So if we can extend the workflow extension to provide support to really define reusable workflows(or continuations) which can be used like actionForwards from struts actions, that will make the package really complete. Shirish. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Monday, March 22, 2004 3:41 PM To: Struts Developers List Subject: struts-workflow (Re: OT: Struts JSR?) 1:There is no overlap as there does not seem to be any development going on about WorkFlow area in struts. I think you are correct; people seem to be gravitating to struts-workflow. 2:While brousing through struts-dev archive, I came aross many threads where the topic of a workflow like concept was discussed.But nobody seems to have taken this up any further,apart from a mail where in craig has mentioned that he would like to implement a workflow engine where the scriptign languages may be used to define the workflow.he has also mentioned using jelly for the same. But for me, the struts-workflow is more like a wizard implementation,not a real workflow processing engine.SO I am still not clear where jelly like packages may help.But may be I am just being naive. I think it's true that in a wizard scenario, scripting is less likely to be needed. Insofar as one would want to use scripting, I'd probably advocate for a BSF implementation rather than Jelly, so that people can script in any language they want. (Well, actually, I don't think there's a Jelly BSF engine, but I don't think that many people want to script in Jelly either.) 3:The mention of the commons chainning for integrating expernal packages like workflow so that the processing can be intercepted at perticular points and customised.This soundds very interesting concept and very suitable for the workflow requirement.I have not invested much time into this perticular aspect but plan to do so.And I also have a feeling that the future direction for the workflow extension shuld be to move towards the usage of the commons chainning package. I haven't come up to speed on struts-workflow, although I've been wanting to for a while. I remember that Matthias was one of the people who really wanted to see a composable request processing chain, since right now Struts-Workflow has to extend RequestProcessor. It seems likely that the fit will be pretty natural. So this leaves me where I started.Very unclear about the direction the struts is going to take in this regard.And very unclear about how to plan the next major enhancement for the extension. I'm not sure which of the above you'd like to resolve to make more planning. I think (1) is a non-issue; (2) should be deferred until someone has a use-case for it, and (3) -- well, we're going to work on moving the commons-chain based request processor into the Struts core shortly after we deal with migrating Struts to a TLP. But it works enough right now that you could probably begin exploring using it for Struts-Workflow. I'm interested in both chain and workflow, so you might be able to con me into helping out a little bit 8^) Joe -- Joe Germuska [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
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. I presume there are some other Struts HTML tags that are favourites with other people too. -- 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]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
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). 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. -- Peter Pilgrim Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future Struts evolution: look at elements of BEA Page Flows
Hi All-- As David put on flame-retardant gloves, I'll provide full disclosure and tell you what I know. I'm a dev on the team that wrote the Java Page Flow (JPF) code, and open sourcing JPF is something we've been discussing for some time now. I'd definitely be interested in talking about how this could relate to the Struts project if there's any interest. If you'd like to look at JPF, try running the Page Flow Portability Kit, which shipped in December and is available from the link below. This kit allows JPFs to run on any Servlet 2.3 container and has all of the functionality available in the BEA version minus some WebLogic-specific features related to Java Controls, WebLogic RowSets, and automatic recompile / webapp redeploy. At the same link, there's an implementation of the Petstore application that demonstrates some JPF concepts and the programming model. http://dev2dev.bea.com/products/wlworkshop81/technicalguides/pgflow_portability.jsp I don't think you'll need to register on the BEA site and the license is very open -- evaluation / production / etc. There are two versions of this kit -- one that runs on any Servlet 2.3 container and one that runs specifically on Tomcat. The Petstore sample was built using the former, and the latter is integrated with Tomcat security and requires a bit more setup. Let me know what you think. Eddie Karr, David wrote: Before I go any further, I'd like to say that I haven't had time to go over any of the proposed future architectural ideas for Struts going forward. Nevertheless, as I put on my flame-retardant gloves, I'd like to know if anyone thinking about this has examined the elements of the BEA Page Flow architecture. I can't call myself an expert with this, but I've seen enough to be intrigued. The Page Flow architecture is an extension of Struts 1.1 (it uses it internally, and also allows build time and run time integration of pure Struts applications). The high-level elements that I think are intriguing, and might have some application to the Struts architecture, would be the following: Each Page Flow is represented by a Page Flow Controller class. A Page Flow corresponds to a Struts Module. Every action in a Page Flow (module) is handled in the single controller. The routing of Forwards to action methods is basically done through reflection, as opposed to a configuration file mapping. One instance of the Page Flow Controller is created for every user session. The properties of the controller are read and modified to keep track of a user's progress. ActionForms are also used as an additional way to transmit and collect user data, although since Page Flows are easily nested, you tend to write smaller page flows where most of the transient user data is stored in the Page Flow Controller instead of ActionForms. I don't really have any idea how the evolution of Struts should work with the evolution of JavaServer Faces. I can only look a short distance ahead. Although BEA Page Flows are part of a commercial product, BEA has been attempting to release several elements of their newer products as open-source projects. I wouldn't be at all surprised to see them release much of the Page Flow architecture as a SourceForge project in the very near future. If you wanted to examine Page Flows and try it out, all the tools and documentation are freely downloadable. The WebLogic Platform EvalGuide has tutorials on Page Flows (and other aspects). It obviously requires WebLogic for this, but the intent is that Page Flow applications that don't use EJB elements can be deployed to Tomcat or any Servlet 2.3 container (I don't know how/if they would handle licensing for this). The tutorials mostly focus on using the Workshop GUI to do this work, but from our point of view, it's useful to understand the architectural elements the GUI is operating on. - 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 NOT REPLY [Bug 27961] - struts.jsl patch so that Maven build will create taglib documentation pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27961. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27961 struts.jsl patch so that Maven build will create taglib documentation pages --- Additional Comments From [EMAIL PROTECTED] 2004-03-25 22:09 --- Created an attachment (id=10997) Adds jsl elements for taglib documentation generation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27964] New: - struts.jsl patch so that Maven build includes contributors box
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27964. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27964 struts.jsl patch so that Maven build includes contributors box Summary: struts.jsl patch so that Maven build includes contributors box Product: Struts Version: Nightly Build Platform: Other URL: http://www.cyberego.com/maven/struts12/userGuide/struts- bean.html OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] struts.jsl in the Maven build currently does not build the documentation from taglib xdoc files. This minor patch adds the contributors list to the left hand column of the documentation pages. It contains the same style class declaration as the current struts documentation, however the authors class still needs to be added to the maven build-utilized CSS. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27964] - struts.jsl patch so that Maven build includes contributors box
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27964. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27964 struts.jsl patch so that Maven build includes contributors box --- Additional Comments From [EMAIL PROTECTED] 2004-03-25 22:38 --- Created an attachment (id=10998) [PATCH] struts.jsl patch to add contributors list - 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: 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. 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]
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: Splitting struts-config into multiple jar and read them as resource stream
Quoting Martin Cooper [EMAIL PROTECTED]: On Tue, 23 Mar 2004, Martin Cooper wrote: On Tue, 23 Mar 2004, Craig R. McClanahan wrote: Quoting Ted Husted [EMAIL PROTECTED]: On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote: Perfect! What you did in JSF is exatcly what we need: the controller servlet automatically recognize 'META-INF/struts- config.xml' resources in any JAR files that were included in the application. When in struts? Can I help? I think we do the same sort of thing in Commons Chain, n'est pas? This particular functionality was in relationship to automatically finding and loading struts-config.xml files (contributed by JAR files dropped in to the WAR) without having to explicitly note them in context init parameters. It doesn't really relate to per-request processing. I can't do this today, but anyone who wants to help on this need only submit an enhancement request (with a patch) to ActionServlet.init() to scan the configuration resources in addition to what it already does. The secret sauce is to use ClassLoader.findResources() to get the list of URLs to be processed. Before anyone does dash off and write this, I'd like to have a brief discussion about this in relation to multi-module applications, and removing any need to modify web.xml when adding or removing modules. This is something I did in a project about a year ago, very successfully, so I think it's worth adding to the Struts core. So the earlier suggestion / idea was to automatically scan for a Struts config file in a jar's META-INF. This is a nice idea, but by itself, it doesn't work in a multi-module application. The problem is that each module has its own config file, and that config file does not include the name of the module (and neither should it, IMHO). The approach I have used in the past is to create the following structure within the web app: WEB-INF/ modules/ default/ config/ struts-config.xml ... other config files ... jsp/ ... moduleX/ ... moduleY/ ... ... I subclassed ActionServlet so that I could reimplement the config locating code, but it actually wasn't much work at all. The really cool thing about this approach is that adding or removing a module is as simple as adding or removing files and directories. Not one file needs to be edited. This is great for those of us who don't trust installers to do the right thing. ;-) In a similar vein, I'd like to talk about separating out the config reading somewhat, to allow for alternative mechanisms. The point here is that it should be possible to configure Struts in any of the following ways: * Just what we do today, reading the file names from web.xml. * Auto-locating the config file from META-INF (for 1-module apps). * The above-described mechanism for multi-module apps. * Not using Digester at all, possibly not even using XML files. What do people think? The only important con I can think of is that you'd need a Servlet 2.3 or later platform for this to actually work (in order to gain access to ServletContext.getResourcePaths()). Other than that, it's perfectly reasonable (and certainly reasonable for Struts 2.x). -- Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26322] - WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26322. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26322 WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 11:08 --- Is anyone working on a patch for this, or should we offer people the workaround class until a patch is made available? We can't leave a Major bug report open. We need to fish or cut-bait. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27228] - nested errors and messages does not have correct nesting for property
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27228 nested errors and messages does not have correct nesting for property [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 11:09 --- Closing for lack of response. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27332] - The bundle attr do not have subapp resolution.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27332. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27332 The bundle attr do not have subapp resolution. --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 11:10 --- Are you still interested in working on a patch, Richard? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26322] - WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26322. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26322 WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 13:34 --- I will find out from our client if they've been able to work around this for now. I haven't heard anything so I suspect they have. However, an official workaround class would still be a good idea. I briefly looked at what it would take to serialize these classes, and it would go all the way down to the Struts RequestProcessor class and even further to the ModuleConfig class. Before working on a patch for this, I want to understand WHY Weblogic is serializing these classes. Perhaps they are stored in the session...??? Once I figure that out I can begin to work on a patch. However, depending on the response from our client preparing a patch could take a couple of weeks. - 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: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Mar 24, 2004, at 4:19 AM, Ted Husted wrote: Next question. In making changes like this, at what point do we start breaking the CVS history? I'd definitely want to keep it all for core and taglibs. The other components might be less important. ** Last but not least: What else do we need to do for 1.2.1 ? -- Just the three problem tickets on the bugzilla list now? Personally, I'd like to see a 1.2 release before any CVS changes are made. I think the user community would agree. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Simple form state mechanism
Hi! Don't know whether any implementation of preserving form state is planned for Struts. But at the simplest level I would like to implement the following: 1) extend html:form tag to except Map of parameters, so that I could preserve request parameters between form submissions: form name=pform action=/app/action.do?user_id=34amp;status_id=72 method=post.../form This is similar to what we now have in html:link tag. 2) extend ActionForward with addParameter method, so that I could redirect to an action with parameter. It is possible to construct path manually, but addParameter method will save a lot of time. Does any body already work on it? Regards, Ignat. E-mail: ignat at tiger dot unisquad dot com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27239] - bug in html:javascript
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27239. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27239 bug in html:javascript [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 15:06 --- Since I tested this out using the example app and it seems to correctly support static javascript, I'm calling this one fixed. - 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?)
On Wed, 24 Mar 2004 07:45:29 -0700, Matt Raible wrote: ** Last but not least: What else do we need to do for 1.2.1 ? -- Just the three problem tickets on the bugzilla list now? Personally, I'd like to see a 1.2 release before any CVS changes are made. I think the user community would agree. Well, did-ja have anything to add to the list, Matt? :) http://tinyurl.com/yqxyk If we can clear the outstanding problem tickets, along with any burning issues people haven't reported yet, we can roll 1.2.1. -Ted. - 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?)
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Personally, I'd like to see a 1.2 release before any CVS changes are made. I think the user community would agree. Well, did-ja have anything to add to the list, Matt? :) Nope - release, release!! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27910] New: - java.lang.NullPointerException at org.apache.struts.validator.ValidatorForm.validate(ValidatorForm.java:143)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27910.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27910
java.lang.NullPointerException at
org.apache.struts.validator.ValidatorForm.validate(ValidatorForm.java:143)
Summary: java.lang.NullPointerException at
org.apache.struts.validator.ValidatorForm.validate(Valid
atorForm.java:143)
Product: Struts
Version: 1.1 Final
Platform: Other
URL: http://cvs.apache.org/viewcvs.cgi/jakarta-
struts/src/share/org/apache/struts/validator/ValidatorFo
rm.java?rev=1.13view=markup
OS/Version: Other
Status: NEW
Severity: Enhancement
Priority: Other
Component: Validator Framework
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
In my multi-step form wizard, hidden form fields may be a bad idea for security
reasons. Therefore, I keep a copy of the form in the session and incrementally
add the values gathered from the browser.
There arose even a scenario where it was advisable to set some values in that
form even without first doing a PropertyUtils.copyProperties from a form coming
from a browser. A subsequent .validate() then causes the above nullPointer
exception.
Suggestion:
When doing the
ServletContext application = getServlet().getServletContext();
in the ValidatorForm, first test whether the getServlet() really returns other
than null and otherwise return a decent error message.
I am not fully clear why the problem arises, but I guess that ValidatorForm()
not having a constructor method is part of the reason for this.
Anyway, I got it working by extending my form as follows:
public class MyForm extends ValidatorForm
public MyForm() {
super();
}
public MyForm(ActionServlet servlet) {
this();
if (super.getServlet() == null) {
if (servlet == null) {
log.error(servlet == null);
} else {
super.setServlet(servlet);
log.debug(set servlet: + servlet);
}
} else {
log.debug(super.getServlet(): + super.getServlet());
}
when creating the form, I call it with
MyForm myForm = new MyForm(getServlet());
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27239] - bug in html:javascript
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27239. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27239 bug in html:javascript --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 17:14 --- Matt: re: documentation, agreed, and thanks for the reminder; I just patched doc/userGuide/struts-html.xml with more information. If you have other suggestions for where this might be documented, please let me know. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Counting down to the 1.2.1 release (was RE: Making Struts Build Easier)
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 ... -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] Bug ID 26322 - Weblogic hot-deploy breaks tiles
I have made a number of Struts classes Serializable, which addresses this
issue: http://issues.apache.org/bugzilla/show_bug.cgi?id=26322
Attached are the diffs for:
- org.apache.struts.action.PlugIn
- org.apache.struts.action.RequestProcessor
- org.apache.struts.config.ModuleConfig
- org.apache.struts.tiles.TilesPlugin
- org.apache.struts.tiles.TilesRequestProcessor
- org.apache.struts.util.ModuleUtils
In all of the above cases, the default serialization was sufficient to
serialize the objects.
This is my first patch submission, so please let me know if there is anything
I should do differently.
Thanks,
Justin
Index: src/share/org/apache/struts/config/ModuleConfig.java
===
RCS file: /home/cvspublic/jakarta-struts/src/share/org/apache/struts/config/ModuleConfig.java,v
retrieving revision 1.7
diff -u -b -r1.7 ModuleConfig.java
--- src/share/org/apache/struts/config/ModuleConfig.java 14 Mar 2004 06:23:47 - 1.7
+++ src/share/org/apache/struts/config/ModuleConfig.java 24 Mar 2004 17:26:05 -
@@ -19,6 +19,8 @@
*/
package org.apache.struts.config;
+import java.io.Serializable;
+
/**
* pThe collection of static configuration information that describes a
* Struts-based module. Multiple modules are identified by
@@ -31,7 +33,7 @@
* @version $Revision: 1.7 $ $Date: 2004/03/14 06:23:47 $
* @since Struts 1.1
*/
-public interface ModuleConfig {
+public interface ModuleConfig extends Serializable {
/**
* Has this module been completely configured yet. Once this flag
* has been set, any attempt to modify the configuration will return an
Index: src/share/org/apache/struts/tiles/TilesPlugin.java
===
RCS file: /home/cvspublic/jakarta-struts/src/share/org/apache/struts/tiles/TilesPlugin.java,v
retrieving revision 1.25
diff -u -b -r1.25 TilesPlugin.java
--- src/share/org/apache/struts/tiles/TilesPlugin.java 14 Mar 2004 06:23:43 - 1.25
+++ src/share/org/apache/struts/tiles/TilesPlugin.java 24 Mar 2004 17:27:03 -
@@ -21,6 +21,7 @@
package org.apache.struts.tiles;
import java.util.Map;
+import java.io.Serializable;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
@@ -59,7 +60,7 @@
* properly initialize the request processor.
* @since Struts 1.1
*/
-public class TilesPlugin implements PlugIn {
+public class TilesPlugin implements PlugIn, Serializable {
/**
* Commons Logging instance.
Index: src/share/org/apache/struts/tiles/TilesRequestProcessor.java
===
RCS file: /home/cvspublic/jakarta-struts/src/share/org/apache/struts/tiles/TilesRequestProcessor.java,v
retrieving revision 1.25
diff -u -b -r1.25 TilesRequestProcessor.java
--- src/share/org/apache/struts/tiles/TilesRequestProcessor.java 14 Mar 2004 06:23:43 - 1.25
+++ src/share/org/apache/struts/tiles/TilesRequestProcessor.java 24 Mar 2004 17:27:18 -
@@ -21,6 +21,7 @@
package org.apache.struts.tiles;
import java.io.IOException;
+import java.io.Serializable;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
@@ -51,7 +52,7 @@
* /p
* @since Struts 1.1
*/
-public class TilesRequestProcessor extends RequestProcessor {
+public class TilesRequestProcessor extends RequestProcessor implements Serializable {
/**
* Definitions factory.
Index: src/share/org/apache/struts/action/PlugIn.java
===
RCS file: /home/cvspublic/jakarta-struts/src/share/org/apache/struts/action/PlugIn.java,v
retrieving revision 1.15
diff -u -b -r1.15 PlugIn.java
--- src/share/org/apache/struts/action/PlugIn.java 14 Mar 2004 06:23:42 - 1.15
+++ src/share/org/apache/struts/action/PlugIn.java 24 Mar 2004 17:25:51 -
@@ -25,6 +25,8 @@
import javax.servlet.ServletException;
import org.apache.struts.config.ModuleConfig;
+import java.io.Serializable;
+
/**
* pA strongPlugIn/strong is a configuration wrapper for a
@@ -47,7 +49,7 @@
* @since Struts 1.1
*/
-public interface PlugIn {
+public interface PlugIn extends Serializable {
/**
Index: src/share/org/apache/struts/util/ModuleUtils.java
===
RCS file: /home/cvspublic/jakarta-struts/src/share/org/apache/struts/util/ModuleUtils.java,v
retrieving revision 1.8
diff -u -b -r1.8 ModuleUtils.java
--- src/share/org/apache/struts/util/ModuleUtils.java 14 Mar 2004 06:23:51 - 1.8
+++ src/share/org/apache/struts/util/ModuleUtils.java 24 Mar 2004 17:27:33 -
@@ -29,13 +29,15 @@
import org.apache.struts.action.RequestProcessor;
import org.apache.struts.config.ModuleConfig;
+import java.io.Serializable;
+
/**
* General purpose utility methods related to module processing.
*
* @version $Revision: 1.8 $
* @since Struts 1.2
*/
-public class
DO NOT REPLY [Bug 27910] - java.lang.NullPointerException at org.apache.struts.validator.ValidatorForm.validate(ValidatorForm.java:143)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27910. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27910 java.lang.NullPointerException at org.apache.struts.validator.ValidatorForm.validate(ValidatorForm.java:143) --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 17:58 --- Struts has some deep assumptions that you aren't creating your own form beans. Some work has already happened to make it easier to ask Struts for instances of form beans (instead of using new) -- in nightly builds you can can call RequestUtils.createActionForm(FormBeanConfig,ActionServlet) http://jakarta.apache.org/struts/api/org/apache/struts/util/RequestUtils.html#createActionForm(org.apache.struts.config.FormBeanConfig,%20org.apache.struts.action.ActionServlet) I think there are legitimate reasons to encourage people to use Struts to get form bean instances rather than constructing them themselves. I'd like to steer this bug along the lines of making that work better instead of encouraging people to instantiate their own form beans. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27910] - java.lang.NullPointerException at org.apache.struts.validator.ValidatorForm.validate(ValidatorForm.java:143)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27910. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27910 java.lang.NullPointerException at org.apache.struts.validator.ValidatorForm.validate(ValidatorForm.java:143) --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 18:11 --- Do you have in the from-bean definition initial value for page property? try it, it worked for me form-property name=page type=java.lang.Integer initial=0/ for java.lang.NullPointerException in at org.apache.struts.validator.DynaValidatorForm.validate (DynaValidatorForm.java:141) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26322] - WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26322. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26322 WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 18:21 --- Created an attachment (id=10954) Diff for org.apache.struts.config.ModuleConfig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26322] - WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26322. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26322 WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 18:21 --- Created an attachment (id=10955) Diff for org.apache.struts.util.ModuleUtils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26322] - WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26322. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26322 WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 18:22 --- Created an attachment (id=10956) Diff for org.apache.struts.action.PlugIn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26322] - WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26322. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26322 WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 18:23 --- Created an attachment (id=10957) Diff for org.apache.struts.action.RequestProcessor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26322] - WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26322. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26322 WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 18:23 --- Created an attachment (id=10958) Diff for org.apache.struts.tiles.TilesPlugin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26322] - WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26322. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26322 WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 18:23 --- Created an attachment (id=10959) Diff for org.apache.struts.tiles.TilesRequestProcessor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27912] New: - NullPointerException in DynaValidatorForm.validate
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27912. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27912 NullPointerException in DynaValidatorForm.validate Summary: NullPointerException in DynaValidatorForm.validate Product: Struts Version: 1.1 Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Validator Framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have baseAction that authorize the user. All actions extend it. When user is not allowed to run particular action he is redirected to loginAction (redirect is defined in global-forward as forward name=user_login path=/xxx/Login.do redirect=true/) I use DynaValidatorForm as form bean to collect user data: form-bean name=logInForm type=org.apache.struts.validator.DynaValidatorForm form-property name=page type=java.lang.Integer/ form-property name=method type=java.lang.String/ form-property name=email type=java.lang.String/ form-property name=password type=java.lang.String/ /form-bean Because I display login form and validate it in the same loginAction I use page parameter to validate the form only after submitting it. When redirect occurs I receive the: java.lang.NullPointerException at org.apache.struts.validator.DynaValidatorForm.validate (DynaValidatorForm.java:141) at org.apache.struts.action.RequestProcessor.processValidate (RequestProcessor.java:942) at org.apache.struts.action.RequestProcessor.process (RequestProcessor.java:255) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) solution for this bug? is: a) set in redirect ?page=0 or b) in form definition set form-property name=page type=java.lang.Integer initial=0/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Splitting struts-config into multiple jar and read them as resource stream
On Wed, 24 Mar 2004, Craig R. McClanahan wrote: Quoting Martin Cooper [EMAIL PROTECTED]: On Tue, 23 Mar 2004, Martin Cooper wrote: On Tue, 23 Mar 2004, Craig R. McClanahan wrote: Quoting Ted Husted [EMAIL PROTECTED]: On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote: Perfect! What you did in JSF is exatcly what we need: the controller servlet automatically recognize 'META-INF/struts- config.xml' resources in any JAR files that were included in the application. When in struts? Can I help? I think we do the same sort of thing in Commons Chain, n'est pas? This particular functionality was in relationship to automatically finding and loading struts-config.xml files (contributed by JAR files dropped in to the WAR) without having to explicitly note them in context init parameters. It doesn't really relate to per-request processing. I can't do this today, but anyone who wants to help on this need only submit an enhancement request (with a patch) to ActionServlet.init() to scan the configuration resources in addition to what it already does. The secret sauce is to use ClassLoader.findResources() to get the list of URLs to be processed. Before anyone does dash off and write this, I'd like to have a brief discussion about this in relation to multi-module applications, and removing any need to modify web.xml when adding or removing modules. This is something I did in a project about a year ago, very successfully, so I think it's worth adding to the Struts core. So the earlier suggestion / idea was to automatically scan for a Struts config file in a jar's META-INF. This is a nice idea, but by itself, it doesn't work in a multi-module application. The problem is that each module has its own config file, and that config file does not include the name of the module (and neither should it, IMHO). The approach I have used in the past is to create the following structure within the web app: WEB-INF/ modules/ default/ config/ struts-config.xml ... other config files ... jsp/ ... moduleX/ ... moduleY/ ... ... I subclassed ActionServlet so that I could reimplement the config locating code, but it actually wasn't much work at all. The really cool thing about this approach is that adding or removing a module is as simple as adding or removing files and directories. Not one file needs to be edited. This is great for those of us who don't trust installers to do the right thing. ;-) In a similar vein, I'd like to talk about separating out the config reading somewhat, to allow for alternative mechanisms. The point here is that it should be possible to configure Struts in any of the following ways: * Just what we do today, reading the file names from web.xml. * Auto-locating the config file from META-INF (for 1-module apps). * The above-described mechanism for multi-module apps. * Not using Digester at all, possibly not even using XML files. What do people think? The only important con I can think of is that you'd need a Servlet 2.3 or later platform for this to actually work (in order to gain access to ServletContext.getResourcePaths()). Other than that, it's perfectly reasonable (and certainly reasonable for Struts 2.x). Doh! I'd forgotten about that. However, if we made config reading pluggable, people could implement any of the above options today, without the need to subclass ActionServlet. -- Martin Cooper -- Martin Cooper 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]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Wed, 24 Mar 2004, Ted Husted wrote:
On Tue, 23 Mar 2004 20:52:03 -0800 (PST), Martin Cooper wrote:
So, there are pros and cons both ways, of course. Now we just need
to make a decision and move on it. ;-)
The consensus seems to be to use a single module with top-level-directories
representing each subproject, so lets move forward with that.
So I believe we're talking about something like this:
\core(including tiles and validator)
\apps
\site
\opt-dev (whiteboard or sandbox)
So 'dev', 'whiteboard' or 'sandbox'? ;-) I don't have a strong preference,
although 'sandbox' is used by at least 4 Jakarta sub-projects. (In those,
it's a separate repo, though. Do we want to do the same?)
\opt-taglib
I still like the idea of pushing this down under a generic presentation
directory, or at least under a JSP directory, so that we can move JSP
specific stuff out of core and into this.
\opt-el
Hmm. This is also a taglib...
\opt-faces
The example applications we will have to juggle a bit:
[apps]
/src/example - /mailreader/src/java
/src/examples - /examples/src/java
/src/tiles-documentation - /portal/src/java
And the same for /web
/web/{1} - {1}/src/webapp/
The other directory moving might go something like this:
[opt-el]
src/contrib/struts-el - opt-el
[opt-legacy]
/src/contrib/struts-legacy - opt-legacy
[opt-faces]
/src/contrib/struts-faces - opt-faces
[opt-dev]
/src/contrib/ - opt-dev
[opt-taglib]
src/share/o.a.s/taglib - opt-taglib/src/java/o.a.s/taglib
src/test/o.a.s/taglib- opt-taglib/src/test/o.a.s/taglib
doc/userGuide/dev_*.* - opt-taglib/xdocs
doc/userGuide/struts*.* - opt-taglib/xdocs
[site]
/doc/ - site/xdocs
[core]
/src/share - core/src/java
/src/test - core/src/test
/ - /
This is just a rough starting point. I'd want to try a dry-run offline first, and
post it where people could browse it :)
+1. I was thinking along the same lines.
One question is the packaging of Struts-el. Right now it's org.apache.strutsel. I'm
thinking we might want that to be org.apache.struts.el instead.
Maybe either:
org.apache.struts.taglib.el.${foo}
org.apache.struts.taglib.${foo}.el
The latter just extends the original package names with .el.
We might also want to shuffle some things around in opt-faces to make it more Maven
friendly. It's also sharing the UserDatabase package with the original example, and
so we might want to break the UserDatabase out as a deliverable that multiple
applications could share.
Next question. In making changes like this, at what point do we start breaking the
CVS history? I'd definitely want to keep it all for core and taglibs. The other
components might be less important.
We can arrange to keep CVS history indefinitely. However, we'd want to
stop moving things around as soon as possible, really, and certainly not
move anything after we've created labels or branches in the new tree.
** Last but not least: What else do we need to do for 1.2.1 ? -- Just the three
problem tickets on the bugzilla list now?
Actually, contrary to your comment in the Counting down thread, I don't
have anything up my sleeve (unless I forgot something myself). ;-) It
would be nice to resolve the issue with the Cactus tests not stopping
properly on Tomcat 5.0, but I can live without that if necessary.
--
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]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Wed, 24 Mar 2004 11:03:58 -0800 (PST), Martin Cooper wrote: \opt-dev (whiteboard or sandbox) So 'dev', 'whiteboard' or 'sandbox'? ;-) I don't have a strong preference, although 'sandbox' is used by at least 4 Jakarta sub- projects. (In those, it's a separate repo, though. Do we want to do the same?) Let's go for the brevity and consistency of opt-dev. If we're keeping everything in one module, then let's keep it all on one module :) \opt-taglib I still like the idea of pushing this down under a generic presentation directory, or at least under a JSP directory, so that we can move JSP specific stuff out of core and into this. I would strongly prefer that we should tie the TLDs to specific deliverables and avoid taxonomies, The JSP specific stuff should live with the taglibs or be refactored so that it's not JSP-specific :) Obviously, I'm good with alternate presentation technologies, but they should be available as their own deliverables, and rooted in their own TLDs. \opt-el Hmm. This is also a taglib... But with different platform requirements. :) -Ted. - 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)
On Wed, 24 Mar 2004 11:03:58 -0800 (PST), Martin Cooper wrote: Actually, contrary to your comment in the Counting down thread, I don't have anything up my sleeve (unless I forgot something myself). ;-) It would be nice to resolve the issue with the Cactus tests not stopping properly on Tomcat 5.0, but I can live without that if necessary. Well, if we get the problem tickets down to zero, and I update the release notes again, would we be up for rolling 1.2.1 this weekend? -Ted. - 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)
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? -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]
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: Counting down to the 1.2.1 release (was RE: Making Struts Build Easier)
On Wed, 24 Mar 2004 12:11:01 -0800 (PST), Martin Cooper wrote: Do we want to wait for a Validator 1.1.2, or roll it with 1.1.1? Well, we can't roll it with 1.1.1, since the report says the client validations won't work without the nightly build. It would be cool if we could roll Validator 1.1.2, and then roll Strut 1.2.1, and see if they both make the grade. We mostly expected 1.2.0 to wash-out, but 1.2.1 might actually be OK. Meanwhile, we could branch 1.2.x and bring the Struts-Chain RP down from contrib. :) -Ted. - 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?)
On Wed, 24 Mar 2004 20:35:41 +, Peter A. Pilgrim wrote: Are keeping the basic `src' and `web' main sub directory under each top level directory? I'd prefer we followed the Maven project layout recommendations for each deliverable. This will be the easiest for everyone to grok in the longrun. http://maven.apache.org/reference/dirlayout.html So, under each top-level directory, we would find a layout like /src - java - test - webapp /xdocs /target (generated) - *.jar - distributions - docs - site - ... May be it is worth putting `opt-legacy' and `opt-el' under a `view' directory especially if they are all to do rendering the web user interface You might have meant opt-taglib and opt-el. Legacy is the old datasource implementation. I'd strongly prefer keeping a close relationship between top-level-directories and deliverables, and that we avoid taxonomies. 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. The example applications tree might be a tad different. Here I'd favor a master apps directory, with a directory for each application beneath that. 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 :( -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Validator and Resourcebundles and modules
Hi Since there where no takers on the users list : Is there a way of telling the Validator which Resourcebundle it should get its resources from? I have multi-module Strut application, each module has its own Resourcebundle (ApplicationResources-moda.poperties, ApplicationResources-modb.poperties etc). I have not been able to figure out how to make it read from the various bundles. It insists on looking in the default (ApplicationResources.poperties). Hermod * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that DnB NOR cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Future Struts evolution: look at elements of BEA Page Flows
Before I go any further, I'd like to say that I haven't had time to go over any of the proposed future architectural ideas for Struts going forward. Nevertheless, as I put on my flame-retardant gloves, I'd like to know if anyone thinking about this has examined the elements of the BEA Page Flow architecture. I can't call myself an expert with this, but I've seen enough to be intrigued. The Page Flow architecture is an extension of Struts 1.1 (it uses it internally, and also allows build time and run time integration of pure Struts applications). The high-level elements that I think are intriguing, and might have some application to the Struts architecture, would be the following: Each Page Flow is represented by a Page Flow Controller class. A Page Flow corresponds to a Struts Module. Every action in a Page Flow (module) is handled in the single controller. The routing of Forwards to action methods is basically done through reflection, as opposed to a configuration file mapping. One instance of the Page Flow Controller is created for every user session. The properties of the controller are read and modified to keep track of a user's progress. ActionForms are also used as an additional way to transmit and collect user data, although since Page Flows are easily nested, you tend to write smaller page flows where most of the transient user data is stored in the Page Flow Controller instead of ActionForms. I don't really have any idea how the evolution of Struts should work with the evolution of JavaServer Faces. I can only look a short distance ahead. Although BEA Page Flows are part of a commercial product, BEA has been attempting to release several elements of their newer products as open-source projects. I wouldn't be at all surprised to see them release much of the Page Flow architecture as a SourceForge project in the very near future. If you wanted to examine Page Flows and try it out, all the tools and documentation are freely downloadable. The WebLogic Platform EvalGuide has tutorials on Page Flows (and other aspects). It obviously requires WebLogic for this, but the intent is that Page Flow applications that don't use EJB elements can be deployed to Tomcat or any Servlet 2.3 container (I don't know how/if they would handle licensing for this). The tutorials mostly focus on using the Workshop GUI to do this work, but from our point of view, it's useful to understand the architectural elements the GUI is operating on. - 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]
[Apache Struts Wiki] Updated: AbandonedPages
Date: 2004-03-24T17:28:42 Editor: 202.118.6.200 Wiki: Apache Struts Wiki Page: AbandonedPages URL: http://wiki.apache.org/struts/AbandonedPages no comment Change Log: -- @@ -1,4 +1 @@ -##language:en -Pages that were not edited since the begin of history (literally); it's a listing of the oldest entries in the editlog. - -[[AbandonedPages]] +good luck to you ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/conf/share validator-rules.xml
rleland 2004/03/24 20:52:23 Modified:conf/share validator-rules.xml Log: Have validator bring in Utility functions. Revision ChangesPath 1.49 +15 -4 jakarta-struts/conf/share/validator-rules.xml Index: validator-rules.xml === RCS file: /home/cvs/jakarta-struts/conf/share/validator-rules.xml,v retrieving revision 1.48 retrieving revision 1.49 diff -u -r1.48 -r1.49 --- validator-rules.xml 11 Dec 2003 05:52:58 - 1.48 +++ validator-rules.xml 25 Mar 2004 04:52:23 - 1.49 @@ -259,7 +259,18 @@ javax.servlet.http.HttpServletRequest depends= msg=errors.email/ - + !-- + This simply allows struts to include the validateUtilities into a page, it should + not be used as a validation rule. + -- + validator name=includeJavaScriptUtilities +classname= + method= + methodParams= + depends= + msg= + jsFunction=org.apache.commons.validator.javascript.validateUtilities/ + / /global - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/examples/org/apache/struts/webapp/validator MessageResources.properties TypeForm.java
rleland 2004/03/24 21:12:59
Modified:src/examples/org/apache/struts/webapp/validator
MessageResources.properties TypeForm.java
Log:
Bug#: 27899
Modify example to test proper behaviour is a property
is named 'name'
Revision ChangesPath
1.2 +1 -0
jakarta-struts/src/examples/org/apache/struts/webapp/validator/MessageResources.properties
Index: MessageResources.properties
===
RCS file:
/home/cvs/jakarta-struts/src/examples/org/apache/struts/webapp/validator/MessageResources.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MessageResources.properties 8 Jan 2004 16:18:19 - 1.1
+++ MessageResources.properties 25 Mar 2004 05:12:59 - 1.2
@@ -55,6 +55,7 @@
multiRegistrationForm.description=multi-page example with client side JavaScript
validation and server side validation
# Type form
+typeForm.name.displayname=String Field
typeForm.byte.displayname=Byte Field
typeForm.checkbox.wouldrecommend=I would recommend
typeForm.checkbox.used.languages=Programming Languages used
1.4 +23 -15
jakarta-struts/src/examples/org/apache/struts/webapp/validator/TypeForm.java
Index: TypeForm.java
===
RCS file:
/home/cvs/jakarta-struts/src/examples/org/apache/struts/webapp/validator/TypeForm.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- TypeForm.java 14 Mar 2004 06:23:49 - 1.3
+++ TypeForm.java 25 Mar 2004 05:12:59 - 1.4
@@ -4,13 +4,13 @@
* $Date$
*
* Copyright 2000-2004 The Apache Software Foundation.
- *
+ *
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
- *
+ *
* http://www.apache.org/licenses/LICENSE-2.0
- *
+ *
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -36,7 +36,7 @@
*/
public final class TypeForm extends ValidatorForm implements Serializable {
private String action = null;
-
+private String name = null; //Used to test Multiform per page validation when
property name is 'name'
private String sByte = null;
private String sShort = null;
private String sInteger = null;
@@ -54,15 +54,23 @@
private List lNames = initNames();
-public String getAction() {
- return action;
-}
-
-public void setAction(String action) {
-this.action = action;
-}
+ public String getAction() {
+ return action;
+ }
+
+ public void setAction(String action) {
+ this.action = action;
+ }
+
+ public String getName() {
+ return name;
+ }
+
+ public void setName(String name) {
+ this.name = name;
+ }
-public String getByte() {
+ public String getByte() {
return sByte;
}
-
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)
-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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/examples/validator jsType.jsp
rleland 2004/03/24 21:50:31 Modified:web/examples/validator jsType.jsp Log: Bug#: 27899 Modify example to test proper behaviour is a property is named 'name' Revision ChangesPath 1.2 +8 -0 jakarta-struts/web/examples/validator/jsType.jsp Index: jsType.jsp === RCS file: /home/cvs/jakarta-struts/web/examples/validator/jsType.jsp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jsType.jsp8 Jan 2004 16:21:12 - 1.1 +++ jsType.jsp25 Mar 2004 05:50:31 - 1.2 @@ -23,6 +23,14 @@ table border=0 tr th align=left +bean:message key=typeForm.name.displayname / + /th + td align=left +html:text property=name size=15 maxlength=15 / + /td +/tr +tr + th align=left bean:message key=typeForm.byte.displayname / /th td align=left - 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)
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. -- 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]
greetings a newbie question
hi, just joined the list, and i have a newbie question about struts design. this is where i am at. i have looked at struts about a year back, and rolled my own version of mvc web architecture, stealing several basic ideas from struts. at the time, it appeared that many features of struts were not apparently applicable to the project, so the overhead of configuring struts didn't seem justifiable. now the need for many of the struts features has become pretty concrete, and so i am in process of incorporating struts rather than re-inventing the wheels (and axels and cupholders, etc). while adapting the code base to use struts, i get the sense that: these are the classes/packages; for many, you can configure/adapt it to your needs via config files; in other aspects, you may want/need to subclass and override some of the classes to fit your needs. for the later category of adaptation (subclassing/overriding), the best way seems to be to look into the source to ascertain the default behavior and to ensure the overriding implementation is proper. to put it simply, struts' interface doesn't seem to be clearly defined. by clearly defined interface, i mean programming/usage could/should be via/against the interface without delving into implementation details. if not, pointer(s) to the authoritative interface defnitions would be much appreciated (i told you i'm a newbie). but if so, is this deliberate? and the reasoning behind? some obvious (generic) arguments i could see are: 1. it's advantageous in order to provide greater flexibility, struts being a development framework 2. struts (and web app requirements) are progressing rapidly, so loose interface may serve the purpose better are there more specific reasons other than these? or perhaps it is simply a documentation issue? thanx for any insight/info, dasa ps: i am sending this to both the user and dev lists, thinking the subject is of interest to both. perhaps you'll correct me. again, a newbie here. - 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?)
Martin Cooper wrote: On Mon, 22 Mar 2004, Craig R. McClanahan wrote: Quoting Martin Cooper [EMAIL PROTECTED]: On Mon, 22 Mar 2004, Ted Husted wrote: On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote: While it's great to break out things into separate modules - I'd love to be able to get struts.jar w/ everything in it - including EL and tags. I can live with all the commons-* JARs (even if it is annoying), but in general - the less JARs, the better. It just simplifies things for the developer. I don't care how things are partitioned in CVS, as long as everything builds with one checkout and one command. If that were someone's itch, it could certainly be done. Ant doesn't know about the module partitions, and so someone could write a uber-build that did something like this. If we have all of the pieces in separate repositories, though, where would the files for such an uber-build be checked in? That's one of the problems I have with the multi-repository solution - there is no place for files that span those repositories. If we have one repository split into pieces, then we still have the top level for these things. On the multi-repository projects I've worked on, we had a special repository just for integration tasks like this. So we'd need yet another repo - say struts-integration - just for this. Why is that better than just doing what we need within the repo that we have already? In my experienc multiple CVS repositories can make a project much harder to manage. But are we singing from the same hymn sheet? Is a multiple repository equal ( or not equal) to a CVS module? But, the problem with thinking of Struts as one monothic build is that every aspect of the framework has to be perfect, all at the same time, before we can call it a general availability ready-for-prime-time release. One of the many reasons 1.1 took so long was that if there was any bug in any component anywhere in the framework, everything gridlocked. :( :( :( That doesn't need to be true if we don't want it to. Recall that for a time we had a separtely built, separately distributed component called struts-legacy to handle the data source situation. There is no need for a one-to-one correlation between repositories and distributable entities. What we want to do ... need to do ... is be able to release fixes to components like the taglibs independently of the core controller. Likewise, we need to release changes to Struts EL or Struts Faces (once it goes 1.0) without having to be sure every other component is ready to roll. We should also be able to release updates to the example applications without re-releasing the rest of the framework, if that's all we want to roll right now. Absolutely. And the number of repositories we have is entirely orthogonal to this. Ultimately true, although it's still somewhat easier to visualize if you have separate repositories. Some people may not like more JARs, but I know for certain that the single JAR approach is a momentum killer. It's made my life much more difficult, and I think it's chased away some Committers who became frustrated by having to everything right in order to one little feature into a formal release. For the people who want / need a single jar, it would be simple enough for us to provide an Ant target that explodes the desired individual jars and recombines them into a single jar. The only tricky part, I think, would be creating a manifest that identifies the versions of the individual pieces in that jar. That's assuming people want such a beast, of course. (I'm not in that camp myself, though, just as I'd never use the Commons Combo build.) If we can get more code into the hands of more developers in less time, then a few more JARs seems like a small price to pay. :) +1 Yep. Here's something else to mull over: Now that Struts is a TLP, we might want to talk about whether we want to ask the most popular open source Struts extensions -- like Struts Menu, Workflow, Stxx, SSL, and TestCase -- whether they would like to donate their code to the ASF and live as Struts opt subprojects. This would be a continuation of what we started with Tiles, Validator, and Nested, which are all favorites with our community. People working on such packages might be brought on as Struts Committers, since they have proved they have what it takes to run a project, and after an appropriate period, later invited to join the Struts PMC. IMHO, when people talk about JSF replacing Struts, they are unaware of the true breadth of the Struts platform. Perhaps it's time we made sure people know how much they are missing :) A sad truth: In working with various teams managing larger projects, I've found a surprising reluctance to use extensions that were not distributed by the Struts project itself. By giving these very fine extensions the nod, we can make them available to a greater number of Struts teams, to everyone's benefit. If we don't help make these extensions available to
Re: Splitting struts-config into multiple jar and read them as resource stream
Perfect! What you did in JSF is exatcly what we need: the controller servlet automatically recognize 'META-INF/struts-config.xml' resources in any JAR files that were included in the application. When in struts? Can I help? Filippo Munafò -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 20, 2004 18:33 To: 'Struts Dev Mailing List' Subject: Re: Splitting struts-config into multiple jar and read them as resource stream Quoting Joe Germuska [EMAIL PROTECTED]: We'd like not to subclass ActionServlet, but is really difficult to do something like this outside the ActionServlet hierarchy mainly 'cause of the call to initConfigDigester(), that's obviously protected. The questions are: - is there a way to do the same without subclassing ActionServlet? - do you think is it reasonable to include a similar feature in the main source tree on CVS (dynamic read pieces of struts-config from jar files)? It seems plausible that a factory class could be factored out of the ActionServlet. I'd think you could do this in Struts 1 in a backwards compatible fashion. I think people would like to be able to configure struts from a variety of sources; another popular request is for dynamic reconfiguration -- without a redeploy -- but that's a different and more complicated question. Along the same lines, one of the things we did in JavaServer Faces (with regards to configuration) is to have the controller servlet automatically recognize META-INF/faces-config.xml resources in any JAR files that were included in the application. This makes it very easy to package a module, or some other sub-unit of an overall webapp, as a single JAR file that self-configures. Joe 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]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Tue, 23 Mar 2004 10:07:55 +, Peter A. Pilgrim wrote: In my experienc multiple CVS repositories can make a project much harder to manage. But are we singing from the same hymn sheet? Is a multiple repository equal ( or not equal) to a CVS module? We mean multiple CVS modules. The original idea being each module would generate a jar. Product==JAR==Module==unit-of-release. One list of potential products -- each with its own JAR, module, and release cycle -- would be: * core (including tiles and validator) * examples * site * whiteboard (or sandbox) * opt-taglib * opt-el * opt-faces aka the seven dwarfs :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
