Saving model state between requests

["Meyer, Stefan" <S....@S2neueinformatik.de>]

I have a pretty common problem with tables. I put a button in a table
column. A "setActionListener" makes sure that the called action can
access the id of the entity the column represents and the action can
operate on that entity. The CollectionModel needs to be present before
"model update" so that the actionListener can retrieve the data from it.
In tomahawk there is the attribute "preserveDataModel" in order to
persist the datamodel from request to request. Another option is the use
of "saveState" component. I understand that loading the data freshly has
advantages but in my case  it might be pretty slow (Lucene query). Is
there a way to do preserve the datamodel in trinidad?



  

Re: Re: no dynamic columns for tr:table

[Adam Winer <aw...@gmail.com>]

The major problem is that prior to JSF 1.2, tr:forEach must produce
the same number of columns on every execution.

-- Adam


On 12/14/06, Renzo Tomaselli <re...@tecnotp.it> wrote:
>
>  Adam, can you speculate a bit further on "For cases where that just doesn't
> work"  please ?
>  I mean, shouldn't be this solution a bit more deterministic ? I just read
> about a practical constraint on EL generated variables, which cannot be
> used. Is there anything else preventing tr:forEach usage for columns ?
>  Thanks -- Renzo
>
>
>  Adam Winer wrote:
> You can often use tr:forEach to iterate over the columns.
>  (Or c:forEach, since you're using Facelets.)
>  For cases where that just doesn't work, you can
>  manually populate columns from a backing bean, though
>  that's certainly awkwards.
>
>  As you guessed, you can't mix up tr:table with t:columns.
>
>  -- Adam
>
>
>  On 12/14/06, Renzo Tomaselli <re...@tecnotp.it> wrote:
>
> Hi, for the purpose of replacing existing facelets using Tomahawk
>  components through Trinidad ones, I noticed that nothing like t:columns
>  seems to exist in Trinidad. Only a single tr:column is documented,
>  leading to static tables only.
>  A multiple column component is very useful for rendering runtime-defined
>  (e.g. non static) column sets.
>  Is there another component covering this role or is this feature
>  definitely missing ?
>  Furthermore, I guess that t:dataTable/t:columns/t:column are closely
>  connected, the same also for tr:table/tr:column. Or can I mixup tr:table
>  with t:columns ?
>  Thanks -- Renzo
>
>
>
>
>

Re: no dynamic columns for tr:table

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

Adam, can you speculate a bit further on "For cases where that just doesn't
work"  please ?  
I mean, shouldn't be this solution a bit more deterministic ? I just read
about a practical constraint on EL generated variables, which cannot be used.
Is there anything else preventing tr:forEach usage for columns ?  
Thanks -- Renzo  
  
Adam Winer wrote:

> You can often use tr:forEach to iterate over the columns.  
>  (Or c:forEach, since you're using Facelets.)  
>  For cases where that just doesn't work, you can  
>  manually populate columns from a backing bean, though  
>  that's certainly awkwards.  
>  
>  As you guessed, you can't mix up tr:table with t:columns.  
>  
>  \-- Adam  
>  
>  
>  On 12/14/06, Renzo Tomaselli
> [<re...@tecnotp.it>](mailto:renzo.tomaselli@tecnotp.it) wrote:  
>
>

>> Hi, for the purpose of replacing existing facelets using Tomahawk  
>  components through Trinidad ones, I noticed that nothing like t:columns  
>  seems to exist in Trinidad. Only a single tr:column is documented,  
>  leading to static tables only.  
>  A multiple column component is very useful for rendering runtime-defined  
>  (e.g. non static) column sets.  
>  Is there another component covering this role or is this feature  
>  definitely missing ?  
>  Furthermore, I guess that t:dataTable/t:columns/t:column are closely  
>  connected, the same also for tr:table/tr:column. Or can I mixup tr:table  
>  with t:columns ?  
>  Thanks -- Renzo  
>  
>  
>
>
>  
>  
>

Re: no dynamic columns for tr:table

[Adam Winer <aw...@gmail.com>]

You can often use tr:forEach to iterate over the columns.
(Or c:forEach, since you're using Facelets.)
For cases where that just doesn't work, you can
manually populate columns from a backing bean, though
that's certainly awkwards.

As you guessed, you can't mix up tr:table with t:columns.

-- Adam


On 12/14/06, Renzo Tomaselli <re...@tecnotp.it> wrote:
> Hi, for the purpose of replacing existing facelets using Tomahawk
> components through Trinidad ones, I noticed that nothing like t:columns
> seems to exist in Trinidad. Only a single tr:column is documented,
> leading to static tables only.
> A multiple column component is very useful for rendering runtime-defined
> (e.g. non static) column sets.
> Is there another component covering this role or is this feature
> definitely missing ?
> Furthermore, I guess that t:dataTable/t:columns/t:column are closely
> connected, the same also for tr:table/tr:column. Or can I mixup tr:table
> with t:columns ?
> Thanks -- Renzo
>
>

no dynamic columns for tr:table

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

Hi, for the purpose of replacing existing facelets using Tomahawk 
components through Trinidad ones, I noticed that nothing like t:columns 
seems to exist in Trinidad. Only a single tr:column is documented, 
leading to static tables only.
A multiple column component is very useful for rendering runtime-defined 
(e.g. non static) column sets.
Is there another component covering this role or is this feature 
definitely missing ?
Furthermore, I guess that t:dataTable/t:columns/t:column are closely 
connected, the same also for tr:table/tr:column. Or can I mixup tr:table 
with t:columns ?
Thanks -- Renzo

Re: Re: Saving model state between requests

[Chris Lowe <ch...@gmail.com>]

Apologies, you're right Adam - no mention of Facelets.



On 14/12/06, Adam Winer <aw...@gmail.com> wrote:
>
> Well, the discussion linked to there points out that
> preserveDataModel causes problems - and is unnecessary
> to boot - if it's already conversation-scoped.  Don't see
> anything there that suggests there are problems
> with preserveDataModel and Facelets.  But I would certainly
> agree that using a scope like Seam conversations is a
> cleaner approach than pushing the onus on one
> particular component.
>
> If just sticking with Trinidad, you could use pageFlowScope,
> which is an improvement over session for most scenarios.
>
> -- Adam
>
>
>
> On 12/14/06, Chris Lowe <ch...@gmail.com> wrote:
> > I don't know of any ADF/Trinidad alternative to preserveDataModel, but
> then
> > again I am quite new to this component set.
> >
> > I've been using Trinidad along with Facelets and JBoss Seam. There have
> been
> > some discussions around Tomahawk and in particular the
> "preserveDataModel"
> > flag not playing well with either of these technologies:
> >
> > http://www.jboss.com/index.html?module=bb&op=viewtopic&t=70250
> >
> > Long story short - best not to use it!
> >
> > A general JSF solution to this would be to store your data model (or
> > whatever collection that drives the datamodel) in a session bean which
> will
> > serve as a data cache between requests. In the restore view phase - use
> the
> > cached version; in prerender phase refresh the cached list.  It ain't
> pretty
> > - but it worked for me.
> >
> > BTW Seam offers some neat solutions to this problem ranging from a
> version
> > of the above JSF method but needing only a couple of annotations through
> to
> > the caching of already rendered page fragments.
> >
> > Regards,
> >
> > Chris.
> >
> >
> >
> >
> >
> >
> > On 13/12/06, Meyer, Stefan <S....@s2neueinformatik.de> wrote:
> > >
> > > I have a pretty common problem with tables. I put a button in a table
> > > column. A "setActionListener" makes sure that the called action can
> > > access the id of the entity the column represents and the action can
> > > operate on that entity. The CollectionModel needs to be present before
> > > "model update" so that the actionListener can retrieve the data from
> it.
> > > In tomahawk there is the attribute "preserveDataModel" in order to
> > > persist the datamodel from request to request. Another option is the
> use
> > > of "saveState" component. I understand that loading the data freshly
> has
> > > advantages but in my case  it might be pretty slow (Lucene query). Is
> > > there a way to do preserve the datamodel in trinidad?
> > >
> > >
> > >
> > >
> > >
> >
> >
>

Re: Re: Saving model state between requests

[Adam Winer <aw...@gmail.com>]

Well, the discussion linked to there points out that
preserveDataModel causes problems - and is unnecessary
to boot - if it's already conversation-scoped.  Don't see
anything there that suggests there are problems
with preserveDataModel and Facelets.  But I would certainly
agree that using a scope like Seam conversations is a
cleaner approach than pushing the onus on one
particular component.

If just sticking with Trinidad, you could use pageFlowScope,
which is an improvement over session for most scenarios.

-- Adam



On 12/14/06, Chris Lowe <ch...@gmail.com> wrote:
> I don't know of any ADF/Trinidad alternative to preserveDataModel, but then
> again I am quite new to this component set.
>
> I've been using Trinidad along with Facelets and JBoss Seam. There have been
> some discussions around Tomahawk and in particular the "preserveDataModel"
> flag not playing well with either of these technologies:
>
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=70250
>
> Long story short - best not to use it!
>
> A general JSF solution to this would be to store your data model (or
> whatever collection that drives the datamodel) in a session bean which will
> serve as a data cache between requests. In the restore view phase - use the
> cached version; in prerender phase refresh the cached list.  It ain't pretty
> - but it worked for me.
>
> BTW Seam offers some neat solutions to this problem ranging from a version
> of the above JSF method but needing only a couple of annotations through to
> the caching of already rendered page fragments.
>
> Regards,
>
> Chris.
>
>
>
>
>
>
> On 13/12/06, Meyer, Stefan <S....@s2neueinformatik.de> wrote:
> >
> > I have a pretty common problem with tables. I put a button in a table
> > column. A "setActionListener" makes sure that the called action can
> > access the id of the entity the column represents and the action can
> > operate on that entity. The CollectionModel needs to be present before
> > "model update" so that the actionListener can retrieve the data from it.
> > In tomahawk there is the attribute "preserveDataModel" in order to
> > persist the datamodel from request to request. Another option is the use
> > of "saveState" component. I understand that loading the data freshly has
> > advantages but in my case  it might be pretty slow (Lucene query). Is
> > there a way to do preserve the datamodel in trinidad?
> >
> >
> >
> >
> >
>
>

Re: Saving model state between requests

[Chris Lowe <ch...@gmail.com>]

I don't know of any ADF/Trinidad alternative to preserveDataModel, but then
again I am quite new to this component set.

I've been using Trinidad along with Facelets and JBoss Seam. There have been
some discussions around Tomahawk and in particular the "preserveDataModel"
flag not playing well with either of these technologies:

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=70250

Long story short - best not to use it!

A general JSF solution to this would be to store your data model (or
whatever collection that drives the datamodel) in a session bean which will
serve as a data cache between requests. In the restore view phase - use the
cached version; in prerender phase refresh the cached list.  It ain't pretty
- but it worked for me.

BTW Seam offers some neat solutions to this problem ranging from a version
of the above JSF method but needing only a couple of annotations through to
the caching of already rendered page fragments.

Regards,

Chris.






On 13/12/06, Meyer, Stefan <S....@s2neueinformatik.de> wrote:
>
> I have a pretty common problem with tables. I put a button in a table
> column. A "setActionListener" makes sure that the called action can
> access the id of the entity the column represents and the action can
> operate on that entity. The CollectionModel needs to be present before
> "model update" so that the actionListener can retrieve the data from it.
> In tomahawk there is the attribute "preserveDataModel" in order to
> persist the datamodel from request to request. Another option is the use
> of "saveState" component. I understand that loading the data freshly has
> advantages but in my case  it might be pretty slow (Lucene query). Is
> there a way to do preserve the datamodel in trinidad?
>
>
>
>
>