Hi,
I've been working on an application based on MyFaces 1.0.8. Now, we
are moving to MyFaces 1.0.9 and I would like to discuss discovered
issues and some ideas (not only related to MyFaces but to JSF in
general).
AliasBean
========
* This is a pretty useful component and I'm glad that MyFaces contains it!
* There were a few bugs in this component in MyFaces 1.0.8
(processSaveState, queueEvent) but now they are fixed (1.0.9) - great
Table
====
* This is one of the most used components
* It's definitely better than standard table (sorting support,
scroller, …) BUT:
* Suppose this (selecting a row while model has been
concurrently modified by a different user):
1) Your table has 3 rows and you display a check box for each
row so that user can select a row
2) User selects first row and submits but another user has
concurrently deleted first row. So, model has now only 2 rows.
3) Submitted value (selected checkbox of the first row) will
be applied to the first row of the model. So, actually the second row
is selected :-(. (we've developed a quite simple solution, so if you
are interested, let me know - and we definitely do not serialize whole
model of the table!)
* It's a common case that table rows have checkboxes and can be
selected. So, we have to provide (for most of the tables) model where
each row is wrapped in an extra class that has "selected" property -
and that's tedious.
DataScroller
=========
* We've discovered following issue: uiData.setFirst(someNewValue)
is used within the =decode= method of the HtmlDataScrollerRenderer -
it is too early to modify uiData within =apply request values phase=.
* If some rows of the table were modified too, they will be
applied to wrong table rows :-( (because setFirst has already been
called and table contains different rows now)
* Our solution: DataScrollerRenderer fires an even that uiData
should be updated, and they are updated later in =update model values=
phase (just after model has been updated)
Backing Bean's State, HttpSession, Concurrent Access within a Session
===================================================
In my view, a reasonable web application should fulfill following requirements:
* users can use browser's navigation buttons (back, forward, reload)
* users can use an application from multiple browser tabs (tabs
share the same session)
Although these requirements look simple and unimportant, they present
serious problems and have serious consequences on the whole
architecture of an application.
* navigation buttons
* We use redirects. So, user can use the back button even when
he's moved to a next page via HTTP POST
* We use javax.faces.STATE_SAVING_METHOD=client. So, even if
user has pressed the back button 10 times, a proper view will be
restored when he submits form (or clicks link) on the old page (if
state saving=server, this would obviously not work - you would have to
"click twice" to perform an action :-)).
* But who/when/how will store state of backing beans? - note
that if you not store the state of your backing beans on a client,
your application will not work. Suppose this:
1) Your page displays a category (it has name, description
and sub-categories)
2) User selected category A and it is stored in a property
=currentCategory= in your backing bean
3) User selected category B (sub-category of A), so
=currentCategory= is now B
4) User uses browser's back button, so he can see detail of category A
5) User edits description of the category (A) and submits the page
6) Description of category B will be updated because
=currentCategory= is still B :-(
* Solution: a component (saveState) that accepts a value binding
and saves the "value" within its state. E.g. <y:saveState
value="#{myConroller.pageState}"/>
* tabbed browsing
* Any session scope backing bean is a potential race-condition
* Moreover, if your data like "currentItem", "MyPageConroller"
have session scope, actions performed in one tab may influence
behavior of the other tab
Error Handling
===========
* We created a special component similar to the Buffer component.
We render a sub-tree of this component into the buffer and if and
exception is thrown while processing the sub-tree, we render the
exception. (in addition, we had to wrap ActionListener,
HtmlDataTablePhaseListener, …).
* It would be nice to see an errorHandling component in next
MyFaces distribution.
I hope that you will find some info from this mail useful and intelligible.
Best regards,
MN.
