Re: Value of the variable set with x:set , is [attribute_name=attribute_value] instead of just attribute_value
Thank you, the solution you have provided works perfectly for my case.
I was just wondering that if [attribute_name=attribute_value] does not have
any purpose then, why not just set the value to attribute_value directly when
using x:set
If it does have a purpose then the way x:set works now is fine. Anyway this
is probably for another discussion thread.
I think we can close this thread now. Thank you once again for the help.
Kris Schneider [EMAIL PROTECTED] wrote:
One way:
c:set var=keyx:out
select=$transformed/Products/Product[1]/@l_id//c:set
c:out value=${key}/
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Is there a way to turn-off character escaping when using c:set ?
I'm processing an XML file and trying to get the value stored in the ProductURL
attribute of a node.
I'm doing this:
c:set var=valuex:out select=@ProductURL//c:set
When I output the value of @ProductURL , with just x:out, I get this:
http://www.something.com?qs1=some_valueqs2=another_value
(Notice how the ampersand is not escaped in the above URL generated from x:out)
But when I do
c:redirect url=${value}/ it is not working properly because , the URL
stored inside value has escaped ampersands and c:redirect
requires unescaped ampersands
I could do this to get the unescaped URL:
c:out value=${value} escapeXml=false/
But, I need the unescaped url in a variable so that it can be added to the
url attribute of
c:redirect url=${value}/
-
See the all-new, redesigned Yahoo.com. Check it out.
Re: Is there a way to turn-off character escaping when using c:set ?
x:out is doing the escaping by default. Try:
c:set var=valuex:out select=@ProductURL escapeXml=false//c:set
Rashmi Rubdi wrote:
I'm processing an XML file and trying to get the value stored in the ProductURL
attribute of a node.
I'm doing this:
c:set var=valuex:out select=@ProductURL//c:set
When I output the value of @ProductURL , with just x:out, I get this:
http://www.something.com?qs1=some_valueqs2=another_value
(Notice how the ampersand is not escaped in the above URL generated from x:out)
But when I do
c:redirect url=${value}/ it is not working properly because , the URL stored inside value has escaped ampersands and c:redirect
requires unescaped ampersands
I could do this to get the unescaped URL:
c:out value=${value} escapeXml=false/
But, I need the unescaped url in a variable so that it can be added to the url attribute of
c:redirect url=${value}/
--
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: Is there a way to turn-off character escaping when using c:set ?
This worked! Thank you. Kris Schneider [EMAIL PROTECTED] wrote: x:out is doing the escaping by default. Try: c:set var=valuex:out select=@ProductURL escapeXml=false//c:set __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Nested request in c:import
Hi, Under jsp 2.0 (jstl 1.2), is there any way to force c:import, or perhaps the requestDispatcher.include() in particular, to set up a new request scope when the resource is in the same context? I'm using c:import to do sort of a lightweight tiles replacement for a page menu, and the imported servlet execution is stomping on some of my request variables that my controller sets up for the view. So, for example: Controller does request.setAttribute(someModel,x); jsp does c:import imported controller does request.setAttribute(someModel,y) jsp for imported controller is happy (finds y) import returns jspi for original controller finds y instead of x under someModel, and bad things happen. I'd really like the imported servlet to see a wrapped/cloned request, in which it muck with anything, but that the original request context is untouched. I don't know if this prohibited by the jsp spec though. Thanks, -Clint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nested request in c:import
For the same context, c:import is the equivalent of RequestDispatcher.include, so the request scope is essentially shared. Is it possible for you to refactor either the included servlet or your controller to avoid the stomping? Clint Popetz wrote: Hi, Under jsp 2.0 (jstl 1.2), is there any way to force c:import, or perhaps the requestDispatcher.include() in particular, to set up a new request scope when the resource is in the same context? I'm using c:import to do sort of a lightweight tiles replacement for a page menu, and the imported servlet execution is stomping on some of my request variables that my controller sets up for the view. So, for example: Controller does request.setAttribute(someModel,x); jsp does c:import imported controller does request.setAttribute(someModel,y) jsp for imported controller is happy (finds y) import returns jspi for original controller finds y instead of x under someModel, and bad things happen. I'd really like the imported servlet to see a wrapped/cloned request, in which it muck with anything, but that the original request context is untouched. I don't know if this prohibited by the jsp spec though. Thanks, -Clint -- 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: Nested request in c:import
On 8/3/06, Kris Schneider [EMAIL PROTECTED] wrote: For the same context, c:import is the equivalent of RequestDispatcher.include, so the request scope is essentially shared. Is it possible for you to refactor either the included servlet or your controller to avoid the stomping? Not easily. But I just checked around, and the Spring MVC controller had a bit of code to check for the presence of javax.servlet.include.request_uri in the request and save away a copy of the request attributes, restoring them after view rendering, so that's what I'll do. -Clint Clint Popetz wrote: Hi, Under jsp 2.0 (jstl 1.2), is there any way to force c:import, or perhaps the requestDispatcher.include() in particular, to set up a new request scope when the resource is in the same context? I'm using c:import to do sort of a lightweight tiles replacement for a page menu, and the imported servlet execution is stomping on some of my request variables that my controller sets up for the view. So, for example: Controller does request.setAttribute(someModel,x); jsp does c:import imported controller does request.setAttribute(someModel,y) jsp for imported controller is happy (finds y) import returns jspi for original controller finds y instead of x under someModel, and bad things happen. I'd really like the imported servlet to see a wrapped/cloned request, in which it muck with anything, but that the original request context is untouched. I don't know if this prohibited by the jsp spec though. Thanks, -Clint -- 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]
