Issue Details (XML | Word | Printable)

Key: JAVASERVERFACES_SPEC_PUBLIC-479
Type: Sub-task Sub-task
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Ed Burns
Reporter: pmuir
Votes: 21
Watchers: 6
Operations

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

UIData should support the collection interface rather than the List interface

Created: 02/Oct/08 05:33 AM   Updated: 27/Dec/13 02:36 PM   Resolved: 31/Jan/12 06:19 PM
Component/s: Components/Renderers
Affects Version/s: 1.2
Fix Version/s: 2.2

Time Tracking:
Original Estimate: Not Specified
Remaining Estimate: 3 days, 23 hours, 30 minutes
Time Spent - 1 hour, 16 minutes Remaining Estimate - 3 days, 23 hours, 30 minutes
Time Spent: 1 hour, 16 minutes
Time Spent - 1 hour, 16 minutes Remaining Estimate - 3 days, 23 hours, 30 minutes

File Attachments: 1. Text File i_spec_479-20120130-1614.patch (26 kB) 30/Jan/12 09:47 PM - Ed Burns

Environment:

Operating System: All
Platform: All

Issue Links:
Dependency
 
Related
 

Issuezilla Id: 479
Status Whiteboard:

cat2 javadoc size_medium importance_large draft

Tags:
Participants: arjan tijms, bohl_-., Darious3, Ed Burns, fastroller, mojavelinux, pmuir, Raj and rogerk


 Description  « Hide

The root of the Java collections class structure is java.util.Collection, yet
this interface is not supported in the UIData family of components. Instead,
developers are forced to use a List or wrap their collection in a custom
DataModel implementation (which is what Seam does). The impedance mismatch is
introduced by the fact that java.util.Set is likely the most common association
mapping in ORM. Since the UIData model and ORM go hand-in-hand, there should be
support for java.util.Set (and preferably java.util.Collection) in UIData.
Granted, only a java.util.List can be accessed by index, which is why it would
be acceptable to wrap any other collection in a List implementation internally.
Basically, the developer should not have to care that they are creating a data
table from a Set vs a List. This is an area where the JSF abstract just bleeds.



Ed Burns added a comment - 30/Jan/09 06:54 AM

>>>>> On Fri, 30 Jan 2009 00:28:16 +0000, Pete Muir <pmuir@REDHAT.COM> said:

PM> Currently UIData and UIRepeat only support List, not Collection (sets).
PM> This is an issue since the interface java.util.Set is extremely
PM> prevalent in JPA entity classes, and was raised by Adam a while back:

PM> http://sfjsf.blogspot.com/2006/03/usings-sets-with-uidata.html

PM> But what about the point that a Collection is not indexed by
PM> definition? That is a concern of the developer feeding the collection
PM> into the UIData or UIRepeat. Maybe the developer doesn't care that
PM> each time it iterates, the order is different. Maybe the developer is
PM> using an ordered but not indexed collection such as a LinkedHashSet or
PM> a TreeSet. The point is, UIData and UIRepeat should be able to iterate
PM> a basic java.util.Collection.

You bring a good point, and I'm delighted for your offer to contribute
the work, but this is better left to 2.1. Such a change is certainly
permissible in a maintenance release, and we can do those rather
easily.

Ed


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

Prepare to delete api 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.


mojavelinux added a comment - 18/Dec/09 01:41 PM

Update milestone to 2.0 Rev a and specify subcomponent.

We really need to resolve this issue. It is embarrassing.


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

cat2


Ed Burns added a comment - 22/Mar/10 11:30 AM

javadoc


Ed Burns added a comment - 15/May/10 07:54 AM

These are targeted at 2.1.


rogerk added a comment - 17/Jun/10 08:13 PM

triage


Ed Burns added a comment - 24/Jun/10 02:41 PM

GlassFish 3.1 M6 at the latest.


Ed Burns added a comment - 24/Jun/10 02:55 PM

Move these to M5


Ed Burns added a comment - 30/Aug/10 12:11 PM

Move these to 2.2


arjan tijms added a comment - 14/May/11 07:32 AM

I wonder if the scope of this issue could be extended to also include java.util.Map.

I've found iterating over this structure not at all to be uncommon. JSTL supported it directly, but in JSF with UIData based components we have to jump through some hoops.

Currently I'm mostly using a helper method that I map to an EL function, like this:

public static List<Map.Entry<?, ?>> mapToList(Map<?, ?> map) {

if (map == null) { return null; }

List<Map.Entry<?, ?>> list = new ArrayList<Map.Entry<?,?>>();
list.addAll(map.entrySet());

return list;
}

This will intuitively expose a "key" and "value" property on the iteration variable. However, for many developers it's not clear they have to use a helper function like this and a great deal of wasted time and frustration results.

Supporting Maps directly would greatly simply matters.


Ed Burns added a comment - 26/Jul/11 05:01 PM

snapshot


Ed Burns added a comment - 30/Jan/12 09:47 PM

snapshot.


Ed Burns added a comment - 31/Jan/12 06:19 PM

Sending jsf-api/src/main/java/javax/faces/component/UIData.java
Adding jsf-api/src/main/java/javax/faces/model/CollectionDataModel.java
Sending jsf-api/src/main/java/javax/faces/model/package.html
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/build.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/i_spec_479_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/i_spec_479_war/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/i_spec_479_war/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/i_spec_479_war/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/i_spec_479_war/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/i_spec_479_war/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/i_spec_479_war/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/i_spec_479_war/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/i_spec_479_war/src/main/java/com/sun/faces/i_spec_479_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/i_spec_479_war/src/main/java/com/sun/faces/i_spec_479_war/UserBean.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/i_spec_479_war/src/main/java/com/sun/faces/i_spec_479_war/UserManager.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/i_spec_479_war/src/main/resources
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/i_spec_479_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/i_spec_479_war/src/main/webapp/Issue479UsingPage.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/i_spec_479_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/i_spec_479_war/src/main/webapp/WEB-INF/beans.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-479/i_spec_479_war/src/main/webapp/WEB-INF/web.xml
Sending jsf-test/build.xml
Transmitting file data ...........
Committed revision 9621.


fastroller added a comment - 14/Apr/12 09:40 AM

I see that this issue is fixed for UIData, but the same fix needs to be applied to UIRepeat in facelets.

It would be good if the API spec could be changed to include a factory for creating the DataModel. This would stop repeated code, but also allow third party components to generate a DataModel. E.g. Richfaces has a rich:list component that outputs an html ul (sadly missing from the standard library) but it does not support Sets. If it used a DataModel factory it would now work with Sets.


Raj added a comment - 05/May/12 12:56 PM

This issue has been marked as resolved but, what about the fix for UIRepeat ? Is there a separate issue for that ?


bohl_-. added a comment - 25/Oct/12 05:45 AM

Sorry to wake this old thread, but what about Iterable? Google's fantastic guava library is based on Iterable, not Collection. When using guava in JSF beans you still have to wrap each Iterable with ImmutableList#copyOf. Should a seperate task be created for that?


Ed Burns added a comment - 25/Oct/12 03:32 PM

Sorry to wake this old thread, but what about Iterable? Google's fantastic guava library is based on Iterable, not Collection. When using guava in JSF beans you still have to wrap each Iterable with ImmutableList#copyOf. Should a seperate task be created for that?

Yes, please, and it will not make JSF 2.2.

This issue has been marked as resolved but, what about the fix for UIRepeat ? Is there a separate issue for that ?

Please file an issue, and it will not make JSF 2.2.


Darious3 added a comment - 26/Oct/12 09:27 PM

Please file an issue

What about using JAVASERVERFACES_SPEC_PUBLIC-1103 for this?

and it will not make JSF 2.2.

At this point I don't think anyone assumes that any new suggestions will still make it in JSF 2.2, but what about making some public announcement about this? I.e. that new suggestions are still welcome, but will be considered for JSF 2.3 at the earliest.