1.5 Value and Method Binding:
"Tip: Expression Language statements either start with "${" or "#{" and end with
"}" " => could you explain the difference beetween "$" and "#" (I know that
there is one, but I don't know it myself ;-) )

3.3. Download the JSTL library
"If you know where I find the standard JSTL1.2 reference implementation please
email this information to me." => there is no separate download, it seems to be
part of the JavaEE5 RI (http://java.sun.com/javaee/downloads/index.jsp). I found
it also as part of JBoss 5.

1.5 Value and Method Binding:
"Tip: Expression Language statements either start with "${" or "#{" and end with
"}" " => could you explain the difference beetween "$" and "#" (I know that
there is one, but I don't know it myself ;-) )

3.3. Download the JSTL library
"If you know where I find the standard JSTL1.2 reference implementation please
email this information to me." => there is no separate download, it seems to be
part of the JavaEE5 RI (http://java.sun.com/javaee/downloads/index.jsp). I found
it also as part of JBoss 5.

Wolfgang]]>Wolfgang Knauf2008-11-13T12:47:52-00:00Re: JSF with Eclipse - Tutorialhttps://www.eclipse.org/forums/index.php/mv/msg/151312/476063/#msg_476063
thank you for the feedback.

To 1.5 I believe the following is true (I added it also to the article):
JSP EL expressions are using the ${...} syntax. These EL expressions are
immediately evaluated. JSF EL expressions are of the type #{...}. These
are only evaluated when needed (and otherwisestored as strings).

To 3.3. Shame, I really would like to have a separate download for this.
I'm neither using JBoss nor do I want to download glassfish just for
these libs. So I hope for a better and brighter future and leave this
comment in the article... ;-)

4.4 Fixed

5.4. Fixed

5.5 Fixed

Best regards, Lars

Wolfgang Knauf wrote:
> Hi Lars,
>
> good tutorial!
>
> Some minor things:
>
> 1.5 Value and Method Binding:
> "Tip: Expression Language statements either start with "${" or "#{" and
> end with "}" " => could you explain the difference beetween "$" and "#"
> (I know that there is one, but I don't know it myself ;-) )
>
> 3.3. Download the JSTL library
> "If you know where I find the standard JSTL1.2 reference implementation
> please email this information to me." => there is no separate download,
> it seems to be part of the JavaEE5 RI
> (http://java.sun.com/javaee/downloads/index.jsp). I found it also as
> part of JBoss 5.
>
> 4.4. Create Java Server Page
> Image and code snippet seem to be swapped (correct: first image, then code)
>
> 5.4. Validators
> I miss the implementation of the "validate" (with check for
> login="tester").
>
> 5.5. Resource bundle for messages -> typo in file name:
> "message.properites"
>
> Best regards
>
> Wolfgang

To 1.5 I believe the following is true (I added it also to the article):
JSP EL expressions are using the ${...} syntax. These EL expressions are
immediately evaluated. JSF EL expressions are of the type #{...}. These
are only evaluated when needed (and otherwisestored as strings).

To 3.3. Shame, I really would like to have a separate download for this.
I'm neither using JBoss nor do I want to download glassfish just for
these libs. So I hope for a better and brighter future and leave this
comment in the article... ;-)

4.4 Fixed

5.4. Fixed

5.5 Fixed

Best regards, Lars

Wolfgang Knauf wrote:
> Hi Lars,
>
> good tutorial!
>
> Some minor things:
>
> 1.5 Value and Method Binding:
> "Tip: Expression Language statements either start with "${" or "#{" and
> end with "}" " => could you explain the difference beetween "$" and "#"
> (I know that there is one, but I don't know it myself ;-) )
>
> 3.3. Download the JSTL library
> "If you know where I find the standard JSTL1.2 reference implementation
> please email this information to me." => there is no separate download,
> it seems to be part of the JavaEE5 RI
> (http://java.sun.com/javaee/downloads/index.jsp). I found it also as
> part of JBoss 5.
>
> 4.4. Create Java Server Page
> Image and code snippet seem to be swapped (correct: first image, then code)
>
> 5.4. Validators
> I miss the implementation of the "validate" (with check for
> login="tester").
>
> 5.5. Resource bundle for messages -> typo in file name:
> "message.properites"
>
> Best regards
>
> Wolfgang

--
Lars Vogelhttp://www.vogella.de/eclipse.html - Tutorials about Eclipse http://www.vogella.de/articles/RichClientPlatform/article.ht ml - Eclipse
RCP Tutorial]]>Lars Vogel Unavailable until 15 August 20162008-11-13T21:18:14-00:00Re: JSF with Eclipse - Tutorialhttps://www.eclipse.org/forums/index.php/mv/msg/151312/476064/#msg_476064
>
> To 1.5 I believe the following is true (I added it also to the article):
> JSP EL expressions are using the ${...} syntax. These EL expressions are
> immediately evaluated. JSF EL expressions are of the type #{...}. These
> are only evaluated when needed (and otherwisestored as strings).

> To 3.3. Shame, I really would like to have a separate download for this.
> I'm neither using JBoss nor do I want to download glassfish just for
> these libs. So I hope for a better and brighter future and leave this
> comment in the article... ;-)
>

Wolfgang]]>Wolfgang Knauf2008-11-14T12:02:19-00:00Re: JSF with Eclipse - Tutorialhttps://www.eclipse.org/forums/index.php/mv/msg/151312/618733/#msg_618733
>
> To 1.5 I believe the following is true (I added it also to the article):
> JSP EL expressions are using the ${...} syntax. These EL expressions are
> immediately evaluated. JSF EL expressions are of the type #{...}. These
> are only evaluated when needed (and otherwisestored as strings).

> To 3.3. Shame, I really would like to have a separate download for this.
> I'm neither using JBoss nor do I want to download glassfish just for
> these libs. So I hope for a better and brighter future and leave this
> comment in the article... ;-)
>

Wolfgang]]>Wolfgang Knauf2008-11-14T12:02:19-00:00Re: JSF with Eclipse - Tutorialhttps://www.eclipse.org/forums/index.php/mv/msg/151312/476065/#msg_476065
> Hi Larx,
>
>>
>> To 1.5 I believe the following is true (I added it also to the
>> article): JSP EL expressions are using the ${...} syntax. These EL
>> expressions are immediately evaluated. JSF EL expressions are of the
>> type #{...}. These are only evaluated when needed (and otherwisestored
>> as strings).
>
> I found this article about the "Unified EL":
> http://java.sun.com/products/jsp/reference/techart/unifiedEL .html
> If I find the time to read it, it will hopefully remove the fog in my
> brain ;-). There seems to be more about it than just deferred evaluation.
>
Thanks. I'll include this in the references of the articles.
>
>> To 3.3. Shame, I really would like to have a separate download for
>> this. I'm neither using JBoss nor do I want to download glassfish just
>> for these libs. So I hope for a better and brighter future and leave
>> this comment in the article... ;-)
>>
>
> Here is a direct download link:
> https://javaserverfaces.dev.java.net/servlets/ProjectDocumen tList?folderID=5220&expandFolder=5220&folderID=8467
>
Thanks.
>
> Best regards
>
> Wolfgang
>

--
Lars Vogelhttp://www.vogella.de/eclipse.html - Tutorials about Eclipse http://www.vogella.de/articles/RichClientPlatform/article.ht ml - Eclipse
RCP Tutorial]]>Lars Vogel Unavailable until 15 August 20162008-11-14T19:25:06-00:00Re: JSF with Eclipse - Tutorialhttps://www.eclipse.org/forums/index.php/mv/msg/151312/618734/#msg_618734
> Hi Larx,
>
>>
>> To 1.5 I believe the following is true (I added it also to the
>> article): JSP EL expressions are using the ${...} syntax. These EL
>> expressions are immediately evaluated. JSF EL expressions are of the
>> type #{...}. These are only evaluated when needed (and otherwisestored
>> as strings).
>
> I found this article about the "Unified EL":
> http://java.sun.com/products/jsp/reference/techart/unifiedEL .html
> If I find the time to read it, it will hopefully remove the fog in my
> brain ;-). There seems to be more about it than just deferred evaluation.
>
Thanks. I'll include this in the references of the articles.
>
>> To 3.3. Shame, I really would like to have a separate download for
>> this. I'm neither using JBoss nor do I want to download glassfish just
>> for these libs. So I hope for a better and brighter future and leave
>> this comment in the article... ;-)
>>
>
> Here is a direct download link:
> https://javaserverfaces.dev.java.net/servlets/ProjectDocumen tList?folderID=5220&expandFolder=5220&folderID=8467
>
Thanks.
>
> Best regards
>
> Wolfgang
>

This looks really good! One thing you will be interested to know is that
starting in Galileo, the current JSF library concept is going to be
replaced by a pure classpath container concept. This solve some
outstanding bugs like ones related to broken source attachments.

I'll see if we can link this from the JSF tools project page. It is
definitely more up to date than the current tutorial.

This looks really good! One thing you will be interested to know is that
starting in Galileo, the current JSF library concept is going to be
replaced by a pure classpath container concept. This solve some
outstanding bugs like ones related to broken source attachments.

I'll see if we can link this from the JSF tools project page. It is
definitely more up to date than the current tutorial.

--Cam]]>Cameron Bateman2008-11-14T22:15:50-00:00Re: JSF with Eclipse - Tutorialhttps://www.eclipse.org/forums/index.php/mv/msg/151312/476108/#msg_476108
> http://java.sun.com/products/jsp/reference/techart/unifiedEL .html
> If I find the time to read it, it will hopefully remove the fog in my
> There seems to be more about it than just deferred evaluation.

In JSP 2.0 and before the main difference is, as you say, early vs.
late-bound compilation. ${} is resolved when the JSP page is compiled
into Java. #{} is not resolved until the compiled Java for a JSP is
executed.

So the expression: bean.foo

When it's in ${bean.foo}, the variable 'bean' must be defined when the JSP
page is compiled. You can think of this as similar to variables in Java.

When it's in #{bean.foo}, the variable bean need not be defined until
runtime. That's why it is used in JSF, since JSF injects things into the
runtime that JSP doesn't know about at compile time, like managed beans.

In JSP 2.1 (Faces 1.2), Unified EL created a separate standard for EL. In
the new standard, the meaning of $ vs. # is left to the implementer.
However, I believe in the JSP context the meaning is the same. On the
other hand, in something like Facelets all EL is "late-bound" regardless
of $ or #.

--Cam]]>Cameron Bateman2008-11-14T22:23:52-00:00Re: JSF with Eclipse - Tutorialhttps://www.eclipse.org/forums/index.php/mv/msg/151312/618736/#msg_618736
> http://java.sun.com/products/jsp/reference/techart/unifiedEL .html
> If I find the time to read it, it will hopefully remove the fog in my
> There seems to be more about it than just deferred evaluation.

In JSP 2.0 and before the main difference is, as you say, early vs.
late-bound compilation. ${} is resolved when the JSP page is compiled
into Java. #{} is not resolved until the compiled Java for a JSP is
executed.

So the expression: bean.foo

When it's in ${bean.foo}, the variable 'bean' must be defined when the JSP
page is compiled. You can think of this as similar to variables in Java.

When it's in #{bean.foo}, the variable bean need not be defined until
runtime. That's why it is used in JSF, since JSF injects things into the
runtime that JSP doesn't know about at compile time, like managed beans.

In JSP 2.1 (Faces 1.2), Unified EL created a separate standard for EL. In
the new standard, the meaning of $ vs. # is left to the implementer.
However, I believe in the JSP context the meaning is the same. On the
other hand, in something like Facelets all EL is "late-bound" regardless
of $ or #.

One thing you will be interested to know is
> that starting in Galileo, the current JSF library concept is going to be
> replaced by a pure classpath container concept. This solve some
> outstanding bugs like ones related to broken source attachments.

One thing you will be interested to know is
> that starting in Galileo, the current JSF library concept is going to be
> replaced by a pure classpath container concept. This solve some
> outstanding bugs like ones related to broken source attachments.