In theory, the table could detect that it contains no EditableValueHolders,
no ShowDetails, and no ActionSource components, and decline to run decode(),
etc. - but that'd break any third-party components that wanted to go into
the table, had events, and weren't one of these known types.
-- Adam
On 9/6/07, Vadim Dmitriev <[EMAIL PROTECTED]> wrote:
>
> Hi, Renzo.
> I don't think any component would do such a thing internally. After all,
> component just evaluate EL and can't figure out, when it is undesired.
> As a solution I can recommend you to use
> "FacesContext.getCurrentInstance().getRenderResponse()" to detect, when
> getter is called during renderResponse phase:
>
> public Object getSomeVal()
> {
> if( _someField != null &&
> FacesContext.getCurrentInstance().getRenderResponse() )
> {
> _someField = getDataFromSlowExternalSource();
> }
> return _someField;
> }
>
> In the following code snippet, request to some external data source will
> be issued only once in the renderResponse phase.
>
>
> Renzo Tomaselli wrote:
> > Hi all, in all cases where a readonly tr:table is involved - and
> > needed data are to be loaded from the business layer - then this
> > occurs twice.
> > Once during restore view (decode) and again during rendering (encode).
> > The first time is fairly useless for a readonly component, but the
> > overall doubling can be expensive while loading from a complex
> > business layer (e.i. a db).
> > AFAIK this is a JSF side-effect which should affect all components,
> > not a Trinidad issue. Trees are affected by the same problem as they
> > are typically readonly.
> > I just wonder if anybody else got the same conclusion and there is any
> > workaround.
> > The only one I can think about concerns detecting current phase and
> > skipping loading while restoring a view (e .g. returning null as a
> > value attribute, or at least an empty collection).
> > Any better suggestion ?
> >
>
