Re: Concerning DataModel usage plus overhead?
Kevin, I am trying to get Sylvain involved in this to explain forceIndexFormula better (hint: this should be in the documentation ;) - but I believe that his solution is somewhat similar to your suggestion! Particularly, you just get the id of the data row as part of the client-id in your action, and it is your responsibility then to fetch this row! regards, Martin On 8/30/05, Kevin Galligan [EMAIL PROTECTED] wrote: My brain is very struts centric as well. There's some things I like about the JSF model too though. Thats why I'm probably landing somewhere in between. I generally avoided session scoping anything that didn't need to be, which I guess is my big reservation with JSF. I know exactly what you mean with the lazy list in the form. You do have some extra effort involved, like building the property string on the input objects and tracking the id's in a hidden input component, but there's not as much going on behind the curtain either. I think that's enough for today though... Rick Reumann wrote: On 8/30/05, Kevin Galligan [EMAIL PROTECTED] wrote: I think updating several rows at the same time, which might require local copies of the data, and just linking are two different things. They might need two different components. With Struts this was a piece of cake. Your ActionForm has a bean property that is a List of the objects you want to update (Helps if it's a LazyList if not using session scope), and when your form submits BeanUtils (in the background) simply copies your form objects to the List in the Action form. Super simple imo. The only slightly tricky part is validation, but I always provide a manual validation method in my Action classes so this was easy to handle. -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
Re: Concerning DataModel usage plus overhead?
Hello, I'm not sure I understand your problem, but I'll try to explain what I can : If your problem is that in fields in a table, only the first field is updated, then this has nothing to do with forceIndexFormula, and it might very well be a bug. I had a similar problem, but I didn't take the time to dig into it. Another probable bug is that the table content is only updated on the second request. This too might be a bug, and I didn't had time to check it either. The problem solved by forceIndexFormula is when the backend data can change between requests (order changes, or data insertion/deletion). It makes sure that the right row is updated. This is explained a the bottom of the t:dataTable doc : http://myfaces.apache.org/tomahawk/extDataTable.html HTH Sylvain. On Wed, 2005-08-31 at 08:53 +0200, Martin Marinschek wrote: Kevin, I am trying to get Sylvain involved in this to explain forceIndexFormula better (hint: this should be in the documentation ;) - but I believe that his solution is somewhat similar to your suggestion! Particularly, you just get the id of the data row as part of the client-id in your action, and it is your responsibility then to fetch this row! regards, Martin On 8/30/05, Kevin Galligan [EMAIL PROTECTED] wrote: My brain is very struts centric as well. There's some things I like about the JSF model too though. Thats why I'm probably landing somewhere in between. I generally avoided session scoping anything that didn't need to be, which I guess is my big reservation with JSF. I know exactly what you mean with the lazy list in the form. You do have some extra effort involved, like building the property string on the input objects and tracking the id's in a hidden input component, but there's not as much going on behind the curtain either. I think that's enough for today though... Rick Reumann wrote: On 8/30/05, Kevin Galligan [EMAIL PROTECTED] wrote: I think updating several rows at the same time, which might require local copies of the data, and just linking are two different things. They might need two different components. With Struts this was a piece of cake. Your ActionForm has a bean property that is a List of the objects you want to update (Helps if it's a LazyList if not using session scope), and when your form submits BeanUtils (in the background) simply copies your form objects to the List in the Action form. Super simple imo. The only slightly tricky part is validation, but I always provide a manual validation method in my Action classes so this was easy to handle.
RE: Concerning DataModel usage plus overhead?
Yes, the O'Reilly book has a chapter called Working with Tabular Data
and a section within it called Processing Row-Specific Events. Just
beware of the one bug in the example code that I mentioned earlier in
this thread, and make sure to do a t:saveState on your carListBean. I
haven't worked with the example in the book for several months, so I'll
have to go back to it and try to duplicate the problems Kevin says he
has encountered; we haven't noticed any problems in our applications,
but there may be some anomalies we're not aware of.
- Brendan
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Monday, August 29, 2005 7:43 PM
To: MyFaces Discussion
Subject: Re: Concerning DataModel usage plus overhead?
Thanks Brendan! This below looks wonderful. At home now and no time to
try it, but will tomorrow from work.
By the way, does the O'Reilly book present something like the below?
This is the exact kind of example that I think would be very useful to
see in a mini-demo-app.
On 8/29/05, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote:
Sounds good. Judging from what I understand about your e-mail, I'd
define something like:
managed-bean
managed-bean-namecarListBean/managed-bean-name
managed-bean-classcom.mycompany.CarListBean/managed-bean-class
managed-bean-scoperequest/managed-bean-scope
/managed-bean
managed-bean
managed-bean-namecarAction/managed-bean-name
managed-bean-classcom.mycompany.CarAction/managed-bean-class
managed-bean-scoperequest/managed-bean-scope
managed-property
property-namecarListBean/property-name
value#{carListBean}/value
/managed-property
/managed-bean
(I'm calling your data bean carListBean, rather than carListAction,
just
for my own clarity.)
Then, as you point out, you'd have a dataTable entry like
h:dataTable value=#{carListBean.carModel} var=car
h:column
h:commandLink action={carAction.getCar}
...
h:commandLink
h:column
...
/h:dataTable
Then, in your getCar() method, you'd have something like:
public String getCar() {
Car selectedCar = (Car)
getCarListBean().getCarModel().getRowData();
...
}
Hope that helps.
- Brendan
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Monday, August 29, 2005 4:02 PM
To: MyFaces Discussion
Subject: Re: Concerning DataModel usage plus overhead?
Actually, the MyFaces master/detail example source code is shedding
some light on some things. Rather than me waste more of your valuable
time, let me fart around with that code and see if I can tweak mine to
use a similar concept. Thanks for your help and patience so far.
On 8/29/05, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote:
Can you send a snippet of your faces-config.xml showing your managed
bean definitions and your navigations, just to make sure I have the
picture right?
- Brendan
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Monday, August 29, 2005 3:24 PM
To: MyFaces Discussion
Subject: Re: Concerning DataModel usage plus overhead?
On 8/29/05, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote:
I probably just got confused by your naming convention. Can you
repeat your
question with clearer names?
Sure. Let me change the names and concepts..
First page you come to is a list of cars on cars.jsp. Cars is
populated as DataModel from CarsListAction.java There is a
managed
bean reference for the name cars to CarsListAction.java.
CarsListAction has a method getCars which returns this DataModel.
On
cars.jsp you have...
h:dataTable var=car value=#{carsListAction.cars}
Another managed bean: CarAction.java has CRUD methods. In this case
getCar which is supposed to get a Car back from the backend
based
on 'carID.
I want to be able to click on car from the list on cars.jsp and hit
the getCar' method in my CarAction.java bean and forward to a
carForm.jsp that lets me edit the car. If I use a DataModel with
this
I'm assuming I'll need to get a handle to the DataModel from my
CarAction.java... but the DataModel was set up in CarsListAction.
--
Rick
--
Rick
Re: Concerning DataModel usage plus overhead?
fairly high system volume. Then, of course, we're going
to blame it on user error. Oh, those ops people, they're so clueless.
You know?
Rant over. Sorry for cluttering up mailboxes!
-Kevin
CONNER, BRENDAN (SBCSI) wrote:
Hmm. Sorry I wasn't much help.
That reminds me, though. On a related topic, I do know that there's a
glaring bug in O'Reilly. Specifically, in the code for example 10-1 (p.
176), it lists:
public DataModel getReportsModel() {
if (reportsModel == null) {
reportsModel = new ListDataModel();
}
reportsModel.setWrappedData(getReports()); // wrong
return reportsModel;
}
In case anyone in the discussion group is using this example, please
note that the above should be changed to:
public DataModel getReportsModel() {
if (reportsModel == null) {
reportsModel = new ListDataModel();
reportsModel.setWrappedData(getReports()); // this
should be inside the if statement
}
return reportsModel;
}
In case anyone else is trying out the O'Reilly example, that bug can
cause no end of frustration.
- Brendan
-Original Message-
From: Kevin Galligan [mailto:[EMAIL PROTECTED]
Sent: Monday, August 29, 2005 4:25 PM
To: MyFaces Discussion
Subject: Re: Concerning DataModel usage plus overhead?
There's no stumbling block. I'm saying that if you're trying to
implement the classic model of getting a view of entries from a
database table, or a similar data store, you can easily run into
trouble. Performance trouble, feature trouble, or actual bug trouble.
My obvious example is the O'Reilly book. Unaltered, I was able to make
it do flakey selections. Click on a row, but get a different detail
to show up.
By the way, regardless of whether one is using JSF, the data from
queries become stale the minute one's transaction has ended.
True. However, if you use the classic model, if you click on an entry
and link-by-id, even though the total list has changed, you'll still get
the detail for the particular row you've clicked on. Yes? Even if the
detail data has been altered, you still get the correct row. This is
not true with the pattern I'm talking about (and can publicly be seen in
the O'Reilly book example). Its not *that* bad in this example because
you're just selecting something, but its still bad.
I guess that's my point. I proposed a simple pattern in my post on
java ranch and I still haven't really found a solution in JSF that makes
a lot of sense to me, or somebody to give me the preferred way to
implement it. That's my stumbling block.
I'm really looking for somebody to say, oh yeah, you want to do x or
your assumptions are wrong and it doesn't have the performance issue
you're talking about. Most of the replies I get feel like they're
working around the implementation. 'DataModel links by index, so you
should keep the list in session and only refresh when the user
explicitly asks for it'. Stuff like that. Ok, but that's not how I
think it should work, and in the classic pattern, it doesn't work like
that.
To be clear, using the ext dataTable does solve the consistency problem,
but at the cost of pushing around a lot of data unnecessarily. At least
that's how it looks to me. The tough part is that nobody seems to agree
with me, and I don't understand why. If I had to pinpoint a stumbling
block, that would really, really be it. I feel like I'm missing a point
here. Not how to get it to work, but why we'd want to create and learn
a new framework, and have to then jump through hoops to implement
something that's pretty simple and common.
I'm really just waiting for the post that I read and then say, Oh,
right, now I got it.
Thanks again.
CONNER, BRENDAN (SBCSI) wrote:
OK, I misunderstood the problem you're talking about. So, yes, the
state-saving method is immaterial. The state-saving method can be
material if a user has more than one window open within a session, in
my
experience.
Well, it's definitely true that DataModel is a local snapshot of
what
one queried at a point in time. Yes, it can become stale.
Typically, your table would contain a list of keys, and, once the user
has clicked on one of the entries, you would ask the DataModel for the
appropriate rowIndex that was selected, and then, at that rowIndex,
you
would get the key for that row, go to the database for the detail, and
then return success, at which point the detail for that key is
displayed, or the detail and the summary are both displayed, or
whatever.
If you want to redisplay a refreshed version of the summary as well as
the detail, you'd query the database for that as well.
I guess I'd have to have more information to see where the stumbling
block is. Maybe I'm not having any issues with it because I'm using
t:saveState.
- Brendan
-Original Message-
From: Kevin Galligan [mailto:[EMAIL PROTECTED]
Sent: Monday, August 29, 2005
RE: Concerning DataModel usage plus overhead?
Sorry, not much time to converse today. Just to point out that, when
using the example in O'Reilly last November for our own application, I
encountered a problem, and I banged my head against the wall for a few
days, and I even logged a PMR with IBM, thinking it was a bug in their
code. IBM responded by pointing out that the setWrappedData() line
should be inside the if statement, and, when we made that change, our
code worked. I haven't looked at it much since then, though, since we
haven't really encountered any more errors in our application (that
we've found, anyway!). I just wrote a note in my book so I don't repeat
that error.
- Brendan
-Original Message-
From: Kevin Galligan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 30, 2005 11:41 AM
To: MyFaces Discussion
Subject: Re: Concerning DataModel usage plus overhead?
I'm not so sure that's a bug. Please take a look at the code again.
I think it gets at the root of my problem. In order for that to be a
bug, 'getSortedReportsModel' is also a bug.
public DataModel getSortedReportsModel() {
if (reportsModel == null) {
reportsModel = new ListDataModel();
}
List reports = getReports();
sortReports(reports);
reportsModel.setWrappedData(reports);
return reportsModel;
}
Has to be changed to...
public DataModel getSortedReportsModel() {
if (reportsModel == null) {
reportsModel = new ListDataModel();
List reports = getReports();
sortReports(reports);
reportsModel.setWrappedData(reports);
}
return reportsModel;
}
Once you do that, however, the sorting links stop working, so we change
it to something like...
public DataModel getSortedReportsModel() {
//This is a little shady, but we're just calling the function
to do the initialization
reportsModel = getReportsModel();
List reports = (List) reportsModel.getWrappedData();
sortReports(reports);
return reportsModel;
}
Ok, so now the report list works, and you can sort it. Great. So,
somebody adds a report. How do you see it? Browser refresh? No.
Click sort? Doesn't show. Click the actual refresh button? Nope. The
refresh button just returns Refresh, which will simply reshow the
page. Now we have to go in, code a function to dump and refresh the
DataModel, or at least the wrapped data.
*Note* The screen I'm talking about is Chapter 10 Report List
Area, stage 3 (Example 10-3).
My point is that I understand this enough to figure out how to make it
work, but I feel like I'm working around the implementation. There are
several places in here where one can get into trouble. I would consider
myself an advanced web application developer. I'd be afraid to see what
somebody who didn't know too much about the medium does with this model.
Especially if they are trying to point and click their way through it.
That's what I'm concerned with.
Now, I also have the JSF In Action book. This morning I came in and
planned on getting the Project Track example up and running to further
illustrate my point. However, that thing is absolutely filled with
bugs. For example, on the inbox, sort the table. Then click an entry.
It grabs the entry by index, but on the *unsorted* table. You don't
even need to break that table with external data entry. It'll break
itself.
I mean, I'm not trying to knock JSF or anybody that is trying to help me
with an answer. I guess I'm trying to point out something that I think
could be very error prone if in the wrong hands, and that might be
implemented better. I'd certainly like to find an implementation that
was a little better. Better being a subjective opinion.
The extended data table in myfaces allows for the forceIdIndexFormula,
which will link by id value, which will keep things consistent with
these examples. Even the bug above will work fine with
forceIdIndexFormula specified. Back to my original post, however, as
compared with the classic link-by-id pattern, the
'forceIdIndexFormula' does significantly more work than it needs to. By
that I mean I assume its going to the database to pull back all rows
again, then scanning through each to find the id value selected.
I'll leave this alone for now. I'm fixating. I guess I still don't
understand why nobody else seems to have this issue. As a real world
example, the way I found this was working on the webapp for jboss's jbpm
component. It uses jsf, which is why I started learning jsf. This
problem is in several key places in that app. By way of example, the
task list. The application is a workflow processor. I'd assume that
correct tasklist functionality is important. The task page just shows a
list of tasks. Hitting refresh should show you the current list of
tasks, which it does. The problem is that if a new task is added after
Re: Concerning DataModel usage plus overhead?
My brain is very struts centric as well. There's some things I like about the JSF model too though. Thats why I'm probably landing somewhere in between. I generally avoided session scoping anything that didn't need to be, which I guess is my big reservation with JSF. I know exactly what you mean with the lazy list in the form. You do have some extra effort involved, like building the property string on the input objects and tracking the id's in a hidden input component, but there's not as much going on behind the curtain either. I think that's enough for today though... Rick Reumann wrote: On 8/30/05, Kevin Galligan [EMAIL PROTECTED] wrote: I think updating several rows at the same time, which might require local copies of the data, and just linking are two different things. They might need two different components. With Struts this was a piece of cake. Your ActionForm has a bean property that is a List of the objects you want to update (Helps if it's a LazyList if not using session scope), and when your form submits BeanUtils (in the background) simply copies your form objects to the List in the Action form. Super simple imo. The only slightly tricky part is validation, but I always provide a manual validation method in my Action classes so this was easy to handle.
Concerning DataModel usage plus overhead?
I haven't really used the DataModel class yet, but as described by Brendan in another thread, I have a couple of questions about the concepts behind it... First a simple example... Want to display on a page a list of employees. User should be able to click on employee and brought to an edit page to edit the employee. My question in a previous thread was how to best accomplish this. I figured a simple link passing in an ID would make the most sense, but it seems like there was recommendations to use a dataModel. But say my initial ist was... Fred John Billy Questions: 1) I want to click on one of those names and edit the user. This initial collection of employees shouldn't contain the full employee info - its just name and ID. It's way too much overhead to pull back the full employee information at this stage, so all I have as a name and an ID. 2) Why would I want to really save the state of this tableData in this case using t:saveState since I really don't care about this list anymore once the name is clicked. I'm going to be brought to a totally new editEmployee screen and no longer need this collection around. When I want the updated list I should get it from the backend again. Please someone help me understand how to best accomplish what I want to do. It seems like such an easy concept but yet I haven't seen a good explanation or an example (granted I don't have the O'Reilly book, from what seems to be described I'm not certain that example will be what I want either). Thanks so much. -- Rick
RE: Concerning DataModel usage plus overhead?
Title: Message In answer to your second question, I believe you need t:saveState so JSF will rebuild the table in its component tree upon submitting the request, so you can access the values present in the previous request. - Brendan -Original Message-From: Rick Reumann [mailto:[EMAIL PROTECTED] Sent: Monday, August 29, 2005 9:22 AMTo: MyFaces DiscussionSubject: Concerning DataModel usage plus overhead?I haven't really used the DataModel class yet, but as described by Brendan in another thread, I have a couple of questions about the concepts behind it...First a simple example...Want to display on a page a list of employees. User should be able to click on employee and brought to an edit page to edit the employee.My question in a previous thread was how to best accomplish this. I figured a simple link passing in an ID would make the most sense, but it seems like there was recommendations to use a dataModel. But say my initial ist was...FredJohnBillyQuestions:1) I want to click on one of those names and edit the user. This initial collection of employees shouldn't contain the full employee info - its just name and ID. It's way too much overhead to pull back the full employee information at this stage, so all I have as a name and an ID.2) Why would I want to really save the state of this tableData in this case using t:saveState since I really don't care about this list anymore once the name is clicked. I'm going to be brought to a totally new editEmployee screen and no longer need this collection around. When I want the updated list I should get it from the backend again.Please someone help me understand how to best accomplish what I want to do. It seems like such an easy concept but yet I haven't seen a good explanation or an example (granted I don't have the O'Reilly book, from what seems to be described I'm not certain that example will be what I want either).Thanks so much.-- Rick
Re: Concerning DataModel usage plus overhead?
I've been having some similar questions about datatable usage and general web patterns, specifically walking a database and linking to detail pages with id values. The detail of my questions are in my big post to javaranch... http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topicf=82t=000422 I worked with the O'Reilly book example, and that's where I originally came up with my issue. If you use the standard dataTable, you have to keep your values in session between the time you show the list and when they click on the value. If you get the values from the db each time, you open the possibility that the index will have changed, and the selected value will be incorrect. If you keep the values in session, its keeping a lot of data around, and you need to explicitly code a refresh. I was pointed to the ext dataTable and the forceId (something something) attribute, which allows you to specify and id. This does solve the problem of inconsistancy. However, when the user submits, I assume you have to get the full list and then scan for the selected value. Yes? I'll look into the t:saveState, as I haven't looked at that yet. Anyway, I was also looking for some input as to a suggested way of handling this. In the above post, I outline how I've classically handled this type of issue. I'm hoping to find some insight into the best way to do that with JSF. Thanks in advance, -Kevin CONNER, BRENDAN (SBCSI) wrote: In answer to your second question, I believe you need t:saveState so JSF will rebuild the table in its component tree upon submitting the request, so you can access the values present in the previous request. - Brendan -Original Message- *From:* Rick Reumann [mailto:[EMAIL PROTECTED] *Sent:* Monday, August 29, 2005 9:22 AM *To:* MyFaces Discussion *Subject:* Concerning DataModel usage plus overhead? I haven't really used the DataModel class yet, but as described by Brendan in another thread, I have a couple of questions about the concepts behind it... First a simple example... Want to display on a page a list of employees. User should be able to click on employee and brought to an edit page to edit the employee. My question in a previous thread was how to best accomplish this. I figured a simple link passing in an ID would make the most sense, but it seems like there was recommendations to use a dataModel. But say my initial ist was... Fred John Billy Questions: 1) I want to click on one of those names and edit the user. This initial collection of employees shouldn't contain the full employee info - its just name and ID. It's way too much overhead to pull back the full employee information at this stage, so all I have as a name and an ID. 2) Why would I want to really save the state of this tableData in this case using t:saveState since I really don't care about this list anymore once the name is clicked. I'm going to be brought to a totally new editEmployee screen and no longer need this collection around. When I want the updated list I should get it from the backend again. Please someone help me understand how to best accomplish what I want to do. It seems like such an easy concept but yet I haven't seen a good explanation or an example (granted I don't have the O'Reilly book, from what seems to be described I'm not certain that example will be what I want either). Thanks so much. -- Rick
Re: Concerning DataModel usage plus overhead?
On 8/29/05, Kevin Galligan [EMAIL PROTECTED] wrote: If you use the standard dataTable, you have tokeep your values in session between the time you show the list and whenthey click on the value.If you get the values from the db each time,you open the possibility that the index will have changed, and the selected value will be incorrect.If you keep the values in session,its keeping a lot of data around, and you need to explicitly code a refresh. To me the above is just really goofy. Unless, there are security constraints to me it makes sense to get the item you want back based on some key. Maybe for example you are looking at a list of care models on a page, then you want to see the details of the car. It makes most sense to me to click on the car model passing the id of the model you want, you look up the model and you pass it back. When you need the list of cars back, get a fresh set from the backend. If you need caching, cache at the persistence layer. I don't see the advantage of saving the state of a DataModel, but I'm new to all of this, so maybe I'll see the light at some point. -- Rick
RE: Concerning DataModel usage plus overhead?
Title: Message Yes, you could do your own parameter passing. It's just that JSF offers the DataModel abstraction such that, whenthe userclicks on your link, your program just has to askDataModel for rowIndex to locate the row that was selected. It's designed to simplify your coding. In the applications I've worked on, we very rarely have to explicitly pass request parameters. Pretty much everything is in the bean. - Brendan -Original Message-From: Rick Reumann [mailto:[EMAIL PROTECTED] Sent: Monday, August 29, 2005 2:09 PMTo: MyFaces DiscussionSubject: Re: Concerning DataModel usage plus overhead?On 8/29/05, Kevin Galligan [EMAIL PROTECTED] wrote: If you use the standard dataTable, you have tokeep your values in session between the time you show the list and whenthey click on the value.If you get the values from the db each time,you open the possibility that the index will have changed, and the selected value will be incorrect.If you keep the values in session,its keeping a lot of data around, and you need to explicitly code a refresh. To me the above is just really goofy. Unless, there are security constraints to me it makes sense to get the item you want back based on some key. Maybe for example you are looking at a list of care models on a page, then you want to see the details of the car. It makes most sense to me to click on the car model passing the id of the model you want, you look up the model and you pass it back. When you need the list of cars back, get a fresh set from the backend. If you need caching, cache at the persistence layer.I don't see the advantage of saving the state of a DataModel, but I'm new to all of this, so maybe I'll see the light at some point.-- Rick
Re: Concerning DataModel usage plus overhead?
On 8/29/05, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote:
Yes,
you could do your own parameter passing. It's just that JSF offers the
DataModel abstraction such that, whenthe userclicks on your link,
your program just has to askDataModel for rowIndex to locate the row that
was selected. It's designed to simplify your coding.
Where should I look for a good of this? Also does it work when you need
access to the DataModel from a different backing bean that created the
DataModel? For example...
h:dataTable var=emp value=#{employees.employees} !--
employees is a backing bean that will generate a DataModel of
'employees' --
Now I want a link in on row that will call employee.edit that will go
to Employee.java backing bean and enter the 'edit' method where I can
pull out the 'id' that is is found in the bean for the current row of
my DataModel. How do I get a handle to this DataModel from a totally
different backing bean then the one that created the DataModel?
thanks for the help
-- Rick
RE: Concerning DataModel usage plus overhead?
Title: Message
You
set up employee to have a managed reference toemployees. Then, once
control reaches Employee.edit(),its reference to employees will have been
set up already by JSF.
-
Brendan
-Original Message-From: Rick Reumann
[mailto:[EMAIL PROTECTED] Sent: Monday, August 29, 2005 2:33
PMTo: MyFaces DiscussionSubject: Re: Concerning
DataModel usage plus overhead?On 8/29/05, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote:
Yes, you could do your own
parameter passing. It's just that JSF offers the DataModel abstraction
such that, whenthe userclicks on your link, your program just
has to askDataModel for rowIndex to locate the row that was
selected. It's designed to simplify your
coding.
Where should I look for a good of this? Also does it work when you
need access to the DataModel from a different backing bean that created the
DataModel? For example... h:dataTable var="emp"
value="#{employees.employees}" !-- employees is a backing bean that
will generate a DataModel of 'employees' --Now I want a link in on
row that will call "employee.edit" that will go to "Employee.java" backing
bean and enter the 'edit' method where I can pull out the 'id' that is is
found in the bean for the current row of my DataModel. How do I get a handle
to this DataModel from a totally different backing bean then the one that
created the DataModel?thanks for the help--
Rick
Re: Concerning DataModel usage plus overhead?
I tried to send this, and I think it failed. Anyway... Rick, To me the above is just really goofy. Unless, there are security constraints to me it makes sense to get the item you want back based on some key. You and I are on the same page. I'm not sure I'd so far as goofy, but I think for particular domains, the DataModel pattern isn't really the way to go. Brendan It's just that JSF offers the DataModel abstraction such that, when the user clicks on your link, your program just has to ask DataModel for rowIndex to locate the row that was selected. *It's designed to simplify your coding.* If you look through the post I pasted in my message, I had a fairly serious problem with the DataModel. I was using it to show a list of entries from a database. When the user visits the page, it grabs the list from the database and displays it. I was able to take the example from the O'Reilly book and break it. How? Basically... 1) Get the list of entries on one browser screen 2) Open a different browser and add an entry 3) Go back to the original browser and click an entry If you do it in the magic order, you'll wind up selecting a different row than you clicked on. This is because the DataModel uses a numerical index instead of a internally meaningful id value. If you use the extended dataTable and the forceIdIndexFormula, you can index by an id value, but its still doing some strange dynamics. I'm guessing, but I think when the user clicks, the system would have to get the full list again, scan through it, and then select the value you want. Its self-consistant in that it'll select the correct entry, and maybe its conceptually simpler, but at the expense of significant processing and data access. In the post I asked if anybody used more of a hybrid approach. Do your lists with classic link-by-id design, grab the singular value, and pass to a jsf page. I also had some thoughts on implementing this directly in JSF, but in a way that avoided double data grabs or link-by-index designs. Ok, back to my reguarl day job... (thanks in advance, again) CONNER, BRENDAN (SBCSI) wrote: Yes, you could do your own parameter passing. It's just that JSF offers the DataModel abstraction such that, when the user clicks on your link, your program just has to ask DataModel for rowIndex to locate the row that was selected. It's designed to simplify your coding. In the applications I've worked on, we very rarely have to explicitly pass request parameters. Pretty much everything is in the bean. - Brendan -Original Message- *From:* Rick Reumann [mailto:[EMAIL PROTECTED] *Sent:* Monday, August 29, 2005 2:09 PM *To:* MyFaces Discussion *Subject:* Re: Concerning DataModel usage plus overhead? On 8/29/05, *Kevin Galligan* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: If you use the standard dataTable, you have to keep your values in session between the time you show the list and when they click on the value. If you get the values from the db each time, you open the possibility that the index will have changed, and the selected value will be incorrect. If you keep the values in session, its keeping a lot of data around, and you need to explicitly code a refresh. To me the above is just really goofy. Unless, there are security constraints to me it makes sense to get the item you want back based on some key. Maybe for example you are looking at a list of care models on a page, then you want to see the details of the car. It makes most sense to me to click on the car model passing the id of the model you want, you look up the model and you pass it back. When you need the list of cars back, get a fresh set from the backend. If you need caching, cache at the persistence layer. I don't see the advantage of saving the state of a DataModel, but I'm new to all of this, so maybe I'll see the light at some point. -- Rick
Re: Concerning DataModel usage plus overhead?
On 8/29/05, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote: You set up employee to have a managed reference toemployees. Then, once control reaches Employee.edit(),its reference to employees will have been set up already by JSF. But employee has its managed bean reference to employee (EmployeeAction.java). The edit is a method in EmployeeAction.java not in EmployeesAction.java (EmployeesAction is the one that generated the initial DataModel).. Are you saying 'employee' can have a managed reference to both EmployeesAction AND EmployeeAction? I didn't know you could have a single reference with more than one backing bean associate to it? -- Rick
RE: Concerning DataModel usage plus overhead?
Out of curiosity, are you setting javax.faces.STATE_SAVING_METHOD to client in your web.xml? If not, can you try doing that and seeing if you observe the same behavior? - Brendan -Original Message- From: Kevin Galligan [mailto:[EMAIL PROTECTED] Sent: Monday, August 29, 2005 2:50 PM To: users@myfaces.apache.org Subject: Re: Concerning DataModel usage plus overhead? I tried to send this, and I think it failed. Anyway... Rick, To me the above is just really goofy. Unless, there are security constraints to me it makes sense to get the item you want back based on some key. You and I are on the same page. I'm not sure I'd so far as goofy, but I think for particular domains, the DataModel pattern isn't really the way to go. Brendan It's just that JSF offers the DataModel abstraction such that, when the user clicks on your link, your program just has to ask DataModel for rowIndex to locate the row that was selected. *It's designed to simplify your coding.* If you look through the post I pasted in my message, I had a fairly serious problem with the DataModel. I was using it to show a list of entries from a database. When the user visits the page, it grabs the list from the database and displays it. I was able to take the example from the O'Reilly book and break it. How? Basically... 1) Get the list of entries on one browser screen 2) Open a different browser and add an entry 3) Go back to the original browser and click an entry If you do it in the magic order, you'll wind up selecting a different row than you clicked on. This is because the DataModel uses a numerical index instead of a internally meaningful id value. If you use the extended dataTable and the forceIdIndexFormula, you can index by an id value, but its still doing some strange dynamics. I'm guessing, but I think when the user clicks, the system would have to get the full list again, scan through it, and then select the value you want. Its self-consistant in that it'll select the correct entry, and maybe its conceptually simpler, but at the expense of significant processing and data access. In the post I asked if anybody used more of a hybrid approach. Do your lists with classic link-by-id design, grab the singular value, and pass to a jsf page. I also had some thoughts on implementing this directly in JSF, but in a way that avoided double data grabs or link-by-index designs. Ok, back to my reguarl day job... (thanks in advance, again) CONNER, BRENDAN (SBCSI) wrote: Yes, you could do your own parameter passing. It's just that JSF offers the DataModel abstraction such that, when the user clicks on your link, your program just has to ask DataModel for rowIndex to locate the row that was selected. It's designed to simplify your coding. In the applications I've worked on, we very rarely have to explicitly pass request parameters. Pretty much everything is in the bean. - Brendan -Original Message- *From:* Rick Reumann [mailto:[EMAIL PROTECTED] *Sent:* Monday, August 29, 2005 2:09 PM *To:* MyFaces Discussion *Subject:* Re: Concerning DataModel usage plus overhead? On 8/29/05, *Kevin Galligan* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: If you use the standard dataTable, you have to keep your values in session between the time you show the list and when they click on the value. If you get the values from the db each time, you open the possibility that the index will have changed, and the selected value will be incorrect. If you keep the values in session, its keeping a lot of data around, and you need to explicitly code a refresh. To me the above is just really goofy. Unless, there are security constraints to me it makes sense to get the item you want back based on some key. Maybe for example you are looking at a list of care models on a page, then you want to see the details of the car. It makes most sense to me to click on the car model passing the id of the model you want, you look up the model and you pass it back. When you need the list of cars back, get a fresh set from the backend. If you need caching, cache at the persistence layer. I don't see the advantage of saving the state of a DataModel, but I'm new to all of this, so maybe I'll see the light at some point. -- Rick
RE: Concerning DataModel usage plus overhead?
Title: Message I probably just got confused by your naming convention. Can you repeat your question with clearer names? - Brendan -Original Message-From: Rick Reumann [mailto:[EMAIL PROTECTED] Sent: Monday, August 29, 2005 2:50 PMTo: MyFaces DiscussionSubject: Re: Concerning DataModel usage plus overhead?On 8/29/05, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote: You set up employee to have a managed reference toemployees. Then, once control reaches Employee.edit(),its reference to employees will have been set up already by JSF. But employee has its managed bean reference to "employee" (EmployeeAction.java). The "edit" is a method in EmployeeAction.java not in EmployeesAction.java (EmployeesAction is the one that generated the initial DataModel).. Are you saying 'employee' can have a managed reference to both "EmployeesAction" AND "EmployeeAction"? I didn't know you could have a single reference with more than one backing bean associate to it?-- Rick
Re: Concerning DataModel usage plus overhead?
Hmm. I could, but I'd bet it would be no different. I don't think that takes care of the fundamental problem, which is as follows... *** Get list of entries *** Date Name Id Index 8/22/05 First Entry 10 8/22/05 Second Entry 21 8/24/05 Third Entry 32 8/25/05 Fourth Entry 43 That's what you see on your page (the Index column would really be links to a detail page, not an index number. However, to the system, its an index number). While you're looking at that, somebody else adds the following... Date Name Id 8/20/05 Older Entry 5 Lets say you then click on entry number 2, Second Entry, in your list. To the system you clicked on index number '1'. It will get the list of entries, and the entry at index '1' will be selected. Since an entry was added while you were looking at the page, when you get to the detail page you'll actually see First Entry. I don't think saving state on the client has anything to do with this. Its still select-by-index instead of by id. This is the first issue I had with the DataModel pattern. You can avoid this by keeping the entries in the session. However, every time you go to the list page you'll see stale data. You'd need to code an explicit function and link to dump and refresh the data (and make sure your users are aware that they are looking at stale data). The extended dataTable takes care of this with *forceIdIndexFormula*, but then you still have the issue that every time you click on a link, the system does a full data grab. Worse yet, it then has to scan through each to find the particular id (*** I may be wrong about that. If I am, somebody please tell me. This is part of the reason why I'm posting ***). CONNER, BRENDAN (SBCSI) wrote: Out of curiosity, are you setting javax.faces.STATE_SAVING_METHOD to client in your web.xml? If not, can you try doing that and seeing if you observe the same behavior? - Brendan -Original Message- From: Kevin Galligan [mailto:[EMAIL PROTECTED] Sent: Monday, August 29, 2005 2:50 PM To: users@myfaces.apache.org Subject: Re: Concerning DataModel usage plus overhead? I tried to send this, and I think it failed. Anyway... Rick, To me the above is just really goofy. Unless, there are security constraints to me it makes sense to get the item you want back based on some key. You and I are on the same page. I'm not sure I'd so far as goofy, but I think for particular domains, the DataModel pattern isn't really the way to go. Brendan It's just that JSF offers the DataModel abstraction such that, when the user clicks on your link, your program just has to ask DataModel for rowIndex to locate the row that was selected. *It's designed to simplify your coding.* If you look through the post I pasted in my message, I had a fairly serious problem with the DataModel. I was using it to show a list of entries from a database. When the user visits the page, it grabs the list from the database and displays it. I was able to take the example from the O'Reilly book and break it. How? Basically... 1) Get the list of entries on one browser screen 2) Open a different browser and add an entry 3) Go back to the original browser and click an entry If you do it in the magic order, you'll wind up selecting a different row than you clicked on. This is because the DataModel uses a numerical index instead of a internally meaningful id value. If you use the extended dataTable and the forceIdIndexFormula, you can index by an id value, but its still doing some strange dynamics. I'm guessing, but I think when the user clicks, the system would have to get the full list again, scan through it, and then select the value you want. Its self-consistant in that it'll select the correct entry, and maybe its conceptually simpler, but at the expense of significant processing and data access. In the post I asked if anybody used more of a hybrid approach. Do your lists with classic link-by-id design, grab the singular value, and pass to a jsf page. I also had some thoughts on implementing this directly in JSF, but in a way that avoided double data grabs or link-by-index designs. Ok, back to my reguarl day job... (thanks in advance, again) CONNER, BRENDAN (SBCSI) wrote: Yes, you could do your own parameter passing. It's just that JSF offers the DataModel abstraction such that, when the user clicks on your link, your program just has to ask DataModel for rowIndex to locate the row that was selected. It's designed to simplify your coding. In the applications I've worked on, we very rarely have to explicitly pass request parameters. Pretty much everything is in the bean. - Brendan -Original Message- *From:* Rick Reumann [mailto:[EMAIL PROTECTED] *Sent:* Monday, August 29, 2005 2:09 PM *To:* MyFaces Discussion *Subject:* Re: Concerning DataModel usage plus overhead? On 8/29/05, *Kevin Galligan* [EMAIL
Re: Concerning DataModel usage plus overhead?
On 8/29/05, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote:
I probably just got confused by your naming convention. Can you repeat your
question with clearer names?
Sure. Let me change the names and concepts..
First page you come to is a list of cars on cars.jsp. Cars is
populated as DataModel from CarsListAction.java There is a managed
bean reference for the name cars to CarsListAction.java.
CarsListAction has a method getCars which returns this DataModel. On
cars.jsp you have...
h:dataTable var=car value=#{carsListAction.cars}
Another managed bean: CarAction.java has CRUD methods. In this case
getCar which is supposed to get a Car back from the backend based
on 'carID.
I want to be able to click on car from the list on cars.jsp and hit
the getCar' method in my CarAction.java bean and forward to a
carForm.jsp that lets me edit the car. If I use a DataModel with this
I'm assuming I'll need to get a handle to the DataModel from my
CarAction.java... but the DataModel was set up in CarsListAction.
RE: Concerning DataModel usage plus overhead?
OK, I misunderstood the problem you're talking about. So, yes, the state-saving method is immaterial. The state-saving method can be material if a user has more than one window open within a session, in my experience. Well, it's definitely true that DataModel is a local snapshot of what one queried at a point in time. Yes, it can become stale. Typically, your table would contain a list of keys, and, once the user has clicked on one of the entries, you would ask the DataModel for the appropriate rowIndex that was selected, and then, at that rowIndex, you would get the key for that row, go to the database for the detail, and then return success, at which point the detail for that key is displayed, or the detail and the summary are both displayed, or whatever. If you want to redisplay a refreshed version of the summary as well as the detail, you'd query the database for that as well. I guess I'd have to have more information to see where the stumbling block is. Maybe I'm not having any issues with it because I'm using t:saveState. - Brendan -Original Message- From: Kevin Galligan [mailto:[EMAIL PROTECTED] Sent: Monday, August 29, 2005 3:23 PM To: MyFaces Discussion Subject: Re: Concerning DataModel usage plus overhead? Hmm. I could, but I'd bet it would be no different. I don't think that takes care of the fundamental problem, which is as follows... *** Get list of entries *** Date Name Id Index 8/22/05 First Entry 10 8/22/05 Second Entry 21 8/24/05 Third Entry 32 8/25/05 Fourth Entry 43 That's what you see on your page (the Index column would really be links to a detail page, not an index number. However, to the system, its an index number). While you're looking at that, somebody else adds the following... Date Name Id 8/20/05 Older Entry 5 Lets say you then click on entry number 2, Second Entry, in your list. To the system you clicked on index number '1'. It will get the list of entries, and the entry at index '1' will be selected. Since an entry was added while you were looking at the page, when you get to the detail page you'll actually see First Entry. I don't think saving state on the client has anything to do with this. Its still select-by-index instead of by id. This is the first issue I had with the DataModel pattern. You can avoid this by keeping the entries in the session. However, every time you go to the list page you'll see stale data. You'd need to code an explicit function and link to dump and refresh the data (and make sure your users are aware that they are looking at stale data). The extended dataTable takes care of this with *forceIdIndexFormula*, but then you still have the issue that every time you click on a link, the system does a full data grab. Worse yet, it then has to scan through each to find the particular id (*** I may be wrong about that. If I am, somebody please tell me. This is part of the reason why I'm posting ***). CONNER, BRENDAN (SBCSI) wrote: Out of curiosity, are you setting javax.faces.STATE_SAVING_METHOD to client in your web.xml? If not, can you try doing that and seeing if you observe the same behavior? - Brendan -Original Message- From: Kevin Galligan [mailto:[EMAIL PROTECTED] Sent: Monday, August 29, 2005 2:50 PM To: users@myfaces.apache.org Subject: Re: Concerning DataModel usage plus overhead? I tried to send this, and I think it failed. Anyway... Rick, To me the above is just really goofy. Unless, there are security constraints to me it makes sense to get the item you want back based on some key. You and I are on the same page. I'm not sure I'd so far as goofy, but I think for particular domains, the DataModel pattern isn't really the way to go. Brendan It's just that JSF offers the DataModel abstraction such that, when the user clicks on your link, your program just has to ask DataModel for rowIndex to locate the row that was selected. *It's designed to simplify your coding.* If you look through the post I pasted in my message, I had a fairly serious problem with the DataModel. I was using it to show a list of entries from a database. When the user visits the page, it grabs the list from the database and displays it. I was able to take the example from the O'Reilly book and break it. How? Basically... 1) Get the list of entries on one browser screen 2) Open a different browser and add an entry 3) Go back to the original browser and click an entry If you do it in the magic order, you'll wind up selecting a different row than you clicked on. This is because the DataModel uses a numerical index instead of a internally meaningful id value. If you use the extended dataTable and the forceIdIndexFormula, you can index by an id value, but its still doing some strange dynamics. I'm guessing, but I think when the user clicks, the system would have to get the full list
RE: Concerning DataModel usage plus overhead?
Can you send a snippet of your faces-config.xml showing your managed
bean definitions and your navigations, just to make sure I have the
picture right?
- Brendan
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Monday, August 29, 2005 3:24 PM
To: MyFaces Discussion
Subject: Re: Concerning DataModel usage plus overhead?
On 8/29/05, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote:
I probably just got confused by your naming convention. Can you
repeat your
question with clearer names?
Sure. Let me change the names and concepts..
First page you come to is a list of cars on cars.jsp. Cars is
populated as DataModel from CarsListAction.java There is a managed
bean reference for the name cars to CarsListAction.java.
CarsListAction has a method getCars which returns this DataModel. On
cars.jsp you have...
h:dataTable var=car value=#{carsListAction.cars}
Another managed bean: CarAction.java has CRUD methods. In this case
getCar which is supposed to get a Car back from the backend based
on 'carID.
I want to be able to click on car from the list on cars.jsp and hit
the getCar' method in my CarAction.java bean and forward to a
carForm.jsp that lets me edit the car. If I use a DataModel with this
I'm assuming I'll need to get a handle to the DataModel from my
CarAction.java... but the DataModel was set up in CarsListAction.
RE: Concerning DataModel usage plus overhead?
By the way, regardless of whether one is using JSF, the data from queries become stale the minute one's transaction has ended. - Brendan -Original Message- From: CONNER, BRENDAN (SBCSI) Sent: Monday, August 29, 2005 3:52 PM To: 'MyFaces Discussion' Subject: RE: Concerning DataModel usage plus overhead? OK, I misunderstood the problem you're talking about. So, yes, the state-saving method is immaterial. The state-saving method can be material if a user has more than one window open within a session, in my experience. Well, it's definitely true that DataModel is a local snapshot of what one queried at a point in time. Yes, it can become stale. Typically, your table would contain a list of keys, and, once the user has clicked on one of the entries, you would ask the DataModel for the appropriate rowIndex that was selected, and then, at that rowIndex, you would get the key for that row, go to the database for the detail, and then return success, at which point the detail for that key is displayed, or the detail and the summary are both displayed, or whatever. If you want to redisplay a refreshed version of the summary as well as the detail, you'd query the database for that as well. I guess I'd have to have more information to see where the stumbling block is. Maybe I'm not having any issues with it because I'm using t:saveState. - Brendan -Original Message- From: Kevin Galligan [mailto:[EMAIL PROTECTED] Sent: Monday, August 29, 2005 3:23 PM To: MyFaces Discussion Subject: Re: Concerning DataModel usage plus overhead? Hmm. I could, but I'd bet it would be no different. I don't think that takes care of the fundamental problem, which is as follows... *** Get list of entries *** Date Name Id Index 8/22/05 First Entry 10 8/22/05 Second Entry 21 8/24/05 Third Entry 32 8/25/05 Fourth Entry 43 That's what you see on your page (the Index column would really be links to a detail page, not an index number. However, to the system, its an index number). While you're looking at that, somebody else adds the following... Date Name Id 8/20/05 Older Entry 5 Lets say you then click on entry number 2, Second Entry, in your list. To the system you clicked on index number '1'. It will get the list of entries, and the entry at index '1' will be selected. Since an entry was added while you were looking at the page, when you get to the detail page you'll actually see First Entry. I don't think saving state on the client has anything to do with this. Its still select-by-index instead of by id. This is the first issue I had with the DataModel pattern. You can avoid this by keeping the entries in the session. However, every time you go to the list page you'll see stale data. You'd need to code an explicit function and link to dump and refresh the data (and make sure your users are aware that they are looking at stale data). The extended dataTable takes care of this with *forceIdIndexFormula*, but then you still have the issue that every time you click on a link, the system does a full data grab. Worse yet, it then has to scan through each to find the particular id (*** I may be wrong about that. If I am, somebody please tell me. This is part of the reason why I'm posting ***). CONNER, BRENDAN (SBCSI) wrote: Out of curiosity, are you setting javax.faces.STATE_SAVING_METHOD to client in your web.xml? If not, can you try doing that and seeing if you observe the same behavior? - Brendan -Original Message- From: Kevin Galligan [mailto:[EMAIL PROTECTED] Sent: Monday, August 29, 2005 2:50 PM To: users@myfaces.apache.org Subject: Re: Concerning DataModel usage plus overhead? I tried to send this, and I think it failed. Anyway... Rick, To me the above is just really goofy. Unless, there are security constraints to me it makes sense to get the item you want back based on some key. You and I are on the same page. I'm not sure I'd so far as goofy, but I think for particular domains, the DataModel pattern isn't really the way to go. Brendan It's just that JSF offers the DataModel abstraction such that, when the user clicks on your link, your program just has to ask DataModel for rowIndex to locate the row that was selected. *It's designed to simplify your coding.* If you look through the post I pasted in my message, I had a fairly serious problem with the DataModel. I was using it to show a list of entries from a database. When the user visits the page, it grabs the list from the database and displays it. I was able to take the example from the O'Reilly book and break it. How? Basically... 1) Get the list of entries on one browser screen 2) Open a different browser and add an entry 3) Go back to the original browser and click an entry If you do it in the magic order, you'll wind up selecting a different row than you clicked on. This is because
Re: Concerning DataModel usage plus overhead?
Actually, the MyFaces master/detail example source code is shedding
some light on some things. Rather than me waste more of your valuable
time, let me fart around with that code and see if I can tweak mine to
use a similar concept. Thanks for your help and patience so far.
On 8/29/05, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote:
Can you send a snippet of your faces-config.xml showing your managed
bean definitions and your navigations, just to make sure I have the
picture right?
- Brendan
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Monday, August 29, 2005 3:24 PM
To: MyFaces Discussion
Subject: Re: Concerning DataModel usage plus overhead?
On 8/29/05, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote:
I probably just got confused by your naming convention. Can you
repeat your
question with clearer names?
Sure. Let me change the names and concepts..
First page you come to is a list of cars on cars.jsp. Cars is
populated as DataModel from CarsListAction.java There is a managed
bean reference for the name cars to CarsListAction.java.
CarsListAction has a method getCars which returns this DataModel. On
cars.jsp you have...
h:dataTable var=car value=#{carsListAction.cars}
Another managed bean: CarAction.java has CRUD methods. In this case
getCar which is supposed to get a Car back from the backend based
on 'carID.
I want to be able to click on car from the list on cars.jsp and hit
the getCar' method in my CarAction.java bean and forward to a
carForm.jsp that lets me edit the car. If I use a DataModel with this
I'm assuming I'll need to get a handle to the DataModel from my
CarAction.java... but the DataModel was set up in CarsListAction.
--
Rick
RE: Concerning DataModel usage plus overhead?
Note that I've defined the beans to be request scope, with the
expectation that your JSP will have t:saveState
value=#{carListBean}/
- Brendan
-Original Message-
From: CONNER, BRENDAN (SBCSI)
Sent: Monday, August 29, 2005 4:21 PM
To: 'MyFaces Discussion'
Subject: RE: Concerning DataModel usage plus overhead?
Sounds good. Judging from what I understand about your e-mail, I'd
define something like:
managed-bean
managed-bean-namecarListBean/managed-bean-name
managed-bean-classcom.mycompany.CarListBean/managed-bean-class
managed-bean-scoperequest/managed-bean-scope
/managed-bean
managed-bean
managed-bean-namecarAction/managed-bean-name
managed-bean-classcom.mycompany.CarAction/managed-bean-class
managed-bean-scoperequest/managed-bean-scope
managed-property
property-namecarListBean/property-name
value#{carListBean}/value
/managed-property
/managed-bean
(I'm calling your data bean carListBean, rather than carListAction, just
for my own clarity.)
Then, as you point out, you'd have a dataTable entry like
h:dataTable value=#{carListBean.carModel} var=car
h:column
h:commandLink action={carAction.getCar}
...
h:commandLink
h:column
...
/h:dataTable
Then, in your getCar() method, you'd have something like:
public String getCar() {
Car selectedCar = (Car)
getCarListBean().getCarModel().getRowData();
...
}
Hope that helps.
- Brendan
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Monday, August 29, 2005 4:02 PM
To: MyFaces Discussion
Subject: Re: Concerning DataModel usage plus overhead?
Actually, the MyFaces master/detail example source code is shedding
some light on some things. Rather than me waste more of your valuable
time, let me fart around with that code and see if I can tweak mine to
use a similar concept. Thanks for your help and patience so far.
On 8/29/05, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote:
Can you send a snippet of your faces-config.xml showing your managed
bean definitions and your navigations, just to make sure I have the
picture right?
- Brendan
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Monday, August 29, 2005 3:24 PM
To: MyFaces Discussion
Subject: Re: Concerning DataModel usage plus overhead?
On 8/29/05, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote:
I probably just got confused by your naming convention. Can you
repeat your
question with clearer names?
Sure. Let me change the names and concepts..
First page you come to is a list of cars on cars.jsp. Cars is
populated as DataModel from CarsListAction.java There is a managed
bean reference for the name cars to CarsListAction.java.
CarsListAction has a method getCars which returns this DataModel. On
cars.jsp you have...
h:dataTable var=car value=#{carsListAction.cars}
Another managed bean: CarAction.java has CRUD methods. In this case
getCar which is supposed to get a Car back from the backend based
on 'carID.
I want to be able to click on car from the list on cars.jsp and hit
the getCar' method in my CarAction.java bean and forward to a
carForm.jsp that lets me edit the car. If I use a DataModel with this
I'm assuming I'll need to get a handle to the DataModel from my
CarAction.java... but the DataModel was set up in CarsListAction.
--
Rick
Re: Concerning DataModel usage plus overhead?
There's no stumbling block. I'm saying that if you're trying to implement the classic model of getting a view of entries from a database table, or a similar data store, you can easily run into trouble. Performance trouble, feature trouble, or actual bug trouble. My obvious example is the O'Reilly book. Unaltered, I was able to make it do flakey selections. Click on a row, but get a different detail to show up. By the way, regardless of whether one is using JSF, the data from queries become stale the minute one's transaction has ended. True. However, if you use the classic model, if you click on an entry and link-by-id, even though the total list has changed, you'll still get the detail for the particular row you've clicked on. Yes? Even if the detail data has been altered, you still get the correct row. This is not true with the pattern I'm talking about (and can publicly be seen in the O'Reilly book example). Its not *that* bad in this example because you're just selecting something, but its still bad. I guess that's my point. I proposed a simple pattern in my post on java ranch and I still haven't really found a solution in JSF that makes a lot of sense to me, or somebody to give me the preferred way to implement it. That's my stumbling block. I'm really looking for somebody to say, oh yeah, you want to do x or your assumptions are wrong and it doesn't have the performance issue you're talking about. Most of the replies I get feel like they're working around the implementation. 'DataModel links by index, so you should keep the list in session and only refresh when the user explicitly asks for it'. Stuff like that. Ok, but that's not how I think it should work, and in the classic pattern, it doesn't work like that. To be clear, using the ext dataTable does solve the consistency problem, but at the cost of pushing around a lot of data unnecessarily. At least that's how it looks to me. The tough part is that nobody seems to agree with me, and I don't understand why. If I had to pinpoint a stumbling block, that would really, really be it. I feel like I'm missing a point here. Not how to get it to work, but why we'd want to create and learn a new framework, and have to then jump through hoops to implement something that's pretty simple and common. I'm really just waiting for the post that I read and then say, Oh, right, now I got it. Thanks again. CONNER, BRENDAN (SBCSI) wrote: OK, I misunderstood the problem you're talking about. So, yes, the state-saving method is immaterial. The state-saving method can be material if a user has more than one window open within a session, in my experience. Well, it's definitely true that DataModel is a local snapshot of what one queried at a point in time. Yes, it can become stale. Typically, your table would contain a list of keys, and, once the user has clicked on one of the entries, you would ask the DataModel for the appropriate rowIndex that was selected, and then, at that rowIndex, you would get the key for that row, go to the database for the detail, and then return success, at which point the detail for that key is displayed, or the detail and the summary are both displayed, or whatever. If you want to redisplay a refreshed version of the summary as well as the detail, you'd query the database for that as well. I guess I'd have to have more information to see where the stumbling block is. Maybe I'm not having any issues with it because I'm using t:saveState. - Brendan -Original Message- From: Kevin Galligan [mailto:[EMAIL PROTECTED] Sent: Monday, August 29, 2005 3:23 PM To: MyFaces Discussion Subject: Re: Concerning DataModel usage plus overhead? Hmm. I could, but I'd bet it would be no different. I don't think that takes care of the fundamental problem, which is as follows... *** Get list of entries *** Date Name Id Index 8/22/05 First Entry 10 8/22/05 Second Entry 21 8/24/05 Third Entry 32 8/25/05 Fourth Entry 43 That's what you see on your page (the Index column would really be links to a detail page, not an index number. However, to the system, its an index number). While you're looking at that, somebody else adds the following... Date Name Id 8/20/05 Older Entry 5 Lets say you then click on entry number 2, Second Entry, in your list. To the system you clicked on index number '1'. It will get the list of entries, and the entry at index '1' will be selected. Since an entry was added while you were looking at the page, when you get to the detail page you'll actually see First Entry. I don't think saving state on the client has anything to do with this. Its still select-by-index instead of by id. This is the first issue I had with the DataModel pattern. You can avoid this by keeping the entries in the session. However, every time you go to the list page you'll see stale data. You'd
RE: Concerning DataModel usage plus overhead?
Hmm. Sorry I wasn't much help.
That reminds me, though. On a related topic, I do know that there's a
glaring bug in O'Reilly. Specifically, in the code for example 10-1 (p.
176), it lists:
public DataModel getReportsModel() {
if (reportsModel == null) {
reportsModel = new ListDataModel();
}
reportsModel.setWrappedData(getReports()); // wrong
return reportsModel;
}
In case anyone in the discussion group is using this example, please
note that the above should be changed to:
public DataModel getReportsModel() {
if (reportsModel == null) {
reportsModel = new ListDataModel();
reportsModel.setWrappedData(getReports()); // this
should be inside the if statement
}
return reportsModel;
}
In case anyone else is trying out the O'Reilly example, that bug can
cause no end of frustration.
- Brendan
-Original Message-
From: Kevin Galligan [mailto:[EMAIL PROTECTED]
Sent: Monday, August 29, 2005 4:25 PM
To: MyFaces Discussion
Subject: Re: Concerning DataModel usage plus overhead?
There's no stumbling block. I'm saying that if you're trying to
implement the classic model of getting a view of entries from a
database table, or a similar data store, you can easily run into
trouble. Performance trouble, feature trouble, or actual bug trouble.
My obvious example is the O'Reilly book. Unaltered, I was able to make
it do flakey selections. Click on a row, but get a different detail
to show up.
By the way, regardless of whether one is using JSF, the data from
queries become stale the minute one's transaction has ended.
True. However, if you use the classic model, if you click on an entry
and link-by-id, even though the total list has changed, you'll still get
the detail for the particular row you've clicked on. Yes? Even if the
detail data has been altered, you still get the correct row. This is
not true with the pattern I'm talking about (and can publicly be seen in
the O'Reilly book example). Its not *that* bad in this example because
you're just selecting something, but its still bad.
I guess that's my point. I proposed a simple pattern in my post on
java ranch and I still haven't really found a solution in JSF that makes
a lot of sense to me, or somebody to give me the preferred way to
implement it. That's my stumbling block.
I'm really looking for somebody to say, oh yeah, you want to do x or
your assumptions are wrong and it doesn't have the performance issue
you're talking about. Most of the replies I get feel like they're
working around the implementation. 'DataModel links by index, so you
should keep the list in session and only refresh when the user
explicitly asks for it'. Stuff like that. Ok, but that's not how I
think it should work, and in the classic pattern, it doesn't work like
that.
To be clear, using the ext dataTable does solve the consistency problem,
but at the cost of pushing around a lot of data unnecessarily. At least
that's how it looks to me. The tough part is that nobody seems to agree
with me, and I don't understand why. If I had to pinpoint a stumbling
block, that would really, really be it. I feel like I'm missing a point
here. Not how to get it to work, but why we'd want to create and learn
a new framework, and have to then jump through hoops to implement
something that's pretty simple and common.
I'm really just waiting for the post that I read and then say, Oh,
right, now I got it.
Thanks again.
CONNER, BRENDAN (SBCSI) wrote:
OK, I misunderstood the problem you're talking about. So, yes, the
state-saving method is immaterial. The state-saving method can be
material if a user has more than one window open within a session, in
my
experience.
Well, it's definitely true that DataModel is a local snapshot of
what
one queried at a point in time. Yes, it can become stale.
Typically, your table would contain a list of keys, and, once the user
has clicked on one of the entries, you would ask the DataModel for the
appropriate rowIndex that was selected, and then, at that rowIndex,
you
would get the key for that row, go to the database for the detail, and
then return success, at which point the detail for that key is
displayed, or the detail and the summary are both displayed, or
whatever.
If you want to redisplay a refreshed version of the summary as well as
the detail, you'd query the database for that as well.
I guess I'd have to have more information to see where the stumbling
block is. Maybe I'm not having any issues with it because I'm using
t:saveState.
- Brendan
-Original Message-
From: Kevin Galligan [mailto:[EMAIL PROTECTED]
Sent: Monday, August 29, 2005 3:23 PM
To: MyFaces Discussion
Subject: Re: Concerning DataModel usage plus overhead?
Hmm. I could, but I'd bet it would be no different. I don't think
that
takes care of the fundamental problem, which
Re: Concerning DataModel usage plus overhead?
Rick, To me the above is just really goofy. Unless, there are security constraints to me it makes sense to get the item you want back based on some key. You and I are on the same page. I'm not sure I'd so far as goofy, but I think for particular domains, the DataModel pattern isn't really the way to go. Brendan It's just that JSF offers the DataModel abstraction such that, when the user clicks on your link, your program just has to ask DataModel for rowIndex to locate the row that was selected. *It's designed to simplify your coding.* If you look through the post I pasted in my message, I had a fairly serious problem with the DataModel. I was using it to show a list of entries from a database. When the user visits the page, it grabs the list from the database and displays it. I was able to take the example from the O'Reilly book and break it. How? Basically... 1) Get the list of entries on one browser screen 2) Open a different browser and add an entry 3) Go back to the original browser and click an entry If you do it in the magic order, you'll wind up selecting a different row than you clicked on. This is because the DataModel uses a numerical index instead of a internally meaningful id value. If you use the extended dataTable and the forceIdIndexFormula, you can index by an id value, but its still doing some strange dynamics. I'm guessing, but I think when the user clicks, the system would have to get the full list again, scan through it, and then select the value you want. Its self-consistant in that it'll select the correct entry, and maybe its conceptually simpler, but at the expense of significant processing and data access. In the post I asked if anybody used more of a hybrid approach. Do your lists with classic link-by-id design, grab the singular value, and pass to a jsf page. I also had some thoughts on implementing this directly in JSF, but in a way that avoided double data grabs or link-by-index designs. Ok, back to my reguarl day job... (thanks in advance, again) CONNER, BRENDAN (SBCSI) wrote: Yes, you could do your own parameter passing. It's just that JSF offers the DataModel abstraction such that, when the user clicks on your link, your program just has to ask DataModel for rowIndex to locate the row that was selected. It's designed to simplify your coding. In the applications I've worked on, we very rarely have to explicitly pass request parameters. Pretty much everything is in the bean. - Brendan -Original Message- *From:* Rick Reumann [mailto:[EMAIL PROTECTED] *Sent:* Monday, August 29, 2005 2:09 PM *To:* MyFaces Discussion *Subject:* Re: Concerning DataModel usage plus overhead? On 8/29/05, *Kevin Galligan* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: If you use the standard dataTable, you have to keep your values in session between the time you show the list and when they click on the value. If you get the values from the db each time, you open the possibility that the index will have changed, and the selected value will be incorrect. If you keep the values in session, its keeping a lot of data around, and you need to explicitly code a refresh. To me the above is just really goofy. Unless, there are security constraints to me it makes sense to get the item you want back based on some key. Maybe for example you are looking at a list of care models on a page, then you want to see the details of the car. It makes most sense to me to click on the car model passing the id of the model you want, you look up the model and you pass it back. When you need the list of cars back, get a fresh set from the backend. If you need caching, cache at the persistence layer. I don't see the advantage of saving the state of a DataModel, but I'm new to all of this, so maybe I'll see the light at some point. -- Rick
Re: Concerning DataModel usage plus overhead?
Thanks Brendan! This below looks wonderful. At home now and no time to
try it, but will tomorrow from work.
By the way, does the O'Reilly book present something like the below?
This is the exact kind of example that I think would be very useful to
see in a mini-demo-app.
On 8/29/05, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote:
Sounds good. Judging from what I understand about your e-mail, I'd
define something like:
managed-bean
managed-bean-namecarListBean/managed-bean-name
managed-bean-classcom.mycompany.CarListBean/managed-bean-class
managed-bean-scoperequest/managed-bean-scope
/managed-bean
managed-bean
managed-bean-namecarAction/managed-bean-name
managed-bean-classcom.mycompany.CarAction/managed-bean-class
managed-bean-scoperequest/managed-bean-scope
managed-property
property-namecarListBean/property-name
value#{carListBean}/value
/managed-property
/managed-bean
(I'm calling your data bean carListBean, rather than carListAction, just
for my own clarity.)
Then, as you point out, you'd have a dataTable entry like
h:dataTable value=#{carListBean.carModel} var=car
h:column
h:commandLink action={carAction.getCar}
...
h:commandLink
h:column
...
/h:dataTable
Then, in your getCar() method, you'd have something like:
public String getCar() {
Car selectedCar = (Car)
getCarListBean().getCarModel().getRowData();
...
}
Hope that helps.
- Brendan
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Monday, August 29, 2005 4:02 PM
To: MyFaces Discussion
Subject: Re: Concerning DataModel usage plus overhead?
Actually, the MyFaces master/detail example source code is shedding
some light on some things. Rather than me waste more of your valuable
time, let me fart around with that code and see if I can tweak mine to
use a similar concept. Thanks for your help and patience so far.
On 8/29/05, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote:
Can you send a snippet of your faces-config.xml showing your managed
bean definitions and your navigations, just to make sure I have the
picture right?
- Brendan
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Monday, August 29, 2005 3:24 PM
To: MyFaces Discussion
Subject: Re: Concerning DataModel usage plus overhead?
On 8/29/05, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote:
I probably just got confused by your naming convention. Can you
repeat your
question with clearer names?
Sure. Let me change the names and concepts..
First page you come to is a list of cars on cars.jsp. Cars is
populated as DataModel from CarsListAction.java There is a managed
bean reference for the name cars to CarsListAction.java.
CarsListAction has a method getCars which returns this DataModel. On
cars.jsp you have...
h:dataTable var=car value=#{carsListAction.cars}
Another managed bean: CarAction.java has CRUD methods. In this case
getCar which is supposed to get a Car back from the backend based
on 'carID.
I want to be able to click on car from the list on cars.jsp and hit
the getCar' method in my CarAction.java bean and forward to a
carForm.jsp that lets me edit the car. If I use a DataModel with this
I'm assuming I'll need to get a handle to the DataModel from my
CarAction.java... but the DataModel was set up in CarsListAction.
--
Rick
--
Rick
