Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

UIData should support the collection interface rather than the List interface #479

Closed
eclipse-faces-bot opened this issue Oct 2, 2008 · 28 comments
Closed

UIData should support the collection interface rather than the List interface #479

eclipse-faces-bot opened this issue Oct 2, 2008 · 28 comments
Labels
Component: Components/Renderers Priority: Major Type: Sub-task
Milestone
2.2

Comments

@eclipse-faces-bot
Copy link

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.

Environment

Operating System: All
Platform: All

Affected Versions

[1.2]
@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
Reported by pmuir

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
Parent-Task: JAVASERVERFACES_SPEC_PUBLIC-935

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
Issue-Links:
blocks
JAVASERVERFACES_SPEC_PUBLIC-440
JAVASERVERFACES_SPEC_PUBLIC-1019
JAVASERVERFACES-2318
is related to
JAVASERVERFACES-3125

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:

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

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
Prepare to delete api subcomponent

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
mojavelinux said:
Update milestone to 2.0 Rev a and specify subcomponent.

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

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
cat2

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
javadoc

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
These are targeted at 2.1.

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
rogerk said:
triage

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
GlassFish 3.1 M6 at the latest.

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
Move these to M5

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
Move these to 2.2

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@arjantijms said:
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.

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
snapshot

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
snapshot.

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
File: i_spec_479-20120130-1614.patch
Attached By: @edburns

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
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/#479
Adding jsf-test/#479/build.xml
Adding jsf-test/#479/i_spec_479_war
Adding jsf-test/#479/i_spec_479_war/pom.xml
Adding jsf-test/#479/i_spec_479_war/src
Adding jsf-test/#479/i_spec_479_war/src/main
Adding jsf-test/#479/i_spec_479_war/src/main/java
Adding jsf-test/#479/i_spec_479_war/src/main/java/com
Adding jsf-test/#479/i_spec_479_war/src/main/java/com/sun
Adding jsf-test/#479/i_spec_479_war/src/main/java/com/sun/faces
Adding jsf-test/#479/i_spec_479_war/src/main/java/com/sun/faces/i_spec_479_war
Adding jsf-test/#479/i_spec_479_war/src/main/java/com/sun/faces/i_spec_479_war/UserBean.java
Adding jsf-test/#479/i_spec_479_war/src/main/java/com/sun/faces/i_spec_479_war/UserManager.java
Adding jsf-test/#479/i_spec_479_war/src/main/resources
Adding jsf-test/#479/i_spec_479_war/src/main/webapp
Adding jsf-test/#479/i_spec_479_war/src/main/webapp/Issue479UsingPage.xhtml
Adding jsf-test/#479/i_spec_479_war/src/main/webapp/WEB-INF
Adding jsf-test/#479/i_spec_479_war/src/main/webapp/WEB-INF/beans.xml
Adding jsf-test/#479/i_spec_479_war/src/main/webapp/WEB-INF/web.xml
Sending jsf-test/build.xml
Transmitting file data ...........
Committed revision 9621.

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
Marked as fixed on Tuesday, January 31st 2012, 10:19:15 am

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
fastroller said:
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.

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
rajkumar.w93 said:
This issue has been marked as resolved but, what about the fix for UIRepeat ? Is there a separate issue for that ?

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
bohl_-. said:
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?

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:

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.

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
darious3 said:

Please file an issue

What about using #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.

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@manfredriem said:
Closing resolved issue out

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
This issue was imported from java.net JIRA JAVASERVERFACES_SPEC_PUBLIC-479

@eclipse-faces-bot
Copy link
Author

@eclipse-faces-bot eclipse-faces-bot added this to the 2.2 milestone Aug 6, 2019
@eclipse-faces-bot eclipse-faces-bot mentioned this issue Aug 6, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Component: Components/Renderers Priority: Major Type: Sub-task
Projects
None yet
Milestone
2.2
Development

No branches or pull requests
1 participant
@eclipse-faces-bot