Using clientId for services like Ajax is big mistake, either. clientId
can be changed by implementation ( portletbridge prepends them with
portlet namespace, for example ), or use different separator char as
it configurable in 2.0 . For my opinion, findComponent should be
extended to use xpath-like expression that eliminates requirement for
explicit id's in all components. Such expression can use facet names,
parent or child position, component type etc. Only a few reference
components would require explicit id in this case.
On Thu, Jul 7, 2011 at 3:39 PM, Leonardo Uribe <lu4242_at_gmail.com> wrote:
> This is Blake response:
>
> The issue is that the cases that don't work aren't hacks. If anything,
> they are the way we expect our users to use composite components. I
> worry that by carving out an exception, we complicate the use of
> composite components if the page author has to look at each composite
> component to determine whether it happens to be a NamingContainer or not.
>
> I agree that fixing findComponent is not trivial, however remembering
> the original child locations isn't exactly rocket science either.
>
> Can you provide an example of where fixing findComponent would cause any
> problems with invokeOnComponent or visitTree? As I wrote before, we
> aren't modifying the generated clientIds for the relocated components so
> I don't understand why a change to findComponent would have any effect
> on clientId-based behavior.
>
> 2011/7/7 Leonardo Uribe <lu4242_at_gmail.com>:
>> Hi
>>
>> This answer is from some days ago, but it wasn't sent to
>> jsr344-experts list, so I resend it to continue the discussion on this
>> list:
>>
>> Hi
>>
>> 2011/7/1 Blake Sullivan <blake.sullivan_at_oracle.com>:
>>> Leonardo,
>>>
>>> I agree that you can get rid of the restriction in a very limited case, but
>>> is it worthwhile to make such a change? The reason the composite components
>>> are NamingContainers is to ensure isolation from the consuming page. Your
>>> solution to avoiding id conflicts in this case was to not set any ids in
>>> your composite component definition. This precludes the definition from
>>> EVER using any id-based services, such as <f:ajax> within its definition.
>>> In addition, your proposal does nothing to address abstraction failure
>>> issues regarding whether a composite component implementation happens to use
>>> NamingContainers as part of its implementation.
>>>
>>
>> The intention is just allow the "exception", that theorically is
>> working on MyFaces without change anything. It is clear there will be
>> some hacks that just will not work, but the same is true for cases
>> that right know depends on ui:include or facelets user tags. By
>> default, composite components should be naming containers to work
>> fully. Note this feature does not need any change on the spec.
>>
>>> I do not consider the initial findComponent() failure a bug. Page authors
>>> using components need to know whether they are NamingContainers or not.
>>> Good IDEs should be helping you out in this case. In many ways, it is
>>> easier for page authors to remember whether a component is a composite
>>> component or not if all of the composite components are NamingContainers.
>>>
>>> The abstraction failure is that findComponent() should always work in terms
>>> of the document that the page author is working in. In the case of
>>> composite components, this means that component references in the page
>>> consuming the composite component should stay the same regardless of whether
>>> a composite component uses NamingContainer in its implementation or not.
>>>
>>
>> It sounds reasonable, but I don't see how can we do such change over
>> findComponent() without degrade its performance. Things are more
>> difficult if you consider nested composite components using
>> cc:insertChildren, cc:insertFacet and templating tags. The problem is
>> once the component tree is built, you lose the information related to
>> the page where the component was defined. The only information saved
>> is a marker to identify it on a further refresh (MARK_ID).
>>
>>> Fixing findComponent() should not break invokeOnComponent() and visitTree()
>>> as we are not talking about changing the structure of the returned clientIds
>>> for the child components from the consuming page after they have been
>>> relocated into the composite component.
>>>
>>
>> But an invokeOnComponent will not work too, without get the final
>> clientId. The intention of do not use a NamingContainer deliberately
>> is precisely to know beforehand the clientId of the component.
>>
>> The problem with use facelets user tags or facelets dynamic components
>> is that all properties are strings that are put on a VariableMapper,
>> which is a nasty hack (I already changed that terrible code in MyFaces
>> to something better), and in practice there are some situations where
>> JSF composite components cannot be used, specifically by the
>> NamingContainer restriction.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>
--
_________________
entia non sunt multiplicanda praeter necessitatem,
(entities should not be multiplied beyond necessity.)