It's a minimal thing to "mark" a component as being an iterating/repeating
component. One use for that is that if needed child components can take a
special action if they detect they're nested inside such component.
Tightening up the spec specifically for ui:repeat and h:dataTable is more
difficult. The problem I see (and please correct me if I'm wrong) is that
these are older components. These components may contain certain bugs and
those bugs in some cases may even be a spec violation, but these bugs have
been there for a long time.
At some point the bug, essentially, becomes a kind of de facto spec, since
there's older code depending on it. Fixing the bug means breaking the older
code, which means breaking the rule that existing code can never be broken.
Now I'm of course not saying that no bug should ever be fixed, but that
fixing (obvious) bugs is not always easy for a project with such strict
compatibility rules.
Nevertheless, if someone knows how we can tighten up the spec without
breaking existing code, it may be worthwhile to look into that.
On Fri, Jan 15, 2016 at 3:28 PM, Kito Mann <kito.mann_at_virtua.com> wrote:
> Just to be clear, we're proposing an interface so that people can write
> custom ui:repeat components, but not tightening up the spec so that both
> implementations behave the same?
>
> ___
>
> Kito D. Mann | @kito99 | Author, JSF in Action
> Web Components, Polymer, JSF, PrimeFaces, Java EE, and Liferay training
> and consulting
> Virtua, Inc. | virtua.tech
> JSFCentral.com | @jsfcentral
> +1 203-998-0403
>
> * Listen to the Enterprise Java Newscast: *http://
> <http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
> <http://ww.enterprisejavanews.com>*
>
>
> On Thu, Jan 14, 2016 at 10:29 AM, manfred riem <manfred.riem_at_oracle.com>
> wrote:
>
>> 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> 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> 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
>>> JSFCentral.com | @jsfcentral
>>> +1 203-998-0403 <%2B1%20203-998-0403>
>>>
>>> * Listen to the Enterprise Java Newscast: *http://
>>> <http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
>>> <http://ww.enterprisejavanews.com>*
>>>
>>>
>>>
>>>
>>
>