 |
Using JSP Immediate Expressions to access JSF Data
Posted by edburns on March 15, 2006 at 10:48 AM | Comments (7)
Here is an ultra-quick blog entry sharing something in JSF 1.2 about
which I'm not sure many people are aware. Thanks to the unified EL, it
is possible to refer to JSF managed beans and other JSF concepts using
plain old JSP expressions in the page. For example, let's say you have
a JSF app that is a bookstore. In the app is a managed bean that is a
Map where the keys are ISBN numbers and the values are Book JavaBeans
that have properties like author, title, ISBN, etc.
In JSF 1.1, to display any information from the book Map, you had to
use JSF components. In JSF 1.2, you can use plain old JSP ${}
expressions to access this data, like this:
The title is ${books["0072262400"].title}.
Even though books is a managed bean, you can still
access it without JSF.
Keep in mind that you can also access all the implicit objects,
including JSF ones, in this manner. For example, if you wanted to use
EL to get the locale of the current view, you could say:
${view.locale}
As a final example, if you wanted to get the remote user name of the
current user using standard Servlet authentication APIs you could
say:
${facesContext.externalContext.remoteUser}
Basically anything that conforms to JavaBeans naming conventions and
is accessible from the FacesContext or
UIViewRoot can be reached via the EL in this way.
Technorati Tags: edburns
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
actually, to clarify this, you can't use contextual EL in this manner-- like inlining ${employee.name} within a dataTable. This can be done with a simple fix to JSF's implementation and setting the 'deferredSyntaxAllowedAsLiteral' page property in JSP 2.1 to get 'render-time' evaluation of inlined text w/ #{...} vs. build-time evaluation with the common ${...} syntax.
Posted by: jhook on March 15, 2006 at 01:05 PM
-
hey,Edburns,when do JSF 1.2 release?I have waited it for two years.
Actually,I think hybrid Programming(EL\JSTL\JSF) is very important in JSF 1.2.But must waiting for Glassfish or JBoss seam,still waiting...
Posted by: forsoft on March 16, 2006 at 06:39 AM
-
JSF 1.2 will have its final release this Spring. As you know, however, it is currently available in the Java EE SDK at http://java.sun.com/javaee/downloads/
Ed
Posted by: edburns on March 16, 2006 at 11:22 AM
-
JH> actually, to clarify this, you can't use contextual EL in this
JH> manner-- like inlining ${employee.name} within a dataTable. This
JH> can be done with a simple fix to JSF's implementation and setting
JH> the 'deferredSyntaxAllowedAsLiteral' page property in JSP 2.1 to
JH> get 'render-time' evaluation of inlined text w/ #{...}
JH> vs. build-time evaluation with the common ${...} syntax.
Yes, I see, Jacob. I have simply inlining ${customer.name} into a
dataTable demo I have and found that it does not work in the data table
case. However, I do want to point out that one can use immediate
expressions to reference JSF managed beans in all other cases than the
data table case.
Ed - JSF co-spec lead
Posted by: edburns on March 31, 2006 at 05:29 AM
-
JH> actually, to clarify this, you can't use contextual EL in this
JH> manner-- like inlining ${employee.name} within a dataTable. This
JH> can be done with a simple fix to JSF's implementation and setting
JH> the 'deferredSyntaxAllowedAsLiteral' page property in JSP 2.1 to
JH> get 'render-time' evaluation of inlined text w/ #{...}
JH> vs. build-time evaluation with the common ${...} syntax.
Well, Jacob, I played around a bit with your suggestion and found
that the fix to the JSF impl isn't so simple. I gather you're
suggesting we special-case the ValueExpression callsites in the JSF tag
layer to check:
if isLiteral
then
See if the literal happens to be a real #{ } expression. If it does
create a real (non-literal) expression from it, the way we do
in jsf 1.1.
This approach has problems because the places where you'd have to do
this check are numerous. Furthermore, once you do the check you'd need
some way to have the #{employee.name} value actually get turned into a
real (non-literal) expression. I think we could do this
because of the content-interweaving solution where the template text
would be turned into a UIOutput. Therefore, we could modify the code
that turns the template text into a UIOutput to actually turn it into an
ValueExpression and set that as the value of the UIOutput. As a
performance optimization, we could have that code inspect the literal
text value to see if it contains any #{ characters and only then turn it
into an expression.
This is worth investigating further. I've created issue 164
in the jsf-api public issue tracker and attached my change-bundle so
far.
Ed (JSF co-spec-lead)
Posted by: edburns on March 31, 2006 at 06:30 AM
-
This is really great. I think Unified EL + content interweaving in JSF 1.2 bring a LOT of value a HTML and dynamic content generated by JSF artifacts are so easy to integrate in a JSF page. No more verbatim just plain HTML. Wonderful !!!
Currently we are using JSF 1.1 and to address this handicap of not being able to use JSF EL in template text we did this:
1. Created a TLD function that returns an Object and has a String argument
2. Function creates a ValueBinding out of the argument and ultimately evaluates the expression.
it looks something like
${e:jsfEL('#{MyBean.name}')}
and can be used anywhere in the page. The syntax is a bit long, but it solves the problem but with JSF 1.2 and JSP 2.1 goodies we can use this much more naturally.
Thank you,
Marius
Posted by: marius_danciu on August 12, 2007 at 04:26 AM
|
java.net RSS Feeds
