Re: c:import

[Craig Longman]

On Tue, 2002-09-17 at 20:59, Hans Bergsten wrote:
> The JSTL  action behaves like a RequestDispatcher.include()
> when you import a resource in the same container. This means (as defined
> by the Servlet spec) that the URI for the request is the URI for the
> _including_ resource (the JSP page in this case), so the behavior you
> see is correct.

k.

> You do have access to the URI info that was used to include the resource
> through request attributes. This is from the Servlet spec:
> 
>SRV.8.3.1 Included Request Parameters
>Except for servlets obtained by using the getNamedDispatcher method,
>a servlet being used from within an include has access to the path by
>which it was invoked. The following request attributes are set:
> 
>  javax.servlet.include.request_uri
>  javax.servlet.include.context_path
>  javax.servlet.include.servlet_path
>  javax.servlet.include.path_info
>  javax.servlet.include.query_string
> 
>These attributes are accessible from the included servlet via the
>getAttribute method on the request object.

perfect.  i had actually just noticed all these things in the attribute
list, playing with a servlet and just getting all the parm and attr
names/values to see what was there.

i need to find the SRV spec.

thanks y'all.

-- 

CraigL->Thx();
Be Developer ID: 5852




signature.asc
Description: This is a digitally signed message part

Re: c:import

[Craig Longman]

On Tue, 2002-09-17 at 20:52, Shawn Bayern wrote:
> On 17 Sep 2002, Craig Longman wrote:
> 
> > when you include a file via c:insert that actually maps to another
> > servlet, it appears that the request object (in tomcat 4.1.10 at
> > least) doesn't reflect any of the actual request being delivered.  
> > i'm a little confused as to what i can do now.
> 
> Unless I'm misunderstanding your question, this sounds like the right
> behavior.  The relevant specification is actually the Servlet
> specification (section SRV.8.2), though see JSTL 1.0 section 7.4 for the
> specification of .

hm. i only had the jstl and jsp specs.  thanks, i'll try and find the
servlet spec.

> > however, when this url is invoked via a ,
> > all of the information retrievable via the request object refer to the
> > 'wrapping' request, to the jsp page contains the c:import.  the
> > parameters passed are available, but don't show up in the query string
> > (because the query string is for the containing jsp page).
> 
> I don't see any query string in the example; did you mean to write
> /mapper?file-to-get?  I'm not sure, from your description, what is being
> lost.
> 
> If you need to pass parameters directly, you can use the  tag as
> a subtag of .  Otherwise, I think I'd need a little more
> information to help.

the parameters i refer to are, in fact, passed via .  so, the
relevant jsp file portion looks like:

 
  
 

in the mapper servlet, i can do a request.getParameter( "name1" ) and
get whatever value lookup1 contained.  but if i do a
request.getQueryString(), it returns blank.  also, i have no way of
extracting the 'testfile' information, it is simply lost; a call to
request.getRequestURI(), .getRequestURL() and .getServletPath() will
return references to the calling page (debug.jsp in this case).  i guess
i could just turn the filename into a parameter also.

it just a bit disconcerting, i'm going to have to be very careful about
calling existing servlets as they will quite possibly break as well as
handling (possibly special handling) of cases where a servlet is called
either directly or imported.  this might not be the case with a
cross-context servlet, and probably not the case with an absolute url,
i'll have to test.  but then there is extra overhead in using those
types of connections also.

thanks.

-- 

CraigL->Thx();
Be Developer ID: 5852




signature.asc
Description: This is a digitally signed message part

Re: c:import

[Hans Bergsten]

Craig Longman wrote:
> i've been trying to figure out what happens to the request object when
> you import a file, but had no answers from the tomcat list, so i thought
> i'd try here.
> 
> when you include a file via c:insert that actually maps to another
> servlet, it appears that the request object (in tomcat 4.1.10 at least)
> doesn't reflect any of the actual request being delivered.  i'm a little
> confused as to what i can do now.
> 
> the specifics are that i have a servlet that i want to call with a url
> indicating a specific file that i want retrieved.  this would be most
> useful if it could be called directly, or imported into another jsp
> file.  the url would look like:
> 
>  /mapper/file-to-get
> 
> the file-to-get would be retrieved by the servlet and then it looks up
> the correct file and processes it.
> 
> however, when this url is invoked via a ,
> all of the information retrievable via the request object refer to the
> 'wrapping' request, to the jsp page contains the c:import.  the
> parameters passed are available, but don't show up in the query string
> (because the query string is for the containing jsp page).
> 
> is this the correct behaviour?  i can't find anything definitive in the
> spec, so i'm not sure if this is a bug (it seems like 4.1.10 has a few)
> or the expected behaviour.  and if it is expected, then is there _any_
> of retrieving 'file-to-get' part if the servlet is invoked via an
> import?

The JSTL  action behaves like a RequestDispatcher.include()
when you import a resource in the same container. This means (as defined
by the Servlet spec) that the URI for the request is the URI for the
_including_ resource (the JSP page in this case), so the behavior you
see is correct.

You do have access to the URI info that was used to include the resource
through request attributes. This is from the Servlet spec:

   SRV.8.3.1 Included Request Parameters
   Except for servlets obtained by using the getNamedDispatcher method,
   a servlet being used from within an include has access to the path by
   which it was invoked. The following request attributes are set:

 javax.servlet.include.request_uri
 javax.servlet.include.context_path
 javax.servlet.include.servlet_path
 javax.servlet.include.path_info
 javax.servlet.include.query_string

   These attributes are accessible from the included servlet via the
   getAttribute method on the request object.

Hans
-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
JavaServer Pageshttp://TheJSPBook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: c:import

[Shawn Bayern]

On 17 Sep 2002, Craig Longman wrote:

> when you include a file via c:insert that actually maps to another
> servlet, it appears that the request object (in tomcat 4.1.10 at
> least) doesn't reflect any of the actual request being delivered.  
> i'm a little confused as to what i can do now.

Unless I'm misunderstanding your question, this sounds like the right
behavior.  The relevant specification is actually the Servlet
specification (section SRV.8.2), though see JSTL 1.0 section 7.4 for the
specification of .

> however, when this url is invoked via a ,
> all of the information retrievable via the request object refer to the
> 'wrapping' request, to the jsp page contains the c:import.  the
> parameters passed are available, but don't show up in the query string
> (because the query string is for the containing jsp page).

I don't see any query string in the example; did you mean to write
/mapper?file-to-get?  I'm not sure, from your description, what is being
lost.

If you need to pass parameters directly, you can use the  tag as
a subtag of .  Otherwise, I think I'd need a little more
information to help.

Best,

-- 
Shawn Bayern
"JSTL in Action"   http://www.jstlbook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

c:import

[Craig Longman]

i've been trying to figure out what happens to the request object when
you import a file, but had no answers from the tomcat list, so i thought
i'd try here.

when you include a file via c:insert that actually maps to another
servlet, it appears that the request object (in tomcat 4.1.10 at least)
doesn't reflect any of the actual request being delivered.  i'm a little
confused as to what i can do now.

the specifics are that i have a servlet that i want to call with a url
indicating a specific file that i want retrieved.  this would be most
useful if it could be called directly, or imported into another jsp
file.  the url would look like:

 /mapper/file-to-get

the file-to-get would be retrieved by the servlet and then it looks up
the correct file and processes it.

however, when this url is invoked via a ,
all of the information retrievable via the request object refer to the
'wrapping' request, to the jsp page contains the c:import.  the
parameters passed are available, but don't show up in the query string
(because the query string is for the containing jsp page).

is this the correct behaviour?  i can't find anything definitive in the
spec, so i'm not sure if this is a bug (it seems like 4.1.10 has a few)
or the expected behaviour.  and if it is expected, then is there _any_
of retrieving 'file-to-get' part if the servlet is invoked via an
import?

-- 

CraigL->Thx();
Be Developer ID: 5852




signature.asc
Description: This is a digitally signed message part

Re: set Property error

[Shawn Bayern]

On Wed, 18 Sep 2002, Hao Ding wrote:

> Now when I used JSTL core tags like follows:
> 
> 
> I got a error like: javax.servlet.jsp.JspTagException: Invalid property 
> in :  "urlPrefix"

The "target" requires an expression in JSTL's expression language.  You
need to write

 

Hope that helps,

-- 
Shawn Bayern
"JSTL in Action"   http://www.jstlbook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

set Property error

[Hao Ding]

Hi,

I instantiate a bean instance in my JSP page like follows:


Using JSP standard tags  to set the bean property works 
  well.


Now when I used JSTL core tags like follows:


I got a error like: javax.servlet.jsp.JspTagException: Invalid property 
in :  "urlPrefix"

What is wrong in the JSTL code?
Cheers,
Hao


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: c:out and \n

[Henri Yandell]

I'm not sure. There's nothing really 'html'y about the problem of 'we want
to replace \n'. It's only the with bit that gets htmly. So I'm just
grumbling about the name :)

I was aiming to have a future:

  [blanks="true|false"]
>  [tabs="true|false" [tabLength="noOfChars"]]>
>  text to be converted
>
>
>nls:   replace all \n with 
>blanks:replace multiple blanks with  , but leave single
>   blanks alone
>tabs:  replace tabs with a number of  
>tabLength: how many characters a tab represents (default is 8)
>
> The "blanks" and "tabs" replacements make it possible to handle simple
> formatted (indented) text. Other replacements are possible, of course,
> such as "*" to "", but this is a start.
>
> Hans
>
> Henri Yandell wrote:
> >
> > On Tue, 17 Sep 2002, zze-JEANJEAN S ext FTRD/DMI/SOP wrote:
> >
> >
> Is there a tag to convert \n to  ??
> >>>
> >>>You should be able to use the String Taglib or the Regexp Taglib.
> >>>
> >>
> >>The str:replace tag is not easy to use : in the replace propertie the \n
> >>is not understood :(( You have to put in this propetie a real new line,
> >>so the code is not really readable :(
> >>For instance :
> >>...
> >> >>value="${requestScope[theKey].address1}"/>
> >>...
> >
> >
> > Yeah. This needs to be solved doesn't it.
> >
> > Solutions:
> >
> > Make replace accept \n as being a newline. This would be doable, but what
> > if someone wanted to replace a \n sequence? Is it acceptable to make
> > 'tabs' illegal in the replace etc. Probably not.
> >
> > Add a replaceJava attribute, for specifying the replace tag as a Java
> > attribute. Would want a withJava attribute too.
> > Or maybe this is an encoding="java" attribute.
> >
> > Have a replaceNewline tag. A bit weak as you won't be able to replace
> > something with a newline in. Also has weaknesses as I'm trying to collate
> > similar functionality and not create more tags.
> >
> > 
> > I seem to recall that there are no XML character entities that work
> > there, but possible I could make one work. Whether this would be
> > cross-server though, I don't know.
> >
> > Most people will want \n to work I imagine, and won't care that they have
> > to do \\n to replace a \ and a n. If I change it so that all
> > String attributes get unescaped for Java entities, and maybe even all
> > content as well. I wonder if this will hurt anything...
> >
> > If not, I'll aim for this feature to be in a 2.0 release. My apologies for
> > not being able to get it in sooner.
> >
> > Hen
> >
> >
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> >
>
> --
> Hans Bergsten [EMAIL PROTECTED]
> Gefion Software   http://www.gefionsoftware.com
> JavaServer Pages  http://TheJSPBook.com
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: c:out and \n

[Hans Bergsten]

Because of all the escaping problems, I think a separate action is the
best solution for this instead of trying to do some tricks with the
replace action. How about something like this:

   
 text to be converted
   

   nls:   replace all \n with 
   blanks:replace multiple blanks with  , but leave single
  blanks alone
   tabs:  replace tabs with a number of  
   tabLength: how many characters a tab represents (default is 8)

The "blanks" and "tabs" replacements make it possible to handle simple
formatted (indented) text. Other replacements are possible, of course,
such as "*" to "", but this is a start.

Hans

Henri Yandell wrote:
> 
> On Tue, 17 Sep 2002, zze-JEANJEAN S ext FTRD/DMI/SOP wrote:
> 
> 
Is there a tag to convert \n to  ??
>>>
>>>You should be able to use the String Taglib or the Regexp Taglib.
>>>
>>
>>The str:replace tag is not easy to use : in the replace propertie the \n
>>is not understood :(( You have to put in this propetie a real new line,
>>so the code is not really readable :(
>>For instance :
>>...
>>>value="${requestScope[theKey].address1}"/>
>>...
> 
> 
> Yeah. This needs to be solved doesn't it.
> 
> Solutions:
> 
> Make replace accept \n as being a newline. This would be doable, but what
> if someone wanted to replace a \n sequence? Is it acceptable to make
> 'tabs' illegal in the replace etc. Probably not.
> 
> Add a replaceJava attribute, for specifying the replace tag as a Java
> attribute. Would want a withJava attribute too.
> Or maybe this is an encoding="java" attribute.
> 
> Have a replaceNewline tag. A bit weak as you won't be able to replace
> something with a newline in. Also has weaknesses as I'm trying to collate
> similar functionality and not create more tags.
> 
> 
> I seem to recall that there are no XML character entities that work
> there, but possible I could make one work. Whether this would be
> cross-server though, I don't know.
> 
> Most people will want \n to work I imagine, and won't care that they have
> to do \\n to replace a \ and a n. If I change it so that all
> String attributes get unescaped for Java entities, and maybe even all
> content as well. I wonder if this will hurt anything...
> 
> If not, I'll aim for this feature to be in a 2.0 release. My apologies for
> not being able to get it in sooner.
> 
> Hen
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 

-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
JavaServer Pageshttp://TheJSPBook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: c:out and \n

[Shawn Bayern]

On Tue, 17 Sep 2002, Henri Yandell wrote:

> Most people will want \n to work I imagine, and won't care that they
> have to do \\n to replace a \ and a n. If I change it so that all
> String attributes get unescaped for Java entities, and maybe even all
> content as well. I wonder if this will hurt anything...

It probably wouldn't, but unfortunately JSP's fighting you on this point.  

If a user enters "\n" as the attribute for a tag, it comes through to your
tag as "n", for "\" is handled by the JSP container (per section JSP.2.6).
The "\" character needs to be escaped as "\\", meaning that "\n" would
need to be entered as "\\n", and "\n" would need to be entered as "n".  
(This is reminiscent of situations where a Unix tool, not the Unix shell,
must see the "\" escape.)

Thus, while I'd have preferred this solution personally, it might be
better to choose one of the other approaches.  I don't have any ideas off
the top of my head for a syntax that seems pleasant for this...

-- 
Shawn Bayern
"JSTL in Action"   http://www.jstlbook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: c:out and \n

[Henri Yandell]

On Tue, 17 Sep 2002, zze-JEANJEAN S ext FTRD/DMI/SOP wrote:

> > > Is there a tag to convert \n to  ??
> >
> > You should be able to use the String Taglib or the Regexp Taglib.
> >
> The str:replace tag is not easy to use : in the replace propertie the \n
> is not understood :(( You have to put in this propetie a real new line,
> so the code is not really readable :(
> For instance :
> ...
>  value="${requestScope[theKey].address1}"/>
> ...

Yeah. This needs to be solved doesn't it.

Solutions:

Make replace accept \n as being a newline. This would be doable, but what
if someone wanted to replace a \n sequence? Is it acceptable to make
'tabs' illegal in the replace etc. Probably not.

Add a replaceJava attribute, for specifying the replace tag as a Java
attribute. Would want a withJava attribute too.
Or maybe this is an encoding="java" attribute.

Have a replaceNewline tag. A bit weak as you won't be able to replace
something with a newline in. Also has weaknesses as I'm trying to collate
similar functionality and not create more tags.


I seem to recall that there are no XML character entities that work
there, but possible I could make one work. Whether this would be
cross-server though, I don't know.

Most people will want \n to work I imagine, and won't care that they have
to do \\n to replace a \ and a n. If I change it so that all
String attributes get unescaped for Java entities, and maybe even all
content as well. I wonder if this will hurt anything...

If not, I'll aim for this feature to be in a 2.0 release. My apologies for
not being able to get it in sooner.

Hen


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: c:out and \n

[zze-JEANJEAN S ext FTRD/DMI/SOP]

>
> On Mon, 16 Sep 2002, zze-JEANJEAN S ext FTRD/DMI/SOP wrote:
> 
> > The c:out tag convert special characters to character entities, why
> > not do the same thing with \n (to ) ? 
> 
> Because such a translation isn't general-purpose or based on the rules
of
> XML; JSTL isn't tied to HTML specifically.
> 
Off course, but in fact, it's usually used with HTML, so it's could be
an option...

> 
> > Is there a tag to convert \n to  ??
> 
> You should be able to use the String Taglib or the Regexp Taglib.
> 
The str:replace tag is not easy to use : in the replace propertie the \n
is not understood :(( You have to put in this propetie a real new line,
so the code is not really readable :(
For instance :
...

...

bye,

Stephane

--
To unsubscribe, e-mail:   
For additional commands, e-mail: