• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

how to use ui:param in facelets

 
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How are methods invoked on the `bird` parameter?


next.xhtml:



MyQueueBean:



`MyQueueBean` is intended to give out a bird once only, to exactly one end-user. Because it's application scoped, and not session scoped, getting attributes directly from the bean would give inconsistent results.


The birds application is from Facelets Essentials Guide to JavaServer Faces View Definition Framework:

http://www.apress.com/9781430210498




how is the variable passed to the file? Once it's passed, how is it referenced?

 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Annotating an application-scope bean as Singleton is redundant. By definition, there's only one instance of it per application.

The problem here is that although your property is only coded once and for a single user, its get method has side-effects.

JavaBeans in general and specifically JSF backing beans should not have side-effects in their get/set methods. A get method for a property might be invoked 5 or 6 times in the course of a single request/response cycle.

The way around this is to back up the get/set methods by an actual instance variable (property item) and have the get/set methods set or retrieve that variable's value.

For a read-only property such as this one, the backing property variable can be initialized either in a @Postconstruct method or by coding the "get" method to employ the variable as a cached item. That is, on the first call, retrieve the value from the database and set the variable, on subsequent calls just return the variable.
 
Piter Smith
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:Annotating an application-scope bean as Singleton is redundant. By definition, there's only one instance of it per application.

The problem here is that although your property is only coded once and for a single user, its get method has side-effects.

JavaBeans in general and specifically JSF backing beans should not have side-effects in their get/set methods. A get method for a property might be invoked 5 or 6 times in the course of a single request/response cycle.

The way around this is to back up the get/set methods by an actual instance variable (property item) and have the get/set methods set or retrieve that variable's value.

For a read-only property such as this one, the backing property variable can be initialized either in a @Postconstruct method or by coding the "get" method to employ the variable as a cached item. That is, on the first call, retrieve the value from the database and set the variable, on subsequent calls just return the variable.



by side effect, you mean mutate fields?
 
Tim Holloway
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A side-effect is the opposite of idempotent. An idempotent method returns the exact same value every time you invoke it. A method with side-effects might not.

By "every time", I mean in the absence of interim processes external to that method changing its backing value. Most notably the corresponding "put" method, but also things like action processors. The point is that other code might change the value, but the "get" code - and any code that the "get" code invokes - must not.

JavaBean and JSF "get" methods should not have side-effects, and for best performance, they should not indulge in resource-intensive operations. Since, as I said earlier, you don't know how many times a "get" method is going to be invoked on a given JSF request/response.
 
reply
    Bookmark Topic Watch Topic
  • New Topic