[Trinidad] how to PPR without trigger/target dependencies

[Renzo Tomaselli <re...@tecnotp.it>]

Hi, I'm trying to figure out how to PPR a target which has no static 
knowledge about its triggers, e.g. no partialTriggers are specified.
At the same time triggers (button and links) do not know about the 
target they will potentially PPR.
 From the dev-guide, I knew about the addPartialTarget(component) 
method, which seems nearly perfect for my purposes, but I have a couple 
of questions:

- assume I use a binding attribute to let a bean knowing about a 
component to PPR (e.i. tr:panelPopup or tr:panelGroupLayout), all I need 
is to invoke the method above when the binding method is called to give 
the component to a bean ? If not, what is the right context to call this 
method ?

- what about the partialSubmit attribute of potential triggers: must it 
be set on all candidates, in spite of missing any target ? Does it have 
any side effect if the target is missing ?

Comments are welcome, thanks.

-- Renzo

Re: [Trinidad] how to PPR without trigger/target dependencies

[Matthias Wessendorf <ma...@apache.org>]

On Jan 30, 2008 12:28 PM, Renzo Tomaselli <re...@tecnotp.it> wrote:
>
>  Matthias Wessendorf wrote:
>
>  - what about the partialSubmit attribute of potential triggers: must it
> be set on all candidates, in spite of missing any target ? Does it have
> any side effect if the target is missing ?
>
>  I think I don't understand.
> partialSubmit must be true to cause PPR.
> you can update ANY JSF UIComponent, with the addPartialTarget()
>
> if the the passed in comp is NULL, you get a NPE
>
> -M
>
>  To clarify: I need to decouple triggers from the result of their action.
> Thus in general, almost all my buttons/links should have partialSubmit=true,
> no matter if there is any target to PPR or not. I wasn't sure about this
> strategy having side effects or not, but it seems it doesn't harm.

yeah, as said partialSubmit=true means ppr;
the targets you can find on the fly

-M

>  Then PPR targets are provided either statically (by means of
> partialTriggers=...) or dynamically, through addPartialTarget().
>
>  -- Renzo
>
>
>



-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [Trinidad] how to PPR without trigger/target dependencies

[Matthias Wessendorf <ma...@apache.org>]

Hi,

On Jan 24, 2008 7:29 PM, Renzo Tomaselli <re...@tecnotp.it> wrote:
> Hi, I'm trying to figure out how to PPR a target which has no static
> knowledge about its triggers, e.g. no partialTriggers are specified.
> At the same time triggers (button and links) do not know about the
> target they will potentially PPR.
>  From the dev-guide, I knew about the addPartialTarget(component)
> method, which seems nearly perfect for my purposes, but I have a couple
> of questions:
>
> - assume I use a binding attribute to let a bean knowing about a
> component to PPR (e.i. tr:panelPopup or tr:panelGroupLayout), all I need
> is to invoke the method above when the binding method is called to give
> the component to a bean ? If not, what is the right context to call this
> method ?

this is what I do, for instance

    // find the UIComponent (or use binding)
    UIXTable table = (UIXTable)
FacesContext.getCurrentInstance().getViewRoot().findComponent("userTable");
// TODO: check if != null.....

    // set new "data" to the table
    table.setValue(this.users);

    // add the Table as a target;
    RequestContext afContext = RequestContext.getCurrentInstance();
    afContext.addPartialTarget(table);

>
> - what about the partialSubmit attribute of potential triggers: must it
> be set on all candidates, in spite of missing any target ? Does it have
> any side effect if the target is missing ?

I think I don't understand.
partialSubmit must be true to cause PPR.
you can update ANY JSF UIComponent, with the addPartialTarget()

if the the passed in comp is NULL, you get a NPE

-M

>
> Comments are welcome, thanks.
>
> -- Renzo
>
>
>



-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org