AbstractComponent.getPath() access _id field directly instead of using getId()
------------------------------------------------------------------------------
Key: TAPESTRY-2456
URL: https://issues.apache.org/jira/browse/TAPESTRY-2456
Project: Tapestry
Issue Type: Bug
Components: Core Components
Affects Versions: 4.1.5
Environment: windows xp pro sp2
tapestry 4.1.5
==JRE==
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing)
Reporter: carlos fernandez-touzon
I have an @EventListener attached to a JS method on a Hidden component.
during the rendering of the page the ComponentEventConnectionWorker will
contribute the results of the ComponentEvent.script for each component that has
ajax events. as part of that rendering the component's extendedId is utilized.
my hidden component is returning an extended Id of
"MyPageName/theHiddenComponentsContainer.null"
the ".null" portion of the extendedId is incorrect. The Hidden components Id
parameter is set to "hidden".
this seems to be a bug in how the AbstractComponent.getIdPath() conflicts with
the Hidden components Id parameter.
AbstractComponent.getIdPath() access the _id instance variable directly.
Outsiders, such as the PageLoader use the getId()/setId() getter/setter pair.
Unfortunately, if the component has an id parameter getId()/setId() are
overridden by the ParameterPropertyWorker.
In my case this means that the component's id$Default instance variable is set
to "hidden" while the _id instance variable is still null. Calls to getId()
return "hidden", but since the AbstractComponent accesses _id directly ... the
id$Default is never used when constructing the extendedPath.
This should effect any component with an id parameter.
I couldn't get anyone to confirm or disagree with me about this issue on the
mailing list. So I am working under the assumption that I am correct. I also
didn't find any mention of this in Jira or the mailing list - although nabble
has a lot to be desired and I am a Jira noob.
I will try to submit a patch based on the tapestry v4.x code in the trunk.
I listed this as major because the cause of this error is pretty obscure and
can become a pretty big "time sink" when it comes up. I assume this has come
up before because 1) the @EventListener feature is pretty compelling and 2) a
number of form components use the ID parameter.
Carlos
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
