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]
