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 is as follows...
>
> *** Get list of entries ***
>
> Date Name Id Index
> 8/22/05 First Entry 1 0
> 8/22/05 Second Entry 2 1
> 8/24/05 Third Entry 3 2
> 8/25/05 Fourth Entry 4 3
>
> 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: [email protected]
>>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
>>
>>
>>
>
