redirect

2002-11-21 Thread Stefan 
Hi,

Is the c:redirect url=/ equivalent in scriptlets response.sendRedirect() ?

Thanks,

Stef

Question for Bergsten

2002-11-21 Thread Stefan 
Hi,

IN your book 'JavaServerPages' on page 580 where you are listing response objects 
methods, you list 3 deprecated methods:

public string encodeRedirectURL(String url)  , You go on to say in Servlet 2.1 use 
'encodeRedirectURL(String url)'

How is that different?

Stef

Re: JSTL Bug - requestScope[var] not working

2002-11-21 Thread Shawn Bayern 
On Thu, 21 Nov 2002, Scott Goldstein wrote:

 I think this may have already been posted, but I don't recall the
 answer.
 
 Aren't the following two snippets identical?
 
 %
 String value = foo;
 %
 
 c:out value=${requestScope[value]}/
 
 and
 
 %= request.getAttribute(value) %

Nope.  Scripting variables are not automatically made into scoped
attributes, and the EL can only refer to scoped attributes.  If you added

  pageContext.setAttribute(foo, foo);

to the upper scriptlet, then the code would be identical.

 The first is returning null and the second is returning the
 appropriate attribute value.  I looked in the JSTL spec and it looks
 like the first should work.
 
 Is this a bug?

No, the behavior is as expected.

-- 
Shawn Bayern
JSTL in Action   http://www.manning.com/bayern


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Taglibs to provide an abstraction for mobile device guis

2002-11-21 Thread Stefan 
Hi,

Are there any taglibs out there that provide an abstraction layer for PDA device 
displays? An example of such would be the Microsoft ASP.NET mobile controls. The 
controls will properly render the gui widgets on about 200 devices ...

Thanks,

Stef

Re: JSTL Bug - requestScope[var] not working

2002-11-21 Thread Henri Yandell 

I get pretty stupid with JSTL sometimes, but aren't you trying to treat
requestScope as a map?

ie) it should be requestScope.var?

Other useful things that took me a while to get:

request.getParameter(Xxx) is available as:

param.Xxx

and the request itself can be got to via:

pageContext.request.remoteUser


[jsut trying to help until one of the real JSTL guys shows up :) ]

Hen

On Thu, 21 Nov 2002, Scott Goldstein wrote:

 I think this may have already been posted, but I don't recall the
 answer.

 Aren't the following two snippets identical?

 %
 String value = foo;
 %

 c:out value=${requestScope[value]}/

 and

 %= request.getAttribute(value) %

 The first is returning null and the second is returning the appropriate
 attribute value.  I looked in the JSTL spec and it looks like the first
 should work.

 Is this a bug?

 Thanks.

 Scott


 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]




--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: JSTL Bug - requestScope[var] not working

2002-11-21 Thread Henri Yandell 

I seem to have a wonderful ability to not see Shawn's replies. Sorry
Shawn.

On Thu, 21 Nov 2002, Henri Yandell wrote:


 I get pretty stupid with JSTL sometimes, but aren't you trying to treat
 requestScope as a map?

 ie) it should be requestScope.var?

 Other useful things that took me a while to get:

 request.getParameter(Xxx) is available as:

 param.Xxx

 and the request itself can be got to via:

 pageContext.request.remoteUser


 [jsut trying to help until one of the real JSTL guys shows up :) ]

 Hen

 On Thu, 21 Nov 2002, Scott Goldstein wrote:

  I think this may have already been posted, but I don't recall the
  answer.
 
  Aren't the following two snippets identical?
 
  %
  String value = foo;
  %
 
  c:out value=${requestScope[value]}/
 
  and
 
  %= request.getAttribute(value) %
 
  The first is returning null and the second is returning the appropriate
  attribute value.  I looked in the JSTL spec and it looks like the first
  should work.
 
  Is this a bug?
 
  Thanks.
 
  Scott
 
 
  --
  To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
  For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 
 


 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]




--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: Question for Bergsten

2002-11-21 Thread Hans Bergsten 
Stefan wrote:

Hi,

IN your book 'JavaServerPages' on page 580 where you are listing response objects methods, you list 3 deprecated methods:

public string encodeRedirectURL(String url)  , You go on to say in Servlet 2.1 use 'encodeRedirectURL(String url)'

How is that different?


First, please send questions about my book that are not of obvious
interest to other readers on this list to me or O'Reilly (there are
references to web sites and email addresses in the Preface, but
[EMAIL PROTECTED] always works).

To answer your question, the deprecated method is encodeRedirectUrl()
(note the mixed case in Url), replaced with encodeRedirectURL() (note
URL in all caps). This change was done for consistency with other
methods that contains URL in their names.

Hans
--
Hans Bergsten[EMAIL PROTECTED]
Gefion Software   http://www.gefionsoftware.com/
Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0
Details athttp://TheJSPBook.com/


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: Question for Bergsten

2002-11-21 Thread Henri Yandell 


On Thu, 21 Nov 2002, Hans Bergsten wrote:

 To answer your question, the deprecated method is encodeRedirectUrl()
 (note the mixed case in Url), replaced with encodeRedirectURL() (note
 URL in all caps). This change was done for consistency with other
 methods that contains URL in their names.

I wonder if Sun will ever get around to dumping the acronym-rule bit from
their coding standard. Or is it already gone?

[as in, URL is wrong by the Java Coding Standard, but Url is right]

Hen


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: Question for Bergsten

2002-11-21 Thread Shawn Bayern 
On Thu, 21 Nov 2002, Henri Yandell wrote:

 I wonder if Sun will ever get around to dumping the acronym-rule bit
 from their coding standard. Or is it already gone?
 
 [as in, URL is wrong by the Java Coding Standard, but Url is right]

No, it's still there, but it's not universally followed.  To my knowledge,
it's also unclear what you're supposed to do with two adjacent acronyms,
as in HttpURLConnection, which mixes the two approaches.

Shawn


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: JSTL Bug - requestScope[var] not working

2002-11-21 Thread Karr, David 
If Shawn's response wasn't clear, I'm not sure what else we can say.  The EL parser 
doesn't read scripting variables.  It doesn't know anything about them.  It can't use 
them.  Your first example doesn't work because it's trying to reference a scripting 
variable.  From the EL's point of view, there is no value scoped attribute, so the 
result is null.

You should read the specification, if you haven't yet.

 -Original Message-
 From: Scott Goldstein [mailto:[EMAIL PROTECTED]]
 
 I'm not sure that I follow.  How about these two snippets:
 
 %
  String value = foo;
 %
 
 c:out value=${requestScope[value]}/
 
 and
 
 c:out value=${requestScope[foo]}/
 
 The second one works, while the first doesn't.  The only 
 difference is that 
 the second is using a string literal for the index and the 
 first is using a 
 scripting variable.  Are you saying that scripting variables 
 cannot be used as 
 indexes?
 
 Basically, prior to this jsp being executed, I've done the following:
 
 request.setAttribute(foo, SomeTextToRetrieve);
 
 So, what I think should happen in the first snippet, is that 
 the variable, 
 value, is resolved to it's String literal, foo and then the 
 expression is 
 evaluated just like the second snippet.  This does not appear 
 to be happening.
 
 Scott
 
 = Original Message From Shawn Bayern 
 [EMAIL PROTECTED] =
 On Thu, 21 Nov 2002, Scott Goldstein wrote:
 
  I think this may have already been posted, but I don't recall the
  answer.
 
  Aren't the following two snippets identical?
 
  %
  String value = foo;
  %
 
  c:out value=${requestScope[value]}/
 
  and
 
  %= request.getAttribute(value) %
 
 Nope.  Scripting variables are not automatically made into scoped
 attributes, and the EL can only refer to scoped attributes.  
 If you added
 
   pageContext.setAttribute(foo, foo);
 
 to the upper scriptlet, then the code would be identical.
 
  The first is returning null and the second is returning the
  appropriate attribute value.  I looked in the JSTL spec 
 and it looks
  like the first should work.
 
  Is this a bug?
 
 No, the behavior is as expected.

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: taglib directives confusion

2002-11-21 Thread Travis McCauley 
I think I was confused because I took the taglib directive out of a 
page that is only included by other pages. I can do that and the page 
still works. Is it not supposed to? I know the page is re-compiling.

Travis

Travis McCauley wrote:

Hello,

I am still new to jsp and jstl and I'm a little confused about why 
it is not necessary to add a taglib directive at the top of a page 
for the standard taglib like:

%@ taglib prefix = c uri = http://java.sun.com/jstl/core; %

You do need to add this taglib directive. What makes you think you
don't?


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: taglib directives confusion

2002-11-21 Thread Hans Bergsten 
Travis McCauley wrote:

I think I was confused because I took the taglib directive out of a page 
that is only included by other pages. I can do that and the page still 
works. Is it not supposed to? I know the page is re-compiling.

If you include a page with the include directive (%@ include file=... %)
it's merged with the including page and becomes part of the same
translation unit. This means it shares all taglib declarations used in
the including page, so yes, in this scenario, declaring the tag library
in the included page as well is redundant.

However, if you include the page with the include action (jsp:include
page=... /), the included page must be self sustained. It's converted
to its own servlet and at runtime, it's executed and only the _result_
is included in the including page. In this scenarion, the included page
must declare all tag libraries it uses.

Hans


Travis McCauley wrote:


Hello,

I am still new to jsp and jstl and I'm a little confused about why it 
is not necessary to add a taglib directive at the top of a page for 
the standard taglib like:

%@ taglib prefix = c uri = http://java.sun.com/jstl/core; %


You do need to add this taglib directive. What makes you think you
don't?



--
To unsubscribe, e-mail:   
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: 
mailto:[EMAIL PROTECTED]


--
Hans Bergsten[EMAIL PROTECTED]
Gefion Software   http://www.gefionsoftware.com/
Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0
Details athttp://TheJSPBook.com/


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: taglib directives confusion

2002-11-21 Thread Mark Goking 

is there an administrator here? :) i want to be unsubscribed to the mailing list. as 
well as jakarta. problem is i cant unsubscribe. so im hoping that someone can remove 
me manually from the mailing list database. =)

mark

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.422 / Virus Database: 237 - Release Date: 11/20/2002
 

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

JSTL Bug - requestScope[var] not working

2002-11-21 Thread Scott Goldstein 
I think this may have already been posted, but I don't recall the
answer.

Aren't the following two snippets identical?

%
String value = foo;
%

c:out value=${requestScope[value]}/

and

%= request.getAttribute(value) %

The first is returning null and the second is returning the appropriate
attribute value.  I looked in the JSTL spec and it looks like the first
should work.

Is this a bug?

Thanks.

Scott


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: JSTL Bug - requestScope[var] not working

2002-11-21 Thread Shawn Bayern 
On Thu, 21 Nov 2002, Scott Goldstein wrote:

 I'm not sure that I follow.  How about these two snippets:
 
 %
  String value = foo;
 %
 
 c:out value=${requestScope[value]}/
 
 and
 
 c:out value=${requestScope[foo]}/
 
 The second one works, while the first doesn't.

Yes.  Again, this is correct.  In fact, the problem is the same:  in the
first example (which is the same as what you showed before), 'value' is
simply a scripting variable.  It is not automatically visible to the EL;
the EL has no way to read scripting variables.  Instead, it must be made a
scoped variable explicitly, as by pageContext.setAttribute().

 The only difference is that the second is using a string literal for
 the index and the first is using a scripting variable.  Are you saying
 that scripting variables cannot be used as indexes?

I'm saying that scripting variables cannot be accessed at all by the EL.
Any EL-accessible values can be used as indices.

Shawn


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]