Forum:

how to use ui:param in facelets

Ranch Hand

Posts: 55

posted 9 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

How are methods invoked on the `bird` parameter?

next.xhtml:

MyQueueBean:

package dur.facelets;
    
    import dur.database.Clients;
    import dur.database.ClientsQueryBean;
    import java.io.Serializable;
    import java.util.logging.Logger;
    import javax.ejb.EJB;
    import javax.inject.Named;
    import javax.ejb.Singleton;
    import javax.enterprise.context.ApplicationScoped;
    //import javax.inject.Singleton;
    
    @Named
    @ApplicationScoped
    @Singleton
    public class MyQueueBean implements Serializable {
    
        @EJB
        private ClientsQueryBean clientsQueryBean;
    
        private static final long serialVersionUID = 1L;
        private final Logger log = Logger.getLogger(MyQueueBean.class.getName());
        private int next = 1001;
    
        public MyQueueBean() {
        }
    
        public int getId() {
            return next;
        }
    
        public Clients getBird() {
            log.info("next\t" + next);
            Clients c = clientsQueryBean.getClientById(next);
            log.info(c.getName());
            next++;
            return c;
        }
    }

`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?

Tim Holloway

Saloon Keeper

Posts: 27478

195

I like...

posted 9 years ago

1
Number of slices to send:

Optional 'thank-you' note:

Send

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.

The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.

You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.

Piter Smith

Ranch Hand

Posts: 55

posted 9 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

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: 27478

195

I like...

posted 9 years ago

1
Number of slices to send:

Optional 'thank-you' note:

Send

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.

Just the other day, I was thinking ... about this tiny ad:

a bit of art, as a gift, that will fit in a stocking

https://gardener-gift.com