myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott O'Bryan" <darkar...@gmail.com>
Subject Re: [Trinidad] about using PPR everywhere on a panel-driven page
Date Wed, 09 Apr 2008 17:42:10 GMT
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
>


Mime
View raw message