For "push triggering": what if we had a tag called pprTrigger,
that worked like:
<someone:commandLink ...>
<tr:pprTrigger event="action" partialTargets="list of ids"/>
</someone:commandLink>
<someone:inputText ...>
<tr:pprTrigger event="valueChange" partialTargets="list of ids"/>
</someone:inputText>
... where we use a dynamic proxy to register, in the first
case, an ActionListener, in the second case, a ValueChangeListener,
etc. The point here is that it's not at all tied even to Trinidad (though,
of course, whatever component it is must have been capable of
initiating a PPR request), though it's perfectly usable and reasonable
with Trinidad. It has a minor advantage over the partialTriggers attribute
in that it is specific to one event type, and will not fire on just
any event, which is an issue for complex components like table
that can fire multiple events.
Possibility #2, which is certainly simpler, is that we just add
a partialTargets attribute to Trinidad components. It has the
distinct disadvantage of being less fun to code up. :)
-- Adam
On 9/7/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> > - Trigger PPR from a parent when any child is a "PPR trigger"
> > General agreement that this is valuable.
> > - Trigger PPR when a message is queued for a component
> > I want to rely on DHTML for this instead of PPR, at least
> > for the Trinidad components.
> > - Push triggering instead of pull ("partialTargets" instead
> > of "partialTriggers")
> > Very interesting question, I'm toying with the idea
> > of a tag that can be attached for any event.
> > - Trigger PPR for a component on every request
> > I dislike this, as you probably have surmised. :)
> >
> > Have I omitted an item from this list?
> >
>
> For 663, and 664, this should be adequate, as long as DHTML is not the
> solution
>
