Howard, Thank you for your answer. From what I understand, if a zone B is nested in a zone A, its id will change in a partial update of A. Thus the existing links on the page, oustide of A, that used to point to B, wont point to it anymore after that partial update of A. This explains the behaviour I saw on my use case. This leads me to the conclusion that nesting zones is not legal in T5, or at least not compatible with Ajax. Am I right on that point ? Howard Lewis Ship a écrit : --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]It's not a hash code, its a unique id. Because Tapestry is having to render the page piecemeil, across a series of Ajax requests, it can't know what ids are already taken when it is trying to generate unique DOM ids for elements, therefore, an Ajax request gets a namespace: this timestamp as a hex string. The namespace is encororated into any ids generated by PageRenderSupport during an Ajax partial markup render.On Wed, Mar 19, 2008 at 11:43 AM, José Paumard <[EMAIL PROTECTED]> wrote:It is indeed an Ajax request, the t:zone XML attribute is there, so there is no problem with that. From what I see, T5 sometimes maps a TML <t:zone t:id="someZone"></t:zone> as (seen by inspecting the DOM) <div id="someZone:118c853e048" class="t-zone"/> or as <div id="someZone" class="t-zone"/> And in the 1st case, clicking on the link refresh the page, with an error message. When I try to narrow things, it seems to me that when you refresh a Zone A that contains another zone B, then the id of B is added this hashCode like stuff. I hope Howard could enlighten us on that point ? Thank you, José Ted Steen a écrit : The error you get is probably due to the fact that it is not an ajax request. you can only return blocks from event methods when making ajax requests. you have to make the request with Ajax.request(...) or by using tapestry default ajax mechanism. (<t:form t:zone="....">...) hope it helps! 2008/3/19, Martin Kersten <[EMAIL PROTECTED]>: I see. When I read the AJAX documentation correctly your code snippet should be on the save side. Sorry but I can't see anything wrong. Cheers, Martin (Kersten) ________________________________ Von: José Paumard [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 19. März 2008 17:33 An: Tapestry users Betreff: Re: AW: Component event handlers Code snippets are very basic : In the tml : <t:eventLink t:event="someEvent" t:zone="someZone">click me</t:eventLink> <t:block t:id="someBlock"> <t:some.component/> </t:block> In the class : @Inject private Block someBlock ; @OnEvent(value="someEvent") Block clickMe() { return someBlock ; } What I would expect is to see the content of the block in the div "someZone", but I have an exception instead. José Martin Kersten a écrit : Sounds like onActivate? What do you try to do? Can you give us the exact case (event type). Code Snippet? ________________________________ Von: José Paumard [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 19. März 2008 17:18 An: Tapestry users Betreff: Re: Component event handlers Hello Chris, Thank you for your fast answer. It is Block (not BlockImpl, this class is in the internals of T5, so using it is not recommended). I switched to Object, but it didnt change anything. Here is the exact error message : A component event handler method returned the value [EMAIL PROTECTED] Return type org.apache.tapestry.internal.structure.BlockImpl can not be handled. Configured return types are java.lang.Class, java.lang.String, java.net.URL, org.apache.tapestry.Link, org.apache.tapestry.StreamResponse, org.apache.tapestry.runtime.Component. Chris Lewis a écrit : What is the declared return type of your method? It should be Object, and not BlockImpl. José Paumard wrote: Hi all, Everytime I try to return an injected block in an event handler method, I get an error message, telling me that BlockImpl is not a valid returned value. From the nightly generated docs, this is supposed to work. Has anyone experienced this too ? Thank you, José --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] |
- Component event handlers José Paumard
- Re: Component event handlers Chris Lewis
- Re: Component event handlers José Paumard
- AW: Component event handlers Martin Kersten
- Re: AW: Component event handlers José Paumard
- AW: AW: Component event handlers Martin Kersten
- Re: AW: Component event handle... Ted Steen
- Re: AW: Component event ha... José Paumard
- Re: AW: Component event ha... Howard Lewis Ship
- Re: AW: Component event ha... José Paumard
- Re: Component event handlers Davor Hrg