If #1 was decided on, it would be good to have clear documentation on
the how to initiate the submit from one of those components as well.
TrPage.getInstance().sendPartialFormPost may be enough, but maybe
additional "standard" form parameters could be supported in that
method call (like, (1) is supporting the ability to skip the update
phase a good idea?, (2) ability to only send the value from this
component -- JavaScript initiated partial decode like the subform
component does, etc.).
-Andrew
PS - Out of curiosity, why was it coded as
"TrPage.getInstance().sendPartialFormPost" instead of
"TrPage.sendPartialFormPost" (JavaScript singletons don't normally
need an instance)?
On 9/8/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> 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
> >
>