jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: [jsr372-experts mirror] ui:repeat

From: manfred riem <manfred.riem_at_oracle.com>
Date: Thu, 14 Jan 2016 09:29:17 -0600

Hi all,

Any proposal for changes needs to take into account the behavior that
ui:repeat has had for
a long time, whether that is explicitly mentioned in the specification
or not. As otherwise
you would break existing applications.

This proposal looks like it does not break anything, but obviously it
actually needs to be
tested to see if it works. So please continue and deliver a fix/patch
that is/can be tested.

Thanks!

Kind regards,
Manfred Riem

On 1/13/16, 3:10 PM, arjan tijms wrote:
> Hi,
>
> On Wed, Jan 13, 2016 at 5:53 PM, Cagatay Civici
> <cagatay.civici_at_primetek.com.tr
> <mailto:cagatay.civici_at_primetek.com.tr>> wrote:
>
> Following is from Mojarra that is used by UIData and UIRepeat;
>
> private Boolean isNestedWithinIterator() {
> if (isNested == null) {
> UIComponent parent = this;
> while (null != (parent = parent.getParent())) {
> if (parent instanceof UIData ||
> parent.getClass().getName().endsWith("UIRepeat")) {
> isNested = Boolean.TRUE;
> break;
> }
> }
> ...
>
> [...]
> In terms of Spec, an interface like Repeater should solve it where
> we at PF can implement as well for our components.
>
>
> We have had comparable issues with that same fragment. I like the
> Repeater proposal. If we just let it be a marker interface and then
> have both UIData and UIRepeat implement it, then the check can become:
>
> if (parent instanceof Repeater ||
> parent.getClass().getName().endsWith("UIRepeat")) {
> isNested = Boolean.TRUE;
> break;
> }
>
> It still has the class name check, but I think that's a small price
> for the sake of backwards compatibility.
>
> This would be a relatively small change, in terms of coding effort
> trivial almost. Cagatay, would the above change fully fix the issue
> for you?
>
> Parallel to this, does anyone think it's a good idea to investigate if
> it's necessary/useful to introduce a new iterating (base) component? I
> took a few looks at the existing code of UIData for some of the above
> issues and I fear that fixing those while at the same time being 100%
> backwards compatible is undoable.
>
> Kind regards,
> Arjan Tijms
>
>
>
> On Wednesday 13 January 2016 at 16:27, arjan tijms wrote:
>> Hi,
>>
>> Interesting, indeed. There's quite an amount of issues in the
>> spec tracker that concern ui:repeat and the related h:dataTable.
>> I planned to do a JSF 2.3 wishlist part II, but never came around
>> to doing that.
>>
>> See:
>>
>> * https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-236
>> * UIData needs review on a couple of fronts
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-935
>> * Alignment/extending of iterating ui components
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-963
>> * Provide a component for iterating over hierarchical data
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-965
>> * ui:repeat requires document "begin" and "end" properties
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-892
>> * add "maxRepeats" attribute to ui:repeat.
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1249
>> * Add a styleClass attribute to h:column
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-217
>> * Inconsistent column styles handling with h:dataTable
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-627
>> * ui:repeat varStatus incompletely specified
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-609
>> * Add rowStatePreserved property to UIRepeat, exactly the same
>> as UIData
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1263
>> * UIData (and related classes) doesn't respect contract for
>> UIComponent process
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1120
>> * UIRepeat supports Collection
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1103
>> * Add support for condition check like regular for-loop in
>> ui:repeat
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1102
>> * Have DataModel implementations registerable
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1078
>> * h:datatable component to handle multiple entities lists
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-713
>> * UIRepeat et al are not specified
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-704
>> * Ajax inside a DataTable (getClientId append rowIndex)
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-865
>>
>> Perhaps some of the inconsistencies Cagatay found are related to
>> any of those?
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>> On Wed, Jan 13, 2016 at 3:15 PM, Kito Mann <kito.mann_at_virtua.com
>> <mailto:kito.mann_at_virtua.com>> wrote:
>>> Hello Cagatay,
>>>
>>> I noticed you just added a PrimeFaces repeat component
>>> <https://github.com/primefaces/primefaces/issues/999> citing
>>> "inconsistencies between ui:repeat implementations of mojarra
>>> and myfaces with our components". Is there something we need to
>>> do with the spec to ensure that the two implementations of
>>> ui:repeat behave more consistently?
>>> ___
>>>
>>> Kito D. Mann | @kito99 | Author, JSF in Action
>>> Web Components, Polymer, JSF, PrimeFaces, Java EE, and Liferay
>>> training and consulting
>>> Virtua, Inc. | virtua.tech <http://virtua.tech>
>>> JSFCentral.com <http://JSFCentral.com> | @jsfcentral
>>> +1 203-998-0403 <tel:%2B1%20203-998-0403>
>>>
>>> * Listen to the Enterprise Java Newscast: _http://
>>> <http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
>>> <http://ww.enterprisejavanews.com>_
>>>
>>
>
>