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
you've retrieved the page, but before you've clicked on a task, you will
see the wrong task in the details page. Your options are as follows:
1) Keep the current list in session and provide an explicit "Refresh"
button.
2) Use the extended datatable with forceIdIndexFormula
#1 is bad because hitting the refresh button on the browser doesn't
work, and I don't think its too much to expect it to. You also have to
keep the list around in memory just to support the framework
#2 is bad because of the above mentioned performance issues. The
functionality, however, does work as expected and would probably be the
preferred way to go
A more general issue with #2, however, is that you'd need special
knowledge to know option #2 even existed, and why it should be used.
That particular bug is of the worst kind because you wouldn't see it
unless you had 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 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
