Hi Mario,
Mario Ivankovits wrote:
Mario Ivankovits wrote:
Unhappily this doesnt work as it seems the model update is AFTER the
fireing of the valueChangeListeners.
Thus my change will be overwritten by the model update.
Is there a way around it?
Well, I found this is the case.
Workaround is to update the value through the component binding.
But I think this is VERY bad.
Could it be somehow possible to have a valueChange method and also
associate a phase to it?
Something like
<f:valueChangeListener type="#{myBean.myMethod}"
phase="UPDATE_MODEL_VALUES" />
maybe by implementing a tomahawk extension?
The problem is that the f:valueChangeListener is really meant to be a
kind of *validator* rather than a model callback.
Perhaps you could try this?
public class MyBean {
public void myMethod(ValueChangeEvent ev) {
// requeue for processing after update model
MyEvent myEvent = new MyEvent(ev);
ev.getSource().queueEvent(myEvent);
}
}
It looks like the custom MyEvent class would need to override a number
of the FacesListener methods, eg isAppropriateListener.
This does seem to me to be a reasonable feature for tomahawk, perhaps
called t:valueChangeNotifier or as you say a phase attribute on a
t:valueChangeListener. Having a phase is a little odd, though, as the
ValueChangeListener declares that it throws AbortProcessingException (ie
can report a validation failure) but this has no meaning after the model
update phase.
I also have code that needs to handle value-change stuff at the model
level: I must get a list of all changed rows in a table which contains
input fields. Fortunately in my case I can do the necessary processing
(adding rows to a set) during the validation phase, but I imagine that
needing to know about changes to the model after model update isn't unusual.
Cheers,
Simon
