Does anyone else have thoughts on Leonardo's solution vs a Repeater
interface?
___
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 Fri, Jan 15, 2016 at 12:26 PM, Leonardo Uribe <leonardo.uribe_at_irian.at>
wrote:
> Hi
>
> The point is there is an implementation or ui:repeat and UIData that
> behaves as expected by the spec without any additional changes. The only
> difference we have between both implementations is that one has a bug in
> that part and the other does not. The fix is just implement
> setDataModel(...), getDataModel(...) and other related methods in a way
> that assume the same component instances is used many times in the same
> phase by different "virtual" components.
>
> I do not see a use case where the fix could break older code, or at least
> there is no report suggesting that the current ui:repeat implementation
> contains a compatibility bug.
>
> But if we talk about c:forEach tag, that's another story, because that
> component has been proven to be really hard to fix, and any attempt to fix
> it breaks backwards compatibility. I do not how, but the users always found
> new creative ways to break that component, but I think the latest version
> we have in MyFaces Core 2.2.9 is the best fix so far.
>
> The fix is just use a map to store the DataModel instances, and use the
> container clientId to get the right instance. That sounds better than add a
> Repeater interface.
>
> regards,
>
> Leonardo Uribe
>
>
> 2016-01-15 9:54 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com>:
>
>> 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>*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>