Win a copy of Java Concurrency Live Lessons this week in the Threads forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

how do you call Expression Language (EL) from xhtml?  RSS feed

 
Piter Smith
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I followed the example at:

http://www.apress.com/9781430210498


and created a birds project as so:





which runs fine on glassfish. Because glassfish bundles mojarra, there's no need to add anything to the projects classpath to run Unified Expression Language?


Why won't the birds speak? I tried this syntax:





which, I think is the correct syntax to print "hi fred" to the web page given this bean:






there must be some sort of configuration I'm overlooking.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Probably because it's expecting "fred" to be the name of a variable, not a string literal constant.

As a general rule, however, I do not recommend attempting to use EL as a programming language with parameterized function calls and the like, however. EL's primary purpose in JSF is to define references to backing bean properties and action methods, which is why the "#" is used (read/write) instead of the older "$" (read-only). Among other things. Also complex EL is a royal pain to debug.

UEL support is not part of JSF itself. It's a general JEE functionality and is integral to most modern servers, including Tomcat 5 and later.
 
Piter Smith
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:Probably because it's expecting "fred" to be the name of a variable, not a string literal constant.

As a general rule, however, I do not recommend attempting to use EL as a programming language with parameterized function calls and the like, however. EL's primary purpose in JSF is to define references to backing bean properties and action methods, which is why the "#" is used (read/write) instead of the older "$" (read-only). Among other things. Also complex EL is a royal pain to debug.

UEL support is not part of JSF itself. It's a general JEE functionality and is integral to most modern servers, including Tomcat 5 and later.


I'm using glassfish, so I'm ok with UEL being part of JEE functionality.

I have no idea what you mean by references to backing bean properties. Can you make that more concrete? That being said, it does give me something to google. In terms of getting output for this web app, I got something.





with the xhtml client:



and the bean as:




so that it's now a managed bean. However, that's deprecated, or will be, as I understand it. Not sure why it has to be a managed bean...?
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm probably going to miss something, since when a post is taller than my screen, I lose track of details. But here's some information that should help:

UEL is the same in both Tomcat and Glassfish, so EL coding doesn't change and you don't have to add EL support jars on either platform.

What I meant was that to work "properly", your EL expression should have looked more like this:



Although that's not legal XML

In reality, it's much simpler to get outputText for a string literal:



Or, for cases where the name is a backing bean property:



Backing beans are POJOs (JavaBeans) and the same terminology and conventions apply to them as apply to any other JavaBean. Properties are value holders and are accessed via get/set methods. Backing beans of course may have action methods and listener methods as well. That, however, doesn't make them Controllers in Model/View/Controller parlance, since a Controller transfers values between Model and View and those methods don't do that, JSF itself does.

A Managed Bean is simply a Backing Bean which can be automatically instantiated by JSF using its no-argument constructor. Any time you reference a Backing Bean that doesn't already exist, if it's defined as a Managed Bean, JSF will automatically construct it and inject any Managed Property values. This is a hallmark of the Inversion of Control (IoC) paradigm. The Managed Bean capability allows on-demand construction instead of making you have to explicitly code logic to create backing beans and store them in an appropriate context (request, View, Session, or Application).

The Managed Bean functionality is not likely to go away anytime soon. There is a general-purpose JSR that defines a more generalized version of this functionality, named CDI, but the ability to dynamically construct and initialize beans remains and only the annotations change. The new system is designed to make beans more portable/reusable and to add some additional functionality such as is offered by the Spring Framework, for example. So far I've avoided it myself, since you have to have a certain minimum JEE version support in your server and - more importantly - I found CDI both less capable than Spring and unwilling to allow a clean migration path for my existing Spring code.
 
Piter Smith
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you.

I'm not convinced that CDI is as bad as you paint it, but I appreciate your perspective and knowledge.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!