Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
4.1.5
-
None
-
None
-
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)
Description
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