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>*
>>
>>
>>
>>
>