On 8/26/05, Enrique Medina <[EMAIL PROTECTED]> wrote:
> It would be great if you could copy all this to the Wiki ;-)
>
> http://wiki.apache.org/myfaces/
I'll take a look at it.
Yes, some issues have been already resolved - a few minutes after
sending this mail I've come across saveState component that works
*exactly* the same way as our component :-)
>
> 2005/8/26, mirek novak <[EMAIL PROTECTED]>:
> > 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.
> >
>
>
