myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Robinson" <>
Subject Re: [Trinidad] ppr: partialTriggers doesn't work if there are validation messages?
Date Wed, 29 Aug 2007 16:30:54 GMT
I know this would be a major architectural change, but what if
components queued a partial trigger event in each of the listeners?
That way each listener would have the choice on the phase ID of the
event and the ability to act on it if desired.

Pseudo code using UIXCommand (component using ActionEvent as the
trigger) as an example:

  if event is an ActionEvent:
    loop through all components listening to this one
      queue new PartialTriggerEvent
    end loop
  end if

The event could look something like:

public class PartialTriggerEvent extends FacesEvent {
  private FacesEvent cause;
  public PartialTriggerEvent(UIComponent component, FacesEvent cause) {
    this.cause = cause;
  ... etc.

This could be in addition to the current code as not to break backward

Then some additional attribute could be used on components that
implement partialTriggers functionality like "partialTriggerPhase"
defaulting to null.

if not null, the component in the queueEvent method could set the
phase ID of the event. Then the component can add itself as a
partialTarget during the broadcasting of that event.

I know I am proposing a very large change, but it would provide a lot
more flexibility at the listener end of partial triggering to control
when a component should be re-rendered.

Just something to chew on

If no one likes this idea, another idea is to have UIXEditableValue
execute trigger logic in the validate function if the component is not
valid. Then conversion/validation/message-dependent components could
partially trigger off of the editable component instead of the
UIXCommand component.


On 8/29/07, Andrew Robinson <> wrote:
> Yes, I am just looking to be able to re-render items to reflect
> server-side messages. This could be actual message and label
> components, or other components (like for example, setting the style
> class of an input text that has a message). So it really should not be
> only message components, but all components should have the ability to
> re-render if there are messages.
> I am not using client side validation (I have it turned off) and am
> planning on using the Hibernate validation framework with the Seam
> validate and validateAll tags. I am doing this so that I can
> centralize the validation of a model class to one location (so if 5
> views all reference the same class, I only need to write the
> validation code once).
> Thank you,
> Andrew
> On 8/29/07, Adam Winer <> wrote:
> > On 8/28/07, Adam Winer <> wrote:
> > > If I understand it correctly, your concern here is basically that
> > > we're not displaying validation errors correctly after an
> > > event is submitted?
> > >
> > > (We do, or at least should, re-display tr:messages during PPR, but
> > > not the messages next to the individual components.  If your
> > > page doesn't have a tr:messages on it, I'd recommend adding
> > > one.)
> > >
> > > If that's the issue, then we should tackle that, which is a
> > > clear functionality gap that doesn't require architectural
> > > changes, and shouldn't require any end developer code -
> > > those messages should just get displayed on the client.
> >
> > ... and so there's no confusion, I mean that those
> > *server-side* messages should get just displayed on
> > the client.  As long as we have inline client-side validation
> > in general, our Javascript is easily smart enough to
> > deal with inserting error messages on the client,
> > so we'd just need to update our rendering code to include
> > a Javascript payload of all the per-component FacesMessages.
> >
> > -- Adam

View raw message