Issue Details (XML | Word | Printable)

Key: JAVASERVERFACES_SPEC_PUBLIC-236
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Incomplete
Priority: Major Major
Assignee: javaserverfowner
Reporter: dmlloyd
Votes: 9
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
javaserverfaces-spec-public

UIData is Fundamentally Broken and Needs to Go Away

Created: 18/Jan/07 02:00 PM   Updated: 07/Jun/11 05:33 PM   Resolved: 04/Mar/10 12:41 PM
Component/s: Uncategorized
Affects Version/s: 2.0
Fix Version/s: None

Time Tracking:
Not Specified

Environment:

Operating System: All
Platform: All

Issue Links:
Dependency

Issuezilla Id: 236
Status Whiteboard:

EGTop5 effort_hard

Tags:
Participants: dmlloyd, Ed Burns, javaserverfowner, jhook and rogerk


 Description  « Hide

Weighing in at 1485 lines, with dozens of methods, UIData is a complex and
confusing behemoth of a component. It exhibits subtle problems in certain
conditions (see issue 153) relating to state management, because it maintains
child state in a manner inconsistent with all other components. UIData can also
be inefficient, in that it must save and restore child state many times during
rendering, decoding, etc.; this is to swap the current state of rows to trick
other JSF components into believing that multiple instances of its child
components exist.

It also represents the only viable way of implementing a component that contains
a variable number of instances of the tags it contains. The reason for this is
that the logic behind implementing this component is so complex that it is not
an effective use of time to duplicate it for most people, and there is no
alternative approach available within the JSF RI, which may lead people to
believe that this is the only approach possible.

I propose that this component be retired in favor of a new methodology for these
types of collection-oriented components. The new methodology would work as follows.

When a tag is encountered (JSP, or, in the case of Facelets, XML) that
corresponds to a dataTable (or any other such component), the handler for the
tag should construct a component for the tag, and a child component for every
active collection entry (that is, every member of the data model starting from
the first row, whose number may for example be overridden by the "first"
attribute of h:dataTable, through the last row, whose number may be overridden
using the "rows" attribute).

Each of these children will contain the complete component tree represented by
the tags that are nested within h:dataTable. The children themselves would be a
standard component type (say, UICollectionEntry), which would have a null
renderer type by default (so that rendering falls through to the children).

The UICollectionEntry components have special handling for IDs; each one has an
integer ID. getId() (and getClientId()) will return the string representation
of this ID; setId(String) becomes a no-op. A new getRowId()/setRowId(int)
method pair is introduced.

By making the collection component and each UICollectionEntry implement
NamingContainer, the ID nesting will work exactly as UIData's pretends to work
today - except that the collection entry components (rows in the dataTable case)
will be real. This means that no state saving magic is needed and no context
switching to select rows during rendering and other lifecycle phases. Problems
with state maintenance evaporate.

I have developed a Facelets implementation of this idea. My collection
component class (equivalent to UIData) is 174 lines long. The collection entry
component class is 140 lines. The Facelets tag handler for collection
components is 143 lines. And that's including a 19-line copyright notice and
additional comments for each file. All the code is simple and straightforward,
and more importantly can be easily leveraged by an entry-level component
developer. I do not yet have a JSP version, but I plan to develop one as soon
as soon as I can.

I am willing to work offline with someone to review the code and demonstrate the
idea. I think that this would be a good move for JSF 2.0... please consider
this change.



dmlloyd added a comment - 18/Jan/07 02:02 PM

Accidentally targeted for 1.2, meant to target for 2.0


jhook added a comment - 07/Feb/07 08:19 PM

I agree with you a bit-- the statesaving mess in the JSF spec has snowballed
into other implementation issues within classes such as UIData... can you post
it as an attachment to this issue?


dmlloyd added a comment - 09/Feb/07 06:31 AM

If you're referring to my implementation, I can't really but I can link you to
my component library project. You can just check it out from svn and build it
with the default ant target. The project is at:
http://labs.jboss.org/portal/gravel/?prjlist=false


rogerk added a comment - 22/Aug/08 08:46 AM

Status Whiteboard


Ed Burns added a comment - 12/Sep/08 04:39 PM

effort_hard


Ed Burns added a comment - 12/Sep/08 04:47 PM

change target_milestone to 2.0


Ed Burns added a comment - 17/Sep/08 02:56 PM

Depends on 322.


Ed Burns added a comment - 21/Oct/08 07:50 AM
      • Issue 440 has been marked as a duplicate of this issue. ***

Ed Burns added a comment - 28/Jul/09 12:33 PM

Pushing back to 2.1


Ed Burns added a comment - 24/Nov/09 07:48 AM

Prepare to delete "spec" subcomponent.


Ed Burns added a comment - 14/Dec/09 08:59 AM

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.


Ed Burns added a comment - 04/Mar/10 12:41 PM

We have another issue for UIData state saving. Closing this one.


kenaiadmin made changes - 25/Nov/10 06:42 PM
Field Original Value New Value
issue.field.bugzillaimportkey 236 19841
Ed Burns made changes - 07/Jun/11 05:33 PM
Fix Version/s unscheduled [ 10405 ]