On Thu, Apr 9, 2009 at 8:11 PM, Howard Lewis Ship <hls...@gmail.com> wrote:
> The events triggered by the default components used by the BeanEditor > can't be caught: those components are rendered from other pages, they > aren't part of your page hierarchy, so component events bubble up on > the other page hierarchy. > > In addition, the client element ids are documented, but the component > ids are part of the implementation of BeanEditor or, more > specifically, the contributions to the BeanBlockSource service. > > In other words, the TextField component that edits the backgroundURL > field is component core/PropertyEditBlocks:textField, so any events > would have to be caught by PropertyEditBlocks, not your class. > Further, the exact same component, configured differently each time, > will be used to edit every property in your for that's data type is > "text". > Hmm. I think I'd need to dig farther into Tapestry and the core components to really understand that completely. I hear the words, but I'm not attaching meaning to all of them yet. The idea that components on my form are being rendered from other pages doesn't mesh with my undoubtedly limited understanding of Tapestry. Trying my best to gloss over the parts I don't understand and extrapolate from the parts that I think I might ... I believe you're saying that I can't add totally custom validation via event handling to fields that are generated by BeanEditor or BeanEditForm, and that I can either live with form-level validation (e.g. onValidateForm), or, alternately, use my own full form rather than BeanEdit*? - Geoffrey -- Geoffrey Wiseman http://www.geoffreywiseman.ca/
