Re: PreserveDataModel behaviour (2)
Any comments? I think this is a serious issue...2005/9/15, Enrique Medina [EMAIL PROTECTED]:
Hi again,
I have investigated another interesting behaviour about using
PreserveDataModel, which makes my application crash (due to the way I'm
working with data tables). Let me explain it to you in a
straight-forward manner.
Currently, I use a session scoped bean to work with my objects (e.g.
one bean to work with customer objects, one bean to work with the
users, etc), due to the fact that I don't want to loose state between
requests (yes, I know it could have been done using
t:saveState...). So within all my session beans, I have defined
a ListDataModel variable that holds the data model that is presented to
the view every time the view is rendered (nothing strange here, I
guess).
>From my views (JSP), I simply use:
t:dataTable .. value=#{sessionScopedWhateverBean.listOfObjectsAsListDataModel}
So whenever the view is rendered, the method public DataModel
getListOfObjectsAsListDataModel() in my session scoped bean is
invoked. Obviously, the first time it will be created, and the
subsequent calls simply will return the existing object. Everything's
fine here.
The problem comes when using PreserveDataModel because, as explained in
the wiki I posted about working with PreserveDataModel, every object in
my listOfObjectsAsListDataModel is added to a new ArrayList belonging
to a new _SerializedDataModel object, which is the object being really
serialized when saving the state by the JspStateManagerImpl. And why is
it the problem? Think about the future restoring phase...
When a link is clicked inside the data table to work with a particular
object, the event created as a consequence of the clicked link has
the information about the exact row which has been clicked
(specifically in its rowIndex attribute). Following, the state is
restored, and the previously serialized data model (as a
_SerializedDataModel object) is used to set the information about the
clicked row. What does this mean? It's as simple as this: the
clicked row information is set on the restored object, so it is
really set on the _SerializedDataModel object (nothing to be with our
original ListOfObjectsAsListDataModel object).
When afterwards the broadcast calls our action method (the one
associated with the link in the data table through usually an
HtmlCommandLink tag), our session scoped bean has the original
ListOfObjectsAsListDataModel object that was used to create the
_SerializedDataModel object when saving the state. But with a
definitive difference: the rowIndex from the event was set on the
_SerializedDataModel object, not the one we have here now, i.e. our
ListOfObjectsAsListDataModel object. And due to the fact that our
ListOfObjectsAsListDataModel was used to create the
_SerializedDataModel object, now it has its internal rowIndex attribute
set to the last row plus one (obviously, as the saveState method
iterates through the ListOfObjectsAsListDataModel list of objects to
populate the _SerializedDataModel list of objects).
At the end, the result is a call to setRowIndex(last row + 1), which
obviously does not exist, so a IllegalArgumentException: row is
unavailable is thrown. On the other hand, if I don't use
preserveDataModel, everything works perfectly, as the
ListOfObjectsAsListDataModel object is the one used to save the state
(not the _SerializedDataModel).
IMHO, the solution will be as simple as updating my
ListOfObjectsAsListDataModel object with the _SerializedDataModel
object when restoring the state. But I would like to hear the MyFaces'
team experts about this possibility before going deeper into the code.
Is it feasible? Is it possible to work with the preserveDataModel
together with a DataModel inside my bean and the getRowData() method?
Is the use od preserveDataModel incompatible with using the
getRowData() method inside my bean?
Looking forward to hearing your comments :-)
Re: PreserveDataModel behaviour (2)
Hi Martin,
What does 'ev' stands for?
One of the possible solutions I suggested was, the same way a new
_SerializedDataModel is generated from the current data model (my own
ListOfObjectsAsListDataModel), to assign the serialized data model to
the original data model in the restoring data phase.
Please also note that I also posted a solution to the problem of lazy
loading in Hibernate through the use of a LazyListDataModel object via
callback mechanisms (so this will also not work with
preserveDataModel...).2005/9/16, Martin Marinschek [EMAIL PROTECTED]:
Well,the preserveDataModel feature was not programmed especially for thisuse, I would say. I understand your interest for such a usecase,though.Were I've got my problems is that with normal valueBindings for the
dataTable, the model of the backing bean will not be used until therender response phase, instead the serialized data model will be used- for me this means that you will need to use the serialized datamodel in your backing bean as well.
Why do you need to use your original model?can't you say ((UIData) ev.getParent().getParent()).getDataModel()?regards,MartinOn 9/15/05, Enrique Medina
[EMAIL PROTECTED] wrote: Hi again,I have investigated another interesting behaviour about using PreserveDataModel, which makes my application crash (due to the way I'm working with data tables). Let me explain it to you in a straight-forward
manner.Currently, I use a session scoped bean to work with my objects (e.g. one bean to work with customer objects, one bean to work with the users, etc), due to the fact that I don't want to loose state between requests (yes, I
know it could have been done using t:saveState...). So within all my session beans, I have defined a ListDataModel variable that holds the data model that is presented to the view every time the view is rendered (nothing
strange here, I guess).From my views (JSP), I simply use:t:dataTable .. value=#{sessionScopedWhateverBean.listOfObjectsAsListDataModel}
So whenever the view is rendered, the method public DataModel getListOfObjectsAsListDataModel() in my session scoped bean is invoked. Obviously, the first time it will be created, and the
subsequent calls simply will return the existing object. Everything's fine here.The problem comes when using PreserveDataModel because, as explained in the wiki I posted about working with PreserveDataModel, every object in my
listOfObjectsAsListDataModel is added to a new ArrayList belonging to a new _SerializedDataModel object, which is the object being really serialized when saving the state by the JspStateManagerImpl. And why is it the problem?
Think about the future restoring phase...When a link is clicked inside the data table to work with a particular object, the event created as a consequence of the clicked link has the
information about the exact row which has been clicked (specifically in its rowIndex attribute). Following, the state is restored, and the previously serialized data model (as a _SerializedDataModel object) is used to set the
information about the clicked row. What does this mean? It's as simple as this: the clicked row information is set on the restored object, so it is really set on the _SerializedDataModel object (nothing to be with our
original ListOfObjectsAsListDataModel object).When afterwards the broadcast calls our action method (the one associated with the link in the data table through usually an HtmlCommandLink tag), our
session scoped bean has the original ListOfObjectsAsListDataModel object that was used to create the _SerializedDataModel object when saving the state. But with a definitive difference: the rowIndex from the event was set
on the _SerializedDataModel object, not the one we have here now, i.e. our ListOfObjectsAsListDataModel object. And due to the fact that our ListOfObjectsAsListDataModel was used to create the _SerializedDataModel
object, now it has its internal rowIndex attribute set to the last row plus one (obviously, as the saveState method iterates through the ListOfObjectsAsListDataModel list of objects to populate the
_SerializedDataModel list of objects).At the end, the result is a call to setRowIndex(last row + 1), which obviously does not exist, so a IllegalArgumentException: row is unavailable is thrown. On the other hand, if I don't use preserveDataModel,
everything works perfectly, as the ListOfObjectsAsListDataModel object is the one used to save the state (not the _SerializedDataModel).IMHO, the solution will be as simple as updating my
ListOfObjectsAsListDataModel object with the _SerializedDataModel object when restoring the state. But I would like to hear the MyFaces' team experts about this possibility before going deeper into the code.
Is it feasible? Is it possible to work with the preserveDataModel together with a DataModel inside my bean and the getRowData() method? Is the use od preserveDataModel incompatible with using the getRowData() method inside my
bean?Looking
Re: PreserveDataModel behaviour (2)
Hmm,
but you can't restore the value if there is no DataModel you are
binding to, but just a simple list, right?
regards,
Martin
On 9/16/05, Enrique Medina [EMAIL PROTECTED] wrote:
Hi Martin,
What does 'ev' stands for?
One of the possible solutions I suggested was, the same way a new
_SerializedDataModel is generated from the current data model (my own
ListOfObjectsAsListDataModel), to assign the serialized data model to the
original data model in the restoring data phase.
Please also note that I also posted a solution to the problem of lazy
loading in Hibernate through the use of a LazyListDataModel object via
callback mechanisms (so this will also not work with preserveDataModel...).
2005/9/16, Martin Marinschek [EMAIL PROTECTED]:
Well,
the preserveDataModel feature was not programmed especially for this
use, I would say. I understand your interest for such a usecase,
though.
Were I've got my problems is that with normal valueBindings for the
dataTable, the model of the backing bean will not be used until the
render response phase, instead the serialized data model will be used
- for me this means that you will need to use the serialized data
model in your backing bean as well.
Why do you need to use your original model?
can't you say ((UIData) ev.getParent().getParent()).getDataModel()?
regards,
Martin
On 9/15/05, Enrique Medina [EMAIL PROTECTED] wrote:
Hi again,
I have investigated another interesting behaviour about using
PreserveDataModel, which makes my application crash (due to the way I'm
working with data tables). Let me explain it to you in a
straight-forward
manner.
Currently, I use a session scoped bean to work with my objects (e.g.
one
bean to work with customer objects, one bean to work with the users,
etc),
due to the fact that I don't want to loose state between requests (yes,
I
know it could have been done using t:saveState...). So within all my
session beans, I have defined a ListDataModel variable that holds the
data
model that is presented to the view every time the view is rendered
(nothing
strange here, I guess).
From my views (JSP), I simply use:
t:dataTable ..
value=#{sessionScopedWhateverBean.listOfObjectsAsListDataModel}
So whenever the view is rendered, the method public DataModel
getListOfObjectsAsListDataModel() in my session scoped
bean is invoked. Obviously, the first time it will be created, and the
subsequent calls simply will return the existing object. Everything's
fine
here.
The problem comes when using PreserveDataModel because, as explained in
the
wiki I posted about working with PreserveDataModel, every object in my
listOfObjectsAsListDataModel is added to a new ArrayList belonging to a
new
_SerializedDataModel object, which is the object being really serialized
when saving the state by the JspStateManagerImpl. And why is it the
problem?
Think about the future restoring phase...
When a link is clicked inside the data table to work with a particular
object, the event created as a consequence of the clicked link has the
information about the exact row which has been clicked (specifically in
its
rowIndex attribute). Following, the state is restored, and the
previously
serialized data model (as a _SerializedDataModel object) is used to set
the
information about the clicked row. What does this mean? It's as simple
as
this: the clicked row information is set on the restored object, so it
is
really set on the _SerializedDataModel object (nothing to be with our
original ListOfObjectsAsListDataModel object).
When afterwards the broadcast calls our action method (the one
associated
with the link in the data table through usually an HtmlCommandLink tag),
our
session scoped bean has the original ListOfObjectsAsListDataModel object
that was used to create the _SerializedDataModel object when saving the
state. But with a definitive difference: the rowIndex from the event was
set
on the _SerializedDataModel object, not the one we have here now, i.e.
our
ListOfObjectsAsListDataModel object. And due to the fact that our
ListOfObjectsAsListDataModel was used to create the _SerializedDataModel
object, now it has its internal rowIndex attribute set to the last row
plus
one (obviously, as the saveState method iterates through the
ListOfObjectsAsListDataModel list of objects to populate the
_SerializedDataModel list of objects).
At the end, the result is a call to setRowIndex(last row + 1), which
obviously does not exist, so a IllegalArgumentException: row is
unavailable is thrown. On the other hand, if I don't use
preserveDataModel,
everything works perfectly, as the ListOfObjectsAsListDataModel object
is
the one used to save the state (not the _SerializedDataModel).
Re: PreserveDataModel behaviour (2)
Well, my ListOfObjectsAsListDataModel is indeed a DataModel, binded
through the value attribute of the tree component. But IMHO, if I used
an HtmlDataTable object binded to the tree component, I would get the
same result, as the _SerializedDataModel would be also created and used
in the restore phase, instead of my original data model object,
wouldn't it?2005/9/16, Martin Marinschek [EMAIL PROTECTED]:
Hmm,but you can't restore the value if there is no DataModel you arebinding to, but just a simple list, right?regards,MartinOn 9/16/05, Enrique Medina
[EMAIL PROTECTED] wrote: Hi Martin,What does 'ev' stands for?One of the possible solutions I suggested was, the same way a new _SerializedDataModel is generated from the current data model (my own
ListOfObjectsAsListDataModel), to assign the serialized data model to the original data model in the restoring data phase.Please also note that I also posted a solution to the problem of lazy
loading in Hibernate through the use of a LazyListDataModel object via callback mechanisms (so this will also not work with preserveDataModel...). 2005/9/16, Martin Marinschek
[EMAIL PROTECTED]: Well, the preserveDataModel feature was not programmed especially for this use, I would say. I understand your interest for such a usecase,
though. Were I've got my problems is that with normal valueBindings for the dataTable, the model of the backing bean will not be used until the render response phase, instead the serialized data model will be used
- for me this means that you will need to use the serialized data model in your backing bean as well. Why do you need to use your original model? can't you say ((UIData)
ev.getParent().getParent()).getDataModel()? regards, MartinOn 9/15/05, Enrique Medina
[EMAIL PROTECTED] wrote: Hi again,I have investigated another interesting behaviour about using PreserveDataModel, which makes my application crash (due to the way I'm
working with data tables). Let me explain it to you in a straight-forward manner.Currently, I use a session scoped bean to work with my objects (
e.g. one bean to work with customer objects, one bean to work with the users, etc), due to the fact that I don't want to loose state between requests (yes, I
know it could have been done using t:saveState...). So within all my session beans, I have defined a ListDataModel variable that holds the data model that is presented to the view every time the view is rendered
(nothing strange here, I guess).From my views (JSP), I simply use:t:dataTable .. value=#{
sessionScopedWhateverBean.listOfObjectsAsListDataModel} So whenever the view is rendered, the method public DataModel getListOfObjectsAsListDataModel() in my session scoped
bean is invoked. Obviously, the first time it will be created, and the subsequent calls simply will return the existing object. Everything's fine here.
The problem comes when using PreserveDataModel because, as explained in the wiki I posted about working with PreserveDataModel, every object in my listOfObjectsAsListDataModel is added to a new ArrayList belonging to a
new _SerializedDataModel object, which is the object being really serialized when saving the state by the JspStateManagerImpl. And why is it the problem? Think about the future restoring phase...
When a link is clicked inside the data table to work with a particular object, the event created as a consequence of the clicked link has the information about the exact row which has been clicked (specifically in
its rowIndex attribute). Following, the state is restored, and the previously serialized data model (as a _SerializedDataModel object) is used to set the information about the clicked row. What does this mean? It's as simple
as this: the clicked row information is set on the restored object, so it is really set on the _SerializedDataModel object (nothing to be with our original ListOfObjectsAsListDataModel object).
When afterwards the broadcast calls our action method (the one associated with the link in the data table through usually an HtmlCommandLink tag), our
session scoped bean has the original ListOfObjectsAsListDataModel object that was used to create the _SerializedDataModel object when saving the state. But with a definitive difference: the rowIndex from the event was
set on the _SerializedDataModel object, not the one we have here now, i.e. our ListOfObjectsAsListDataModel object. And due to the fact that our ListOfObjectsAsListDataModel was used to create the _SerializedDataModel
object, now it has its internal rowIndex attribute set to the last row plus one (obviously, as the saveState method iterates through the ListOfObjectsAsListDataModel list of objects to populate the
_SerializedDataModel list of objects).At the end, the result is a call to setRowIndex(last row + 1), which obviously does not exist, so a
Re: PreserveDataModel behaviour (2)
So you are using a dataTable embedded in a tree?
On 9/16/05, Enrique Medina [EMAIL PROTECTED] wrote:
Well, my ListOfObjectsAsListDataModel is indeed a DataModel, binded
through the value attribute of the tree component. But IMHO, if I used an
HtmlDataTable object binded to the tree component, I would get the same
result, as the _SerializedDataModel would be also created and used in the
restore phase, instead of my original data model object, wouldn't it?
2005/9/16, Martin Marinschek [EMAIL PROTECTED]:
Hmm,
but you can't restore the value if there is no DataModel you are
binding to, but just a simple list, right?
regards,
Martin
On 9/16/05, Enrique Medina [EMAIL PROTECTED] wrote:
Hi Martin,
What does 'ev' stands for?
One of the possible solutions I suggested was, the same way a new
_SerializedDataModel is generated from the current data model (my own
ListOfObjectsAsListDataModel), to assign the serialized data model to
the
original data model in the restoring data phase.
Please also note that I also posted a solution to the problem of lazy
loading in Hibernate through the use of a LazyListDataModel object via
callback mechanisms (so this will also not work with
preserveDataModel...).
2005/9/16, Martin Marinschek [EMAIL PROTECTED]:
Well,
the preserveDataModel feature was not programmed especially for this
use, I would say. I understand your interest for such a usecase,
though.
Were I've got my problems is that with normal valueBindings for the
dataTable, the model of the backing bean will not be used until the
render response phase, instead the serialized data model will be used
- for me this means that you will need to use the serialized data
model in your backing bean as well.
Why do you need to use your original model?
can't you say ((UIData) ev.getParent().getParent()).getDataModel()?
regards,
Martin
On 9/15/05, Enrique Medina [EMAIL PROTECTED] wrote:
Hi again,
I have investigated another interesting behaviour about using
PreserveDataModel, which makes my application crash (due to the way
I'm
working with data tables). Let me explain it to you in a
straight-forward
manner.
Currently, I use a session scoped bean to work with my objects (
e.g.
one
bean to work with customer objects, one bean to work with the users,
etc),
due to the fact that I don't want to loose state between requests
(yes,
I
know it could have been done using t:saveState...). So within all
my
session beans, I have defined a ListDataModel variable that holds
the
data
model that is presented to the view every time the view is rendered
(nothing
strange here, I guess).
From my views (JSP), I simply use:
t:dataTable ..
value=#{
sessionScopedWhateverBean.listOfObjectsAsListDataModel}
So whenever the view is rendered, the method public DataModel
getListOfObjectsAsListDataModel() in my session
scoped
bean is invoked. Obviously, the first time it will be created, and
the
subsequent calls simply will return the existing object.
Everything's
fine
here.
The problem comes when using PreserveDataModel because, as
explained in
the
wiki I posted about working with PreserveDataModel, every object in
my
listOfObjectsAsListDataModel is added to a new ArrayList belonging
to a
new
_SerializedDataModel object, which is the object being really
serialized
when saving the state by the JspStateManagerImpl. And why is it the
problem?
Think about the future restoring phase...
When a link is clicked inside the data table to work with a
particular
object, the event created as a consequence of the clicked link has
the
information about the exact row which has been clicked (specifically
in
its
rowIndex attribute). Following, the state is restored, and the
previously
serialized data model (as a _SerializedDataModel object) is used to
set
the
information about the clicked row. What does this mean? It's as
simple
as
this: the clicked row information is set on the restored object,
so it
is
really set on the _SerializedDataModel object (nothing to be with
our
original ListOfObjectsAsListDataModel object).
When afterwards the broadcast calls our action method (the one
associated
with the link in the data table through usually an HtmlCommandLink
tag),
our
session scoped bean has the original ListOfObjectsAsListDataModel
object
that was used to create the _SerializedDataModel object when saving
the
state. But with a definitive difference: the rowIndex from the event
was
set
on the _SerializedDataModel object, not the one we have here now,
i.e.
Re: PreserveDataModel behaviour (2)
Yes, I have a session scoped bean called UsuariosBean, which has
defined a variable of type ListDataModel called usuariosDataModel.
Then, in the JSP page, I have:
t:tree2 id= value=#{usuariosBean.usuariosDataTable} ...
So whenever the component needs the data model, it invokes my getUsuariosDataModel() method from my UsuariosBean, as obvious.2005/9/16, Martin Marinschek
[EMAIL PROTECTED]:So you are using a dataTable embedded in a tree?
On 9/16/05, Enrique Medina [EMAIL PROTECTED] wrote: Well, my ListOfObjectsAsListDataModel is indeed a DataModel, binded through the value attribute of the tree component. But IMHO, if I used an
HtmlDataTable object binded to the tree component, I would get the same result, as the _SerializedDataModel would be also created and used in the restore phase, instead of my original data model object, wouldn't it?
2005/9/16, Martin Marinschek [EMAIL PROTECTED]: Hmm, but you can't restore the value if there is no DataModel you are
binding to, but just a simple list, right? regards, Martin On 9/16/05, Enrique Medina
[EMAIL PROTECTED] wrote: Hi Martin,What does 'ev' stands for?One of the possible solutions I suggested was, the same way a new
_SerializedDataModel is generated from the current data model (my own ListOfObjectsAsListDataModel), to assign the serialized data model to the original data model in the restoring data phase.
Please also note that I also posted a solution to the problem of lazy loading in Hibernate through the use of a LazyListDataModel object via callback mechanisms (so this will also not work with
preserveDataModel...). 2005/9/16, Martin Marinschek [EMAIL PROTECTED]:Well,
the preserveDataModel feature was not programmed especially for thisuse, I would say. I understand your interest for such a usecase,though.
Were I've got my problems is that with normal valueBindings for thedataTable, the model of the backing bean will not be used until therender response phase, instead the serialized data model will be used
- for me this means that you will need to use the serialized datamodel in your backing bean as well. Why do you need to use your original model?
can't you say ((UIData) ev.getParent().getParent()).getDataModel()? regards, Martin
On 9/15/05, Enrique Medina [EMAIL PROTECTED] wrote: Hi again,
I have investigated another interesting behaviour about using PreserveDataModel, which makes my application crash (due to the way I'm working with data tables). Let me explain it to you in a
straight-forward manner.Currently, I use a session scoped bean to work with my objects ( e.g. one
bean to work with customer objects, one bean to work with the users, etc), due to the fact that I don't want to loose state between requests (yes,
I know it could have been done using t:saveState...). So within all my session beans, I have defined a ListDataModel variable that holds
the data model that is presented to the view every time the view is rendered (nothing strange here, I guess).
From my views (JSP), I simply use:t:dataTable .. value=#{ sessionScopedWhateverBean.listOfObjectsAsListDataModel
} So whenever the view is rendered, the method public DataModel getListOfObjectsAsListDataModel() in my session
scoped bean is invoked. Obviously, the first time it will be created, and the subsequent calls simply will return the existing object. Everything's
fine here.The problem comes when using PreserveDataModel because, as explained in the wiki I posted about working with PreserveDataModel, every object in
my listOfObjectsAsListDataModel is added to a new ArrayList belonging to a new _SerializedDataModel object, which is the object being really
serialized when saving the state by the JspStateManagerImpl. And why is it the problem? Think about the future restoring phase...
When a link is clicked inside the data table to work with a particular object, the event created as a consequence of the clicked link has the
information about the exact row which has been clicked (specifically in its rowIndex attribute). Following, the state is restored, and the
previously serialized data model (as a _SerializedDataModel object) is used to set the information about the clicked row. What does this mean? It's as
simple as this: the clicked row information is set on the restored object, so it is really set on the _SerializedDataModel object (nothing to be with
our original ListOfObjectsAsListDataModel object).When afterwards the broadcast calls our action method (the one associated
with the link in the data table through usually an HtmlCommandLink tag), our session scoped bean has the original ListOfObjectsAsListDataModel
object
PreserveDataModel behaviour (2)
Hi again,
I have investigated another interesting behaviour about using
PreserveDataModel, which makes my application crash (due to the way I'm
working with data tables). Let me explain it to you in a
straight-forward manner.
Currently, I use a session scoped bean to work with my objects (e.g.
one bean to work with customer objects, one bean to work with the
users, etc), due to the fact that I don't want to loose state between
requests (yes, I know it could have been done using
t:saveState...). So within all my session beans, I have defined
a ListDataModel variable that holds the data model that is presented to
the view every time the view is rendered (nothing strange here, I
guess).
>From my views (JSP), I simply use:
t:dataTable .. value=#{sessionScopedWhateverBean.listOfObjectsAsListDataModel}
So whenever the view is rendered, the method public DataModel
getListOfObjectsAsListDataModel() in my session scoped bean is
invoked. Obviously, the first time it will be created, and the
subsequent calls simply will return the existing object. Everything's
fine here.
The problem comes when using PreserveDataModel because, as explained in
the wiki I posted about working with PreserveDataModel, every object in
my listOfObjectsAsListDataModel is added to a new ArrayList belonging
to a new _SerializedDataModel object, which is the object being really
serialized when saving the state by the JspStateManagerImpl. And why is
it the problem? Think about the future restoring phase...
When a link is clicked inside the data table to work with a particular
object, the event created as a consequence of the clicked link has
the information about the exact row which has been clicked
(specifically in its rowIndex attribute). Following, the state is
restored, and the previously serialized data model (as a
_SerializedDataModel object) is used to set the information about the
clicked row. What does this mean? It's as simple as this: the
clicked row information is set on the restored object, so it is
really set on the _SerializedDataModel object (nothing to be with our
original ListOfObjectsAsListDataModel object).
When afterwards the broadcast calls our action method (the one
associated with the link in the data table through usually an
HtmlCommandLink tag), our session scoped bean has the original
ListOfObjectsAsListDataModel object that was used to create the
_SerializedDataModel object when saving the state. But with a
definitive difference: the rowIndex from the event was set on the
_SerializedDataModel object, not the one we have here now, i.e. our
ListOfObjectsAsListDataModel object. And due to the fact that our
ListOfObjectsAsListDataModel was used to create the
_SerializedDataModel object, now it has its internal rowIndex attribute
set to the last row plus one (obviously, as the saveState method
iterates through the ListOfObjectsAsListDataModel list of objects to
populate the _SerializedDataModel list of objects).
At the end, the result is a call to setRowIndex(last row + 1), which
obviously does not exist, so a IllegalArgumentException: row is
unavailable is thrown. On the other hand, if I don't use
preserveDataModel, everything works perfectly, as the
ListOfObjectsAsListDataModel object is the one used to save the state
(not the _SerializedDataModel).
IMHO, the solution will be as simple as updating my
ListOfObjectsAsListDataModel object with the _SerializedDataModel
object when restoring the state. But I would like to hear the MyFaces'
team experts about this possibility before going deeper into the code.
Is it feasible? Is it possible to work with the preserveDataModel
together with a DataModel inside my bean and the getRowData() method?
Is the use od preserveDataModel incompatible with using the
getRowData() method inside my bean?
Looking forward to hearing your comments :-)
