On 9/8/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
>
> 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.).
I'd like to tackle both of these with a custom JSF 1.2 lifecycle,
at which point, yes, we'd need to add some extra parameters.
PS - Out of curiosity, why was it coded as
> "TrPage.getInstance().sendPartialFormPost" instead of
> "TrPage.sendPartialFormPost" (JavaScript singletons don't normally
> need an instance)?
A good point - my brain's coded to think of Java coding styles.
I don't see any reason to require the getInstance() here,
which makes this call more cumbersome than it needs to be.
-- Adam
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
> > >
> >
>
