You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "sean schofield (JIRA)" <in...@incubator.apache.org> on 2005/01/31 23:42:20 UTC
[jira] Created: (MYFACES-98) Allow x:dataTable to store its data model in the component tree
Allow x:dataTable to store its data model in the component tree
---------------------------------------------------------------
Key: MYFACES-98
URL: http://issues.apache.org/jira/browse/MYFACES-98
Project: MyFaces
Type: New Feature
Versions: 1.0.7 beta, 1.0.8 beta
Reporter: sean schofield
Priority: Minor
I'm proposing a new attribute (saveModel) for x:dataTable that can be true/false (default is false).
When "true", the bean that is associated with the "value" attribute would be stored in the component tree. I'm going to look to the <x:saveState> tag for guidance on this, but the idea would be that you do not have to use <x:saveState> tag for this purpose once the feature is implemented.
The saved value of the data model would be restored during the Restore View phase. Among other things, this would allow actions to be applied to the component with the row index corresponding to the one the user clicked even if the data store used has since changed. Just before the Render Response phase, the component could use the binding expression combined with the bean management facility to create an updated version of the data model which is then saved to the client state and rendered.
This way you have the best of both worlds. You can have value change and action events based on a comparisson of the same data that was used for the original response and the user will still see the latest data when the response is encoded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Re: [jira] Created: (MYFACES-98) Allow x:dataTable to store its
data model in the component tree
Posted by Alessandro Polverini <al...@nibbles.it>.
On Tue, 2005-02-01 at 09:25 +0100, Martin Marinschek wrote:
> Exactly, use the preserveDataModel attribute and you are all set!
>
> Manfred had a very hard time implementing that one, as far as I remember ;)
Hello Martin,
I tried to set preserveDataModel to true to avoid the x:saveState
declaration, but this would not work (in my case, at least).
I try to explain my situation to better understand the behaviour: I have
a simple form with some search parameters, when the user submits it, the
backing bean (request scope) is populated with results and I show and
paginate through them using x:dataTable and x:dataScroller.
The only way I found to make it work well is:
- set preserveDataModel to false (or to not put the attribute
completely)
- use a x:saveState on #{bean.results}
Whithout doning this, I can see only the first page of results and every
other action (for example switch to page #2) the datas are lost and no
more rows are displayed.
The problem also occurs if I *both* use saveState and preserveDataModel,
maybe because the partially conflicts in their operation?
So, I deduce that preserveDataModel does not the very same thing of
saveState, and maybe the idea of Sean is useful anyway?
Or maybe preserveDataModel has a bug (or a limitation) and should be
fixed?
I would be interested to better understand this issue.
Thanks,
Alex
Re: [jira] Created: (MYFACES-98) Allow x:dataTable to store its data model in the component tree
Posted by Martin Marinschek <ma...@gmail.com>.
Exactly, use the preserveDataModel attribute and you are all set!
Manfred had a very hard time implementing that one, as far as I remember ;)
regards,
Martin
On Mon, 31 Jan 2005 23:56:00 -0500, Sean Schofield
<se...@gmail.com> wrote:
> There are definitely a lot of situations where you would expect the
> data to change like this. The program I am working on right now is
> an application that users use during the course of the day to update
> their progress on various documents. Often times you will have
> multiple people making changes to those documents at similar times.
> Of course the default should be to skip storage of the data model so
> that in your case where you don't worry about that sort of thing, you
> don't have the overhead of storing the model.
>
> Also, there are plenty of times where the changes in the data model
> won't cause a problem. A table that displays a report that is read
> only will not be an issue. Its only when you have a hyperlink or
> editable value in the table where you could potentially run into
> problems.
>
> Anyways it sounds like this feature is already available in
> x:dataTable. Nice :-)
>
> sean
>
> On Mon, 31 Jan 2005 22:25:05 -0600, Heath Borders
> <he...@gmail.com> wrote:
> > Well, I guess I'm thinking that you're in a somewhat specialized case
> > where you cannot guarantee synchronized access to data throughout a
> > session.
> >
> > For me, I'm generally able to do simple CRUD operations without the
> > data changing behind me. I could see that being a problem though if
> > multiple users are allowed access to the same data.
> >
> >
> > On Mon, 31 Jan 2005 18:11:10 -0500, Sean Schofield
> > <se...@gmail.com> wrote:
> > > > Your explanation of the problem here makes a little more sense to me
> > > > now. I support this change. Hopefully, most people wouldn't have to
> > > > use it, but if you're operating with really volatile data, I could see
> > > > how it could solve a lot of problems.
> > >
> > > What do you mean by "really volatile data"? It would seem that the
> > > only existing way around this would be to make your managed bean have
> > > session scope. Would you consider volatile to mean data that can
> > > change at some point during the session? A session can go on for
> > > hours if a user is active enough.
> > >
> > > I am glad that you agree that the feature should be added. Maybe I
> > > can convince you that is more useful than you think ... Or maybe you
> > > can convince me of another way to solve the problem? I've only
> > > recently started thinking about this problem so maybe there is another
> > > solution out there. If so, I am definitely interested to know what it
> > > would be. This enhancement may seem like overkill but I can't think
> > > of any other way around the problem.
> > >
> > > I strongly suspect that this is one of the reasons that <x:saveState>
> > > was created (although we'd have to check with the creators of
> > > saveState to be sure.)
> > >
> > > > -Heath Borders-Wing
> > >
> > > sean
> > >
> >
> >
> > --
> > -Heath Borders-Wing
> > hborders@mail.win.org
> >
>
Re: [jira] Created: (MYFACES-98) Allow x:dataTable to store its data model in the component tree
Posted by Sean Schofield <se...@gmail.com>.
There are definitely a lot of situations where you would expect the
data to change like this. The program I am working on right now is
an application that users use during the course of the day to update
their progress on various documents. Often times you will have
multiple people making changes to those documents at similar times.
Of course the default should be to skip storage of the data model so
that in your case where you don't worry about that sort of thing, you
don't have the overhead of storing the model.
Also, there are plenty of times where the changes in the data model
won't cause a problem. A table that displays a report that is read
only will not be an issue. Its only when you have a hyperlink or
editable value in the table where you could potentially run into
problems.
Anyways it sounds like this feature is already available in
x:dataTable. Nice :-)
sean
On Mon, 31 Jan 2005 22:25:05 -0600, Heath Borders
<he...@gmail.com> wrote:
> Well, I guess I'm thinking that you're in a somewhat specialized case
> where you cannot guarantee synchronized access to data throughout a
> session.
>
> For me, I'm generally able to do simple CRUD operations without the
> data changing behind me. I could see that being a problem though if
> multiple users are allowed access to the same data.
>
>
> On Mon, 31 Jan 2005 18:11:10 -0500, Sean Schofield
> <se...@gmail.com> wrote:
> > > Your explanation of the problem here makes a little more sense to me
> > > now. I support this change. Hopefully, most people wouldn't have to
> > > use it, but if you're operating with really volatile data, I could see
> > > how it could solve a lot of problems.
> >
> > What do you mean by "really volatile data"? It would seem that the
> > only existing way around this would be to make your managed bean have
> > session scope. Would you consider volatile to mean data that can
> > change at some point during the session? A session can go on for
> > hours if a user is active enough.
> >
> > I am glad that you agree that the feature should be added. Maybe I
> > can convince you that is more useful than you think ... Or maybe you
> > can convince me of another way to solve the problem? I've only
> > recently started thinking about this problem so maybe there is another
> > solution out there. If so, I am definitely interested to know what it
> > would be. This enhancement may seem like overkill but I can't think
> > of any other way around the problem.
> >
> > I strongly suspect that this is one of the reasons that <x:saveState>
> > was created (although we'd have to check with the creators of
> > saveState to be sure.)
> >
> > > -Heath Borders-Wing
> >
> > sean
> >
>
>
> --
> -Heath Borders-Wing
> hborders@mail.win.org
>
Re: [jira] Created: (MYFACES-98) Allow x:dataTable to store its data model in the component tree
Posted by Heath Borders <he...@gmail.com>.
Well, I guess I'm thinking that you're in a somewhat specialized case
where you cannot guarantee synchronized access to data throughout a
session.
For me, I'm generally able to do simple CRUD operations without the
data changing behind me. I could see that being a problem though if
multiple users are allowed access to the same data.
On Mon, 31 Jan 2005 18:11:10 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > Your explanation of the problem here makes a little more sense to me
> > now. I support this change. Hopefully, most people wouldn't have to
> > use it, but if you're operating with really volatile data, I could see
> > how it could solve a lot of problems.
>
> What do you mean by "really volatile data"? It would seem that the
> only existing way around this would be to make your managed bean have
> session scope. Would you consider volatile to mean data that can
> change at some point during the session? A session can go on for
> hours if a user is active enough.
>
> I am glad that you agree that the feature should be added. Maybe I
> can convince you that is more useful than you think ... Or maybe you
> can convince me of another way to solve the problem? I've only
> recently started thinking about this problem so maybe there is another
> solution out there. If so, I am definitely interested to know what it
> would be. This enhancement may seem like overkill but I can't think
> of any other way around the problem.
>
> I strongly suspect that this is one of the reasons that <x:saveState>
> was created (although we'd have to check with the creators of
> saveState to be sure.)
>
> > -Heath Borders-Wing
>
> sean
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: [jira] Created: (MYFACES-98) Allow x:dataTable to store its data model in the component tree
Posted by Sean Schofield <se...@gmail.com>.
> Your explanation of the problem here makes a little more sense to me
> now. I support this change. Hopefully, most people wouldn't have to
> use it, but if you're operating with really volatile data, I could see
> how it could solve a lot of problems.
What do you mean by "really volatile data"? It would seem that the
only existing way around this would be to make your managed bean have
session scope. Would you consider volatile to mean data that can
change at some point during the session? A session can go on for
hours if a user is active enough.
I am glad that you agree that the feature should be added. Maybe I
can convince you that is more useful than you think ... Or maybe you
can convince me of another way to solve the problem? I've only
recently started thinking about this problem so maybe there is another
solution out there. If so, I am definitely interested to know what it
would be. This enhancement may seem like overkill but I can't think
of any other way around the problem.
I strongly suspect that this is one of the reasons that <x:saveState>
was created (although we'd have to check with the creators of
saveState to be sure.)
> -Heath Borders-Wing
sean
Re: [jira] Created: (MYFACES-98) Allow x:dataTable to store its data model in the component tree
Posted by Heath Borders <he...@gmail.com>.
Your explanation of the problem here makes a little more sense to me
now. I support this change. Hopefully, most people wouldn't have to
use it, but if you're operating with really volatile data, I could see
how it could solve a lot of problems.
On Mon, 31 Jan 2005 23:42:20 +0100 (CET), sean schofield (JIRA)
<in...@incubator.apache.org> wrote:
> Allow x:dataTable to store its data model in the component tree
> ---------------------------------------------------------------
>
> Key: MYFACES-98
> URL: http://issues.apache.org/jira/browse/MYFACES-98
> Project: MyFaces
> Type: New Feature
> Versions: 1.0.7 beta, 1.0.8 beta
> Reporter: sean schofield
> Priority: Minor
>
> I'm proposing a new attribute (saveModel) for x:dataTable that can be true/false (default is false).
>
> When "true", the bean that is associated with the "value" attribute would be stored in the component tree. I'm going to look to the <x:saveState> tag for guidance on this, but the idea would be that you do not have to use <x:saveState> tag for this purpose once the feature is implemented.
>
> The saved value of the data model would be restored during the Restore View phase. Among other things, this would allow actions to be applied to the component with the row index corresponding to the one the user clicked even if the data store used has since changed. Just before the Render Response phase, the component could use the binding expression combined with the bean management facility to create an updated version of the data model which is then saved to the client state and rendered.
>
> This way you have the best of both worlds. You can have value change and action events based on a comparisson of the same data that was used for the original response and the user will still see the latest data when the response is encoded.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> If you want more information on JIRA, or have a bug to report see:
> http://www.atlassian.com/software/jira
>
>
--
-Heath Borders-Wing
hborders@mail.win.org
[jira] Commented: (MYFACES-98) Allow x:dataTable to store its data model in the component tree
Posted by "sean schofield (JIRA)" <in...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-98?page=comments#action_59249 ]
sean schofield commented on MYFACES-98:
---------------------------------------
This functionality already exists with preserveDataModel attribute. This bug should be resolved won't fix / works for me.
> Allow x:dataTable to store its data model in the component tree
> ---------------------------------------------------------------
>
> Key: MYFACES-98
> URL: http://issues.apache.org/jira/browse/MYFACES-98
> Project: MyFaces
> Type: New Feature
> Versions: 1.0.7 beta, 1.0.8 beta
> Reporter: sean schofield
> Priority: Minor
>
> I'm proposing a new attribute (saveModel) for x:dataTable that can be true/false (default is false).
> When "true", the bean that is associated with the "value" attribute would be stored in the component tree. I'm going to look to the <x:saveState> tag for guidance on this, but the idea would be that you do not have to use <x:saveState> tag for this purpose once the feature is implemented.
> The saved value of the data model would be restored during the Restore View phase. Among other things, this would allow actions to be applied to the component with the row index corresponding to the one the user clicked even if the data store used has since changed. Just before the Render Response phase, the component could use the binding expression combined with the bean management facility to create an updated version of the data model which is then saved to the client state and rendered.
> This way you have the best of both worlds. You can have value change and action events based on a comparisson of the same data that was used for the original response and the user will still see the latest data when the response is encoded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-98) Allow x:dataTable to store its data model in the component tree
Posted by "Martin Marinschek (JIRA)" <in...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-98?page=history ]
Martin Marinschek resolved MYFACES-98:
--------------------------------------
Assign To: Manfred Geiler
Resolution: Fixed
Fix Version: 1.0.7 beta
Has already been fixed before the issue was raised ;)
> Allow x:dataTable to store its data model in the component tree
> ---------------------------------------------------------------
>
> Key: MYFACES-98
> URL: http://issues.apache.org/jira/browse/MYFACES-98
> Project: MyFaces
> Type: New Feature
> Versions: 1.0.7 beta, 1.0.8 beta
> Reporter: sean schofield
> Assignee: Manfred Geiler
> Priority: Minor
> Fix For: 1.0.7 beta
>
> I'm proposing a new attribute (saveModel) for x:dataTable that can be true/false (default is false).
> When "true", the bean that is associated with the "value" attribute would be stored in the component tree. I'm going to look to the <x:saveState> tag for guidance on this, but the idea would be that you do not have to use <x:saveState> tag for this purpose once the feature is implemented.
> The saved value of the data model would be restored during the Restore View phase. Among other things, this would allow actions to be applied to the component with the row index corresponding to the one the user clicked even if the data store used has since changed. Just before the Render Response phase, the component could use the binding expression combined with the bean management facility to create an updated version of the data model which is then saved to the client state and rendered.
> This way you have the best of both worlds. You can have value change and action events based on a comparisson of the same data that was used for the original response and the user will still see the latest data when the response is encoded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-98) Allow x:dataTable to store its data model in the component tree
Posted by "sean schofield (JIRA)" <in...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-98?page=comments#action_58339 ]
sean schofield commented on MYFACES-98:
---------------------------------------
Werner Punz has informed me that there is already a preserveDataModel attribute on x:dataTable that does exactly what I am talking about. I will verify this shortly.
If this is true, many thanks to whoever thought of this before me!
> Allow x:dataTable to store its data model in the component tree
> ---------------------------------------------------------------
>
> Key: MYFACES-98
> URL: http://issues.apache.org/jira/browse/MYFACES-98
> Project: MyFaces
> Type: New Feature
> Versions: 1.0.7 beta, 1.0.8 beta
> Reporter: sean schofield
> Priority: Minor
>
> I'm proposing a new attribute (saveModel) for x:dataTable that can be true/false (default is false).
> When "true", the bean that is associated with the "value" attribute would be stored in the component tree. I'm going to look to the <x:saveState> tag for guidance on this, but the idea would be that you do not have to use <x:saveState> tag for this purpose once the feature is implemented.
> The saved value of the data model would be restored during the Restore View phase. Among other things, this would allow actions to be applied to the component with the row index corresponding to the one the user clicked even if the data store used has since changed. Just before the Render Response phase, the component could use the binding expression combined with the bean management facility to create an updated version of the data model which is then saved to the client state and rendered.
> This way you have the best of both worlds. You can have value change and action events based on a comparisson of the same data that was used for the original response and the user will still see the latest data when the response is encoded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira