You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Simon Kulessa <ku...@flexsecure.de> on 2010/06/09 13:07:53 UTC
[Trinidad] concurrent access to a sortable table
Hello everyone,
I am developing a web application for my company based on JSF 1.2.14 and
Trinidad 1.2.13. In this application we have different views
that are displayed with the help of the <tr:table> tag.
We discovered recently that the default data model
does not support concurrent access to the data.
Source:
http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/model/CollectionModel.html
--
The only solution to this problem i have discovered so far, is that
we have to implement our own CollectionModel to support unique row keys.
Question 1: Is there really no other way to support concurrent access?
Question 2: Does a tutorial or a discription exist, how the framework
uses the CollectionModel? Or a tutorial for implementing your own
CollectionModel ?
--
I have tried to implement a class that extends the CollectionModel class
and implemented the necessary methods.
For example: I used the setWrappedData(Object o) method to save the data
as an attribute inside the CollectionModel and to generate an index to
map the uniqueKey to the specified row.
Request 3: It would be helpfull if someone can provide a sample for an
efficient implementation of a CollectionModel ?
--
To return the CollectionModel to the Framework I changed the return type
of the getData method (<tr:table values="someBean.data">) from the
previously used List<Data> to CollectionModel, which now wrapps the
List<Data>.
The bad thing is, that the framework calls this method three times
during the render phase. That means I currently need to create/convert
the CollectionModel and the index for the mapping three times.
Question 4: Is there a way to prevent this?
Maybe an additional check can be added to verify in which render state
the call is made?
--
Another problem is that our data table needs to support sorting.
The default CollectionModel does not support sorting and the
SortableCollectionMethod does not seem to be expandable
(since it uses Integer's as rowKeys).
The solution seems to override the "isSortable, getSortingCriteria,
setSortingCriteria" methods of the CollectionModel
and implement the sorting feature on your own.
Question 5: Again, is that really the way you have to do it?
Request 6: An efficient sample of an implementation would be nice.
--
Any help is appreciated.
If necessary I could provide my sample implementation.
Best regards,
Simon Kulessa.
--
Diplom Informatiker Simon Kulessa
FlexSecure GmbH
Industriestr. 12
D - 64297 Darmstadt
Tel: +49 (0) 6151 501 23-15
Fax: +49 (0) 6151 501 23-19
E-Mail:kulessa@flexsecure.de
Internet:www.flexsecure.de
Geschäftsführer:
Erwin Stallenberger, Markus Ruppert
Amtsgericht Darmstadt HRB 8036
Umsatzsteuernummer: DE 214745269
RE: [Trinidad] concurrent access to a sortable table
Posted by Mark Millman <ma...@mizar.com>.
Simon, I suppose we don't suffer quite the same issues because our table
classes are session scoped. We create the SortableModel in response to a
JPA queryResult and retain it until it is replaced, cleared, or the session
ends. We're using Eclipselink JPA beans and this provides the mechanism to
avoid redundancy of data, the lists (models) associated with each table all
reference the same bean but are independently sortable. The same bean might
be referenced in a hierarchy of parent-child tables.
We've built a relatively simple abstract table/collection class that manages
the behavior of JPA and Trinidad. Our experience has been that we're able
to support a lot of users within reasonable memory limits with reasonable
response.
Mark
-----Original Message-----
From: Simon Kulessa [mailto:kulessa@flexsecure.de]
Sent: Thursday, June 10, 2010 1:12 AM
To: MyFaces Discussion
Subject: Re: [Trinidad] concurrent access to a sortable table
Hello Mark,
thanks for your answer.
I think the code line you mentioned describes the default behaviour of
the framework. So the problem with the concurrent access would not be
solved, because the framework would still use the integer indices.
Best regards,
Simon Kulessa.
Am 10.06.2010 08:57, schrieb Mark Millman:
> I've done the following to create SortableModel from Lists
>
> model = (SortableModel)
>
org.apache.myfaces.trinidad.model.ModelUtils.toCollectionModel((Object)list)
> ;
>
> It's not elegant but it seems to work well enough.
>
> Mark
>
> -----Original Message-----
> From: Simon Kulessa [mailto:kulessa@flexsecure.de]
> Sent: Wednesday, June 09, 2010 4:08 AM
> To: users@myfaces.apache.org
> Subject: [Trinidad] concurrent access to a sortable table
>
> Hello everyone,
>
> I am developing a web application for my company based on JSF 1.2.14 and
> Trinidad 1.2.13. In this application we have different views
> that are displayed with the help of the<tr:table> tag.
>
> We discovered recently that the default data model
> does not support concurrent access to the data.
>
> Source:
>
http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/t
> rinidad/model/CollectionModel.html
>
> --
> The only solution to this problem i have discovered so far, is that
> we have to implement our own CollectionModel to support unique row keys.
>
> Question 1: Is there really no other way to support concurrent access?
> Question 2: Does a tutorial or a discription exist, how the framework
> uses the CollectionModel? Or a tutorial for implementing your own
> CollectionModel ?
>
> --
> I have tried to implement a class that extends the CollectionModel class
> and implemented the necessary methods.
>
> For example: I used the setWrappedData(Object o) method to save the data
> as an attribute inside the CollectionModel and to generate an index to
> map the uniqueKey to the specified row.
>
> Request 3: It would be helpfull if someone can provide a sample for an
> efficient implementation of a CollectionModel ?
>
> --
> To return the CollectionModel to the Framework I changed the return type
> of the getData method (<tr:table values="someBean.data">) from the
> previously used List<Data> to CollectionModel, which now wrapps the
> List<Data>.
>
> The bad thing is, that the framework calls this method three times
> during the render phase. That means I currently need to create/convert
> the CollectionModel and the index for the mapping three times.
>
> Question 4: Is there a way to prevent this?
> Maybe an additional check can be added to verify in which render state
> the call is made?
>
> --
> Another problem is that our data table needs to support sorting.
> The default CollectionModel does not support sorting and the
> SortableCollectionMethod does not seem to be expandable
> (since it uses Integer's as rowKeys).
>
> The solution seems to override the "isSortable, getSortingCriteria,
> setSortingCriteria" methods of the CollectionModel
> and implement the sorting feature on your own.
>
> Question 5: Again, is that really the way you have to do it?
> Request 6: An efficient sample of an implementation would be nice.
>
> --
>
> Any help is appreciated.
> If necessary I could provide my sample implementation.
>
>
> Best regards,
> Simon Kulessa.
--
Diplom Informatiker Simon Kulessa
FlexSecure GmbH
Industriestr. 12
D - 64297 Darmstadt
Tel: +49 (0) 6151 501 23-15
Fax: +49 (0) 6151 501 23-19
E-Mail:kulessa@flexsecure.de
Internet:www.flexsecure.de
Geschäftsführer:
Erwin Stallenberger, Markus Ruppert
Amtsgericht Darmstadt HRB 8036
Umsatzsteuernummer: DE 214745269
Re: [Trinidad] concurrent access to a sortable table
Posted by Simon Kulessa <ku...@flexsecure.de>.
Hello Mark,
thanks for your answer.
I think the code line you mentioned describes the default behaviour of
the framework. So the problem with the concurrent access would not be
solved, because the framework would still use the integer indices.
Best regards,
Simon Kulessa.
Am 10.06.2010 08:57, schrieb Mark Millman:
> I've done the following to create SortableModel from Lists
>
> model = (SortableModel)
> org.apache.myfaces.trinidad.model.ModelUtils.toCollectionModel((Object)list)
> ;
>
> It's not elegant but it seems to work well enough.
>
> Mark
>
> -----Original Message-----
> From: Simon Kulessa [mailto:kulessa@flexsecure.de]
> Sent: Wednesday, June 09, 2010 4:08 AM
> To: users@myfaces.apache.org
> Subject: [Trinidad] concurrent access to a sortable table
>
> Hello everyone,
>
> I am developing a web application for my company based on JSF 1.2.14 and
> Trinidad 1.2.13. In this application we have different views
> that are displayed with the help of the<tr:table> tag.
>
> We discovered recently that the default data model
> does not support concurrent access to the data.
>
> Source:
> http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/t
> rinidad/model/CollectionModel.html
>
> --
> The only solution to this problem i have discovered so far, is that
> we have to implement our own CollectionModel to support unique row keys.
>
> Question 1: Is there really no other way to support concurrent access?
> Question 2: Does a tutorial or a discription exist, how the framework
> uses the CollectionModel? Or a tutorial for implementing your own
> CollectionModel ?
>
> --
> I have tried to implement a class that extends the CollectionModel class
> and implemented the necessary methods.
>
> For example: I used the setWrappedData(Object o) method to save the data
> as an attribute inside the CollectionModel and to generate an index to
> map the uniqueKey to the specified row.
>
> Request 3: It would be helpfull if someone can provide a sample for an
> efficient implementation of a CollectionModel ?
>
> --
> To return the CollectionModel to the Framework I changed the return type
> of the getData method (<tr:table values="someBean.data">) from the
> previously used List<Data> to CollectionModel, which now wrapps the
> List<Data>.
>
> The bad thing is, that the framework calls this method three times
> during the render phase. That means I currently need to create/convert
> the CollectionModel and the index for the mapping three times.
>
> Question 4: Is there a way to prevent this?
> Maybe an additional check can be added to verify in which render state
> the call is made?
>
> --
> Another problem is that our data table needs to support sorting.
> The default CollectionModel does not support sorting and the
> SortableCollectionMethod does not seem to be expandable
> (since it uses Integer's as rowKeys).
>
> The solution seems to override the "isSortable, getSortingCriteria,
> setSortingCriteria" methods of the CollectionModel
> and implement the sorting feature on your own.
>
> Question 5: Again, is that really the way you have to do it?
> Request 6: An efficient sample of an implementation would be nice.
>
> --
>
> Any help is appreciated.
> If necessary I could provide my sample implementation.
>
>
> Best regards,
> Simon Kulessa.
--
Diplom Informatiker Simon Kulessa
FlexSecure GmbH
Industriestr. 12
D - 64297 Darmstadt
Tel: +49 (0) 6151 501 23-15
Fax: +49 (0) 6151 501 23-19
E-Mail:kulessa@flexsecure.de
Internet:www.flexsecure.de
Geschäftsführer:
Erwin Stallenberger, Markus Ruppert
Amtsgericht Darmstadt HRB 8036
Umsatzsteuernummer: DE 214745269
RE: [Trinidad] concurrent access to a sortable table
Posted by Mark Millman <ma...@mizar.com>.
I've done the following to create SortableModel from Lists
model = (SortableModel)
org.apache.myfaces.trinidad.model.ModelUtils.toCollectionModel((Object)list)
;
It's not elegant but it seems to work well enough.
Mark
-----Original Message-----
From: Simon Kulessa [mailto:kulessa@flexsecure.de]
Sent: Wednesday, June 09, 2010 4:08 AM
To: users@myfaces.apache.org
Subject: [Trinidad] concurrent access to a sortable table
Hello everyone,
I am developing a web application for my company based on JSF 1.2.14 and
Trinidad 1.2.13. In this application we have different views
that are displayed with the help of the <tr:table> tag.
We discovered recently that the default data model
does not support concurrent access to the data.
Source:
http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/t
rinidad/model/CollectionModel.html
--
The only solution to this problem i have discovered so far, is that
we have to implement our own CollectionModel to support unique row keys.
Question 1: Is there really no other way to support concurrent access?
Question 2: Does a tutorial or a discription exist, how the framework
uses the CollectionModel? Or a tutorial for implementing your own
CollectionModel ?
--
I have tried to implement a class that extends the CollectionModel class
and implemented the necessary methods.
For example: I used the setWrappedData(Object o) method to save the data
as an attribute inside the CollectionModel and to generate an index to
map the uniqueKey to the specified row.
Request 3: It would be helpfull if someone can provide a sample for an
efficient implementation of a CollectionModel ?
--
To return the CollectionModel to the Framework I changed the return type
of the getData method (<tr:table values="someBean.data">) from the
previously used List<Data> to CollectionModel, which now wrapps the
List<Data>.
The bad thing is, that the framework calls this method three times
during the render phase. That means I currently need to create/convert
the CollectionModel and the index for the mapping three times.
Question 4: Is there a way to prevent this?
Maybe an additional check can be added to verify in which render state
the call is made?
--
Another problem is that our data table needs to support sorting.
The default CollectionModel does not support sorting and the
SortableCollectionMethod does not seem to be expandable
(since it uses Integer's as rowKeys).
The solution seems to override the "isSortable, getSortingCriteria,
setSortingCriteria" methods of the CollectionModel
and implement the sorting feature on your own.
Question 5: Again, is that really the way you have to do it?
Request 6: An efficient sample of an implementation would be nice.
--
Any help is appreciated.
If necessary I could provide my sample implementation.
Best regards,
Simon Kulessa.
--
Diplom Informatiker Simon Kulessa
FlexSecure GmbH
Industriestr. 12
D - 64297 Darmstadt
Tel: +49 (0) 6151 501 23-15
Fax: +49 (0) 6151 501 23-19
E-Mail:kulessa@flexsecure.de
Internet:www.flexsecure.de
Geschäftsführer:
Erwin Stallenberger, Markus Ruppert
Amtsgericht Darmstadt HRB 8036
Umsatzsteuernummer: DE 214745269