[Trinidad] please comment on the following bug

[Andrew Robinson <an...@gmail.com>]

The API for the partialTriggers seems to be broken for Trinidad trunk
components. The bug is:

https://issues.apache.org/jira/browse/TRINIDAD-757

Please review the comments and offer any opinions on changing the
current method to match the documentation. Also please check that we
are right.

Thanks,
Andrew

Re: [Trinidad] please comment on the following bug

[Adam Winer <aw...@gmail.com>]

On 10/8/07, Andrew Robinson <an...@gmail.com> wrote:
> > My recommendation is to change the code and documentation to:
> >  - If the component is a naming container, search relative to the
> >    parent;  otherwise search relative to the component
>
> But what if the person does want to search the children? If the parent
> was used, they would have to refer to themselves, which is more
> confusing IMO.

I agree, that's confusing.  But, IMO, I think that requiring
"::" for finding peers:

  <af:commandLink id="foo" .../>
  <af:table partialTriggers="::foo">...</af:table>

is also really confusing, and suspect that searching for
peers is much more common than searching for children.  Plus,
it's existing behavior, and breaking existing behavior is never
a good thing.

-- Adam


> Example:
>
> <my:namingContainer partialTriggers="link">
> <tr:commandLink id="link" partialSubmit="true" />
> </my:namingContainer>
>
> versus:
>
> <my:namingContainer id="nc" partialTriggers="nc:link">
> <tr:commandLink id="link" partialSubmit="true" />
> </my:namingContainer>
>
> So, if it was left as-is in terms of documentation, the following
> would be the correct way to refer to a child and refer to a sibling:
>
> <tr:commandLink id="outsideLink" />
> <my:namingContainer partialTriggers="link, ::outsideLink">
> <tr:commandLink id="link" partialSubmit="true" />
> </my:namingContainer>
>
> That seems to make sense to me at least
>
> -Andrew
>

Re: [Trinidad] please comment on the following bug

[Andrew Robinson <an...@gmail.com>]

> My recommendation is to change the code and documentation to:
>  - If the component is a naming container, search relative to the
>    parent;  otherwise search relative to the component

But what if the person does want to search the children? If the parent
was used, they would have to refer to themselves, which is more
confusing IMO.

Example:

<my:namingContainer partialTriggers="link">
<tr:commandLink id="link" partialSubmit="true" />
</my:namingContainer>

versus:

<my:namingContainer id="nc" partialTriggers="nc:link">
<tr:commandLink id="link" partialSubmit="true" />
</my:namingContainer>

So, if it was left as-is in terms of documentation, the following
would be the correct way to refer to a child and refer to a sibling:

<tr:commandLink id="outsideLink" />
<my:namingContainer partialTriggers="link, ::outsideLink">
<tr:commandLink id="link" partialSubmit="true" />
</my:namingContainer>

That seems to make sense to me at least

-Andrew

Re: [Trinidad] please comment on the following bug

[Adam Winer <aw...@gmail.com>]

Here's the background:
- The "::", ":::" support is relatively recent.
- Because of that, there originally was no way for a table to
  be triggered by anything but its own children, since a table
  is a naming container!

This was a high priority issue back in the day, and the fix (then)
was to change addPartialTriggerListeners() from using the component
itself to the parent.  And, sadly, the documentation didn't follow.

So, to answer one question - "how many users are dependent on this
broken behavior" - the answer is TONS.  Change it, and you'll
break partialTriggers on all tables.  Which is bad.

The question of how many people rely on the behavior of "::"
when you're on a non-naming container whose immediate parent
is a naming container is far trickier to answer.  Someone out there
will care, and have their code broken, but it's not the massive hell
that changing it for components that are themselves naming
containers would be.

My recommendation is to change the code and documentation to:
 - If the component is a naming container, search relative to the
   parent;  otherwise search relative to the component

Then the next question is whether, on failure for the non-NC
case, we should do a second search relative to the parent,
just for backwards compatibility, but deprecate that pattern
(perhaps by logging at INFO that a deprecated usage of
partialTriggers is in effect).

-- Adam


On 10/5/07, Andrew Robinson <an...@gmail.com> wrote:
> The API for the partialTriggers seems to be broken for Trinidad trunk
> components. The bug is:
>
> https://issues.apache.org/jira/browse/TRINIDAD-757
>
> Please review the comments and offer any opinions on changing the
> current method to match the documentation. Also please check that we
> are right.
>
> Thanks,
> Andrew
>