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?)
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
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: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag)
JSTL does indeed require JSP 1.2. Quoting [EMAIL PROTECTED]: For what my non-contributor opinion's worth, I totally agree with David. So far as I know, while JSTL is not _required_ by the standard for JSP 1.2, it does not _require_ 1.2 -- and can be used with 1.1 containers; so saying use JSTL does not translate to upgrade to Servlet 2.3. Shai. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 07:41 To: Struts Developers List Subject: Re: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag) --- Steve Raeburn [EMAIL PROTECTED] wrote: I'm not singling Vic out for this (honest) but... The standard advice we are now giving everyone is use JSTL, which I wholeheartedly agree with and have said myself. However, I think we need to make sure that we still adequately support non-JSTL solutions and continue to consider bug fixes/enhancements to Struts tags EVEN where it would duplicate JSTL functionality because Struts still supports JSP 1.1/Servlet2.2. I strongly disagree with that. Duplicating standard functionality is a complete waste of time. If someone wants something available in the JSTL they should just use the JSTL. Struts goal in life isn't to duplicate standards. We should absolutely fix bugs in the existing tags and provide tags that aren't available elsewhere. Having said that, I won't stop you or any other committer from donating time to developing tags that duplicate JSTL functionality. However, I can't justify spending my own time maintaining or fixing bugs in such tags. I haven't considered whether this particular enhancement would fall into the category of something we should do, it just prompted me to raise the issue. If we've reached the stage where the recommendations we are making *require* JSTL, then I think it's time to be honest about the required platform for Struts and up it to 1.1/2.3 I don't see how the Servlet version required for JSTL is relevant to Struts. We're making the reasonable recommendation that people use standard technologies instead of the propriety Struts counterparts. The Struts tags have served us well for a long time but IMO its time to let most of them fade away gracefully. David Thoughts? Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: August 27, 2003 8:28 PM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21465. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21465 Enhancement of the html:link tag [EMAIL PROTECTED] changed: What|Removed |Added -- -- Status|ASSIGNED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-08-28 03:27 --- You can/should use JSTL instead. .V -- 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: Simplifying DynaActionForms
String value = BeanUtils.getProperty(form, propName); No casting and it works for *any* form, meaning that your Action code is independent of your choice of form implementation (vanilla or dyna). So, FWIW, even if you added the method, I personally wouldn't use it. I even find using PropertyUtils preferable: String value = (String)PropertyUtils.getProperty(form, propName); It's more important to me to abstract the type of the form than the type of the property. Quoting Sgarlata Matt [EMAIL PROTECTED]: Casting to String gets to be quite painful with many form properties. Unless I've forgotten/missed an easier way of dealing with DynaActionForms, I propose we add a DynaActionForm.getAsString(String) method that does this casting for us. This is a minor point, but how about DynaActionForm.getString(String) instead? This would be consistent with naming conventions in java.sql.ResultSet (I can't think of other places with convenience methods like this off the top of my head). Also, following along in the java.sql.ResultSet thinking, would you also have getters for the other wrappers around primitives and the Date and Calendar objects? This might just clutter the interface... I wouldn't ever personally use them in my app because almost every form property is a String. Matt Thoughts? David -- 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: Streaming PDF file with the bean:write tag -- please help
This really belongs on the user list, but JSP's are perfectly happy to spit out whatever you want: %@ page contentType=application/pdf % They might not be the best choice for certain content, but they're capable of doing a lot more than just text output. Quoting Tom Drake [EMAIL PROTECTED]: Sorry, JSP's are only capable of producing text output. You'll need a servlet to produce PDF output. Also, if you're retrieving the PDF content from the database consider using the 'ResultSet.getBinaryStream(...)' and copy the resulting input stream to the response output stream, as opposed to materializing the entire PDF 'file' in memory and then writing it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 4:50 PM To: [EMAIL PROTECTED] Subject: Streaming PDF file with the bean:write tag -- please help I would like to be able to display/stream the PDF file in the browser and use the bean:write tag in the JSP to acomplish that. Say I have a form bean that has a byte array field, and I want the jsp to specify the contentType as application/pdf and just have the bean:write tag, such as: bean:write name=mybean property=pdfcontent/ Is this possible to achieve? Are there any hacks/tricks to make it work in a JSP when the form bean has the binary content field? When I do it with with the byte array attribute, it just displays the address of the array in memory (possibly calls toString()). If I make the field of type String and convert the byte array to String in the controller as follows: str = new String(byteArray), it does not get converted correctly and the browser hangs. I know the best way to do it is to have a servlet. But I need to do it in a JSP because of certain limitations of my application. Please help. Thanks. -- 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: Double Checked Locking Help
I don't think synchronization is the answer for this one. The general problem is
that while one thread is running through the enumeration returned from
ServletContext.getAttributeNames, another thread adds or removes an application
scoped attribute. Even if you successfully lock down this method, other methods
are still free to mess with the collection of application scope attributes. It
just seems like the creation and caching of the prefixes array should be done at
startup instead of on-demand. Then, this method would just become something like:
public static String[] getModulePrefixes(ServletContext context) {
return (String[])context.getAttribute(Globals.PREFIXES_KEY);
}
Quoting David Graham [EMAIL PROTECTED]:
I'm looking at fixes for
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21091
1. Synchronize the entire RequestUtils.getModulePrefixes() method.
OR
2. The first thing the method does is checks for prefixes in the context
String[] prefixes = (String[]) context.getAttribute(PREFIXES_KEY);
if (prefixes != null) {
return prefixes;
}
What if the rest of the code below that was inside a
synchronized(RequestUtils.class) {} block and the first thing that block
does is perform the check again?
Is this considered double checked locking? It's slightly different than
the examples I've seen because we would be looking up the value in the
context instead of testing a member variable for null.
I think solution 2 will work but I want to make sure.
Thanks,
David
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
--
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: Double Checked Locking Help
I'm not talking about updating existing attributes. As long as the method has to
invoke ServletContext.getAttributeNames and loop through the enumeration (even
if it's just once within a synchronized method or block), it's possible to
trigger the error. The collection that backs that enumeration is available to
pretty much any other thread that wants to get at it without having to acquire
the locks you hold by synchronizing that particular method. So yes, in this
case, it might only be a concern when the prefixes array has to be initialized
and cached, but the concurrency issue is not limited to just this method.
Quoting David Graham [EMAIL PROTECTED]:
--- Kris Schneider [EMAIL PROTECTED] wrote:
I don't think synchronization is the answer for this one. The general
problem is
that while one thread is running through the enumeration returned from
ServletContext.getAttributeNames, another thread adds or removes an
application
scoped attribute. Even if you successfully lock down this method, other
methods
are still free to mess with the collection of application scope
attributes.
The problem in this case is that it's putting an attribute into the
context for the first time which is a structural modification. Updating
existing context attributes is not a structural modification so we just
need to worry about the initialization in this method.
David
It
just seems like the creation and caching of the prefixes array should be
done at
startup instead of on-demand. Then, this method would just become
something like:
public static String[] getModulePrefixes(ServletContext context) {
return (String[])context.getAttribute(Globals.PREFIXES_KEY);
}
Quoting David Graham [EMAIL PROTECTED]:
I'm looking at fixes for
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21091
1. Synchronize the entire RequestUtils.getModulePrefixes() method.
OR
2. The first thing the method does is checks for prefixes in the
context
String[] prefixes = (String[]) context.getAttribute(PREFIXES_KEY);
if (prefixes != null) {
return prefixes;
}
What if the rest of the code below that was inside a
synchronized(RequestUtils.class) {} block and the first thing that
block
does is perform the check again?
Is this considered double checked locking? It's slightly different
than
the examples I've seen because we would be looking up the value in the
context instead of testing a member variable for null.
I think solution 2 will work but I want to make sure.
Thanks,
David
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
--
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: Status check?
If you're going to cross-compile, you really need to go whole-hog and use the target, bootclass, and extdirs options. See: http://java.sun.com/j2se/1.4.1/docs/tooldocs/solaris/javac.html#crosscomp-options and: http://java.sun.com/j2se/1.4.1/docs/tooldocs/solaris/javac.html#crosscomp-example Karr, David wrote: Perhaps a -target 1.2 option should be specified on our javac targets? I would guess the number of issues with down-compilation from 1.4 to 1.2 is very small, but if we have one in our code base, the compiler won't tell us about it. -Original Message- From: Hajratwala, Nayan (N.) [mailto:[EMAIL PROTECTED] -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Our installation page says our dependency is J2SE 1.2 or later. Does that mean I should compile the binary distribution under the latest J2SE 1.2, or should I use the latest J2SE 1.4? I have been building the releases using J2SE 1.4 for some time now, and I would recommend sticking with that. Going with 1.4 ensures we get the benefits of the latest compiler improvements. The compatibility issue is with the JVM rather than the compiler - we want to be able to run on J2SE 1.2, but we don't need to build the releases with that. I don't believe this is correct. I think it actually is the COMPILER that can cause a compatibility issue. There is an article over at Java World that details this problem. The first example makes it clear. http://www.javaworld.com/javaqa/2003-05/02-qa-0523-version.html? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: composable RequestProcessor
RequestHandler? Quoting David Graham [EMAIL PROTECTED]: That doesn't fit well with method parameter semantics because it's not a noun. You can't say, I'm passing a RequestProcessing to myMethod. David From: Andrew Harris [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: composable RequestProcessor Date: Fri, 30 May 2003 17:37:59 +0100 RequestProcessing? Andrew Harris On 30 May 2003 at 7:39, David Graham wrote: In the 1.x series, we could do something like declare a RequestProcessorInterface, have the existing concrete classes implement that, and then change the underlying code to use interface instead, and avoid any external API changes. I'm fine with changing this in 1.x but not with a name like RequestProcessorInterface or IRequestProcessor. We need to think up a better name but we can leave that discussion for post 1.2 or post suggestions to the enhancement ticket. It would also be good to change ExceptionHandler and the various config objects to interfaces as well but that may need to wait for 2.0. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: RequestUtils.computeURL()
Except that the doc for html:img says: Renders an HTML img element with the image at the specified URL. Like the link tag, URL rewriting will be applied automatically to the value specified in src or page, to maintain session state in the absence of cookies. This will allow dynamic generation of an image where the content displayed for this image will be taken from the attributes of this tag. So ImgTag already does URL rewriting, doesn't it? Quoting James Mitchell [EMAIL PROTECTED]: That was my initial thought, but wanted to bounce it off a few other people first. -- James Mitchell Software Developer/Struts Evangelist http://jakarta.apache.org/struts People demand freedom of speech to make up for the freedom of thought which they avoid. - Soren Aabye Kierkegaard (1813-1855) -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 10:28 AM To: [EMAIL PROTECTED] Subject: Re: RequestUtils.computeURL() Is there any reason that any tag should NOT call computeURL when evaluating a URL that needs a parameter of Map entries added? computeURL also encodes the url with session information which isn't desirable for images. Maybe ImgTag should just replace with amp; itself without calling computeURL. David _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - 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] -- 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]
Design clarification for locale handling
As a reference, this is a follow-on to bug 17371 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17371). While I understand David's rationale behind closing the bug, I really think the design is broken (and apparently has been since 1.0). So, instead of just reopening the bug, I thought it would be best to get some feedback from the development community. With regard to locale, it seems like HtmlTag's responsibility should end at rendering the html tag's lang attribute. As it currently stands, it will also create a session and store a locale under Globals.LOCALE_KEY if its locale property is set to true. Which means it's perfeclty legal to have configured controller locale=false/, and then a JSP with %@ page session=false % and html:html locale=true and end up with having a session created and a locale stored in it. RequestProcessor.processLocale seems like the appropriate place to handle the session creation and locale storage. Any other entity that needs a handle to the locale can just call RequestUtils.retrieveUserLocale. Are there other places in the framework besides RequestProcessor.processLocale and HtmlTag.getCurrentLocale that also store the locale in the session? Would appreciate any feedback you can provide. Thanks. -- 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: Design clarification for locale handling
As you say, most apps are probably using sessions. In fact, unless an app is explicitly configured with controller locale=false/, Struts will always create a session on its behalf. So my guess would be that the apps that use html:html locale=true are just doing a redundant storage of the locale. In other words, RequestProcessor.processLocale has already placed the locale in the session, HtmlTag.getCurrentLocale retrieves it and then stores it again. I'm not sure backwards compatibility would really be impacted. Quoting David Graham [EMAIL PROTECTED]: I agree with you that the html tag should not be performing the logic it does now; however, we can't change behavior that people may be relying on. Keep in mind that your app is a special case where you're not using sessions. If many other apps weren't using sessions we would have had many more bug reports before now. So, you can subclass the html tag to change its behavior or simply not use it at all and render html yourself. I'll open an enhancement request against 2.0 so we can consider this issue when backwards compatibility doesn't matter as much. David As a reference, this is a follow-on to bug 17371 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17371). While I understand David's rationale behind closing the bug, I really think the design is broken (and apparently has been since 1.0). So, instead of just reopening the bug, I thought it would be best to get some feedback from the development community. With regard to locale, it seems like HtmlTag's responsibility should end at rendering the html tag's lang attribute. As it currently stands, it will also create a session and store a locale under Globals.LOCALE_KEY if its locale property is set to true. Which means it's perfeclty legal to have configured controller locale=false/, and then a JSP with %@ page session=false % and html:html locale=true and end up with having a session created and a locale stored in it. RequestProcessor.processLocale seems like the appropriate place to handle the session creation and locale storage. Any other entity that needs a handle to the locale can just call RequestUtils.retrieveUserLocale. Are there other places in the framework besides RequestProcessor.processLocale and HtmlTag.getCurrentLocale that also store the locale in the session? Would appreciate any feedback you can provide. Thanks. -- 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] _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: Design clarification for locale handling
David's already asked me to put up or shut up ;-), but for the record... Even if no requests ever get processed by ActionServlet, having HtmlTag just use RequestUtils.retrieveUserLocale will still do the right thing (i.e. return a locale based on the Accept-Language header, or the default locale for the server). I don't see how that would break localization behavior. Quoting Craig R. McClanahan [EMAIL PROTECTED]: On Wed, 26 Feb 2003, Kris Schneider wrote: Date: Wed, 26 Feb 2003 08:45:48 -0500 From: Kris Schneider [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Design clarification for locale handling As a reference, this is a follow-on to bug 17371 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17371). While I understand David's rationale behind closing the bug, I really think the design is broken (and apparently has been since 1.0). So, instead of just reopening the bug, I thought it would be best to get some feedback from the development community. The HTML tag does its own locale-setting (and therefore session creation) because some people still set their apps up to all URLs directly to JSP pages (bypassing the controller servlet, so that the locale setup it does is also skipped). Removing this would break the localization behavior of any app that depends on it. Craig With regard to locale, it seems like HtmlTag's responsibility should end at rendering the html tag's lang attribute. As it currently stands, it will also create a session and store a locale under Globals.LOCALE_KEY if its locale property is set to true. Which means it's perfeclty legal to have configured controller locale=false/, and then a JSP with %@ page session=false % and html:html locale=true and end up with having a session created and a locale stored in it. RequestProcessor.processLocale seems like the appropriate place to handle the session creation and locale storage. Any other entity that needs a handle to the locale can just call RequestUtils.retrieveUserLocale. Are there other places in the framework besides RequestProcessor.processLocale and HtmlTag.getCurrentLocale that also store the locale in the session? Would appreciate any feedback you can provide. Thanks. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: Design clarification for locale handling
Which is a potential backwards compatibility issue, not an issue with HtmlTag being able to grab a locale and render its lang attribute. That seems like a fairly weird use-case though. Quoting David Graham [EMAIL PROTECTED]: Even if no requests ever get processed by ActionServlet, having HtmlTag just use RequestUtils.retrieveUserLocale will still do the right thing (i.e. return a locale based on the Accept-Language header, or the default locale for the server). I don't see how that would break localization behavior. Because it also creates a session and stores the Locale in there. Apps may be relying on that object to be in the session by using the html tag. David _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
