[Trinidad] about using PPR everywhere on a panel-driven page

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

Hi all, I'm working on an application which mimics the behavior of 
modern (non-web GUI) wizards.
Basically there is a single page containing side-by-side panels (like 
frames) plus a number of popup panels.
Users are allowed to move a panel between those tho sets, as well as to 
minimize, maximize, drag and resize panels.
Actual panel contents are runtime-defined after user actions on buttons 
and popup menus, thus there is a massive usage of Facelets composition 
components (but no templates) and ui:include. Heavy usage of js 
machinery is needed too.
Trinidad is very good for my purposes but - as a matter of efficiency - 
PPR should be used everywhere, so that single panels contents only 
should be refreshed upon any user action, not the entire page. Basically 
there is no reason to refresh the entire page, except for changing locale.
Here comes the point: this approach requires using partialSubmit="true" 
on *all* buttons/links, while addPartialTarget() defines later what to 
return as a PPR response.
I already use this way for panel refreshing in selected cases without 
problems but now I would generalize this approach.
But addPartialTarget() requires a component to be specified, and the 
only way I know of to get a component is through the binding attribute. 
This has some unpleasant side-effects with Facelets, and it cannot be 
used within iterating components (stamping) since inner components are 
defined at rendering time.
In general - it's from action processing (within beans) that I have to 
decide upon which component will be a partial target.
In many cases there is no need to return anything: e.i. while removing a 
panel, the DOM is updated by js and the concerned bean needs to know 
about the dropped panel. No PPR response is needed and the result is 
very fast.
Thanks for any comment,

-- Renzo

Re: [Trinidad] about using PPR everywhere on a panel-driven page

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

Thanks Scott. I presume you are referring to addPartialTargets (or 
findRelativeComponent) - which I didn't know about so far.

-- Renzo

Scott O'Bryan wrote:
> Renzo, just use the component's id (ie. in the "id" attribute).  
> Trinidad will correctly resolve the "scope" if you use it right.  
> There is some ":" mechanism that will even let you traverse naming 
> containers, but Andrew could probably explain that better.  :)  I'm 
> sure it's documented somewhere.
>
> Scott
>
> Renzo Tomaselli wrote:
>> Hi all, I'm working on an application which mimics the behavior of 
>> modern (non-web GUI) wizards.
>> Basically there is a single page containing side-by-side panels (like 
>> frames) plus a number of popup panels.
>> Users are allowed to move a panel between those tho sets, as well as 
>> to minimize, maximize, drag and resize panels.
>> Actual panel contents are runtime-defined after user actions on 
>> buttons and popup menus, thus there is a massive usage of Facelets 
>> composition components (but no templates) and ui:include. Heavy usage 
>> of js machinery is needed too.
>> Trinidad is very good for my purposes but - as a matter of efficiency 
>> - PPR should be used everywhere, so that single panels contents only 
>> should be refreshed upon any user action, not the entire page. 
>> Basically there is no reason to refresh the entire page, except for 
>> changing locale.
>> Here comes the point: this approach requires using 
>> partialSubmit="true" on *all* buttons/links, while addPartialTarget() 
>> defines later what to return as a PPR response.
>> I already use this way for panel refreshing in selected cases without 
>> problems but now I would generalize this approach.
>> But addPartialTarget() requires a component to be specified, and the 
>> only way I know of to get a component is through the binding 
>> attribute. This has some unpleasant side-effects with Facelets, and 
>> it cannot be used within iterating components (stamping) since inner 
>> components are defined at rendering time.
>> In general - it's from action processing (within beans) that I have 
>> to decide upon which component will be a partial target.
>> In many cases there is no need to return anything: e.i. while 
>> removing a panel, the DOM is updated by js and the concerned bean 
>> needs to know about the dropped panel. No PPR response is needed and 
>> the result is very fast.
>> Thanks for any comment,
>>
>> -- Renzo
>>
>
>

Re: [Trinidad] about using PPR everywhere on a panel-driven page

[Scott O'Bryan <da...@gmail.com>]

Renzo, just use the component's id (ie. in the "id" attribute).  
Trinidad will correctly resolve the "scope" if you use it right.  There 
is some ":" mechanism that will even let you traverse naming containers, 
but Andrew could probably explain that better.  :)  I'm sure it's 
documented somewhere.

Scott

Renzo Tomaselli wrote:
> Hi all, I'm working on an application which mimics the behavior of 
> modern (non-web GUI) wizards.
> Basically there is a single page containing side-by-side panels (like 
> frames) plus a number of popup panels.
> Users are allowed to move a panel between those tho sets, as well as 
> to minimize, maximize, drag and resize panels.
> Actual panel contents are runtime-defined after user actions on 
> buttons and popup menus, thus there is a massive usage of Facelets 
> composition components (but no templates) and ui:include. Heavy usage 
> of js machinery is needed too.
> Trinidad is very good for my purposes but - as a matter of efficiency 
> - PPR should be used everywhere, so that single panels contents only 
> should be refreshed upon any user action, not the entire page. 
> Basically there is no reason to refresh the entire page, except for 
> changing locale.
> Here comes the point: this approach requires using 
> partialSubmit="true" on *all* buttons/links, while addPartialTarget() 
> defines later what to return as a PPR response.
> I already use this way for panel refreshing in selected cases without 
> problems but now I would generalize this approach.
> But addPartialTarget() requires a component to be specified, and the 
> only way I know of to get a component is through the binding 
> attribute. This has some unpleasant side-effects with Facelets, and it 
> cannot be used within iterating components (stamping) since inner 
> components are defined at rendering time.
> In general - it's from action processing (within beans) that I have to 
> decide upon which component will be a partial target.
> In many cases there is no need to return anything: e.i. while removing 
> a panel, the DOM is updated by js and the concerned bean needs to know 
> about the dropped panel. No PPR response is needed and the result is 
> very fast.
> Thanks for any comment,
>
> -- Renzo
>