Right,
The solution needs to take into account code that has been running like
this in forever.
Note in this particular case the spec was not tight enough which allowed
for this to happen.
Thanks!
Kind regards,
Manfred Riem
On 1/15/16, 8:54 AM, arjan tijms wrote:
> 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
> <mailto: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 <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>_
>
>
> On Thu, Jan 14, 2016 at 10:29 AM, manfred riem
> <manfred.riem_at_oracle.com <mailto: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
>> <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>_
>>>>
>>>
>>
>>
>
>