A while back I stopped returning Zone, or its body, preferring to use AjaxResponseRenderer#addRender instead. So I'm curious - do you see the same effect if you use AjaxResponseRenderer#addRender?
On 24 Jun 2014, at 7:34 pm, Numa Schmeder <n...@dfacto.ch> wrote: > I will add a JIRA then :) > > Concerning the zone ajax issue: > > I am returning zone.getBody() > > Give it try, you will see that with jquery you get the same behavior. > > Maybe it’s by design, but I think it’s a bug of the core js stack the > function ElementWrapper.update > adds nested div one after the other instead of completely replacing the > content of the zone div… > > Also the zone id shouldn’t change on subsequent request… As you have seen > each nested div has a different zone id. > I don’t know what should be the normal behavior. This is the behavior I have > identified. > 1/ The ajax response send the zone body wrapped inside the zone div that has > a new id which a combination of the original zone id and a timestamp. > 2/ The core javascript replaces the zone body with the received zone body > wrapped in this zone div. > > But maybe it’s me doing something wrong… > > The point 2/ should be: > Extract the received zone body wrapped in a div, then replace the original > zone body. > Questions: what should happen if the zone div has any informal parameter > changed (such as a css class) due to an ajax request. Should these changes be > reflected on the client or only the changes in the body ? > > Cheers, > Numa > > > > > Le 23 juin 2014 à 17:21, Thiago H de Paula Figueiredo <thiag...@gmail.com> a > écrit : > >> On Mon, 23 Jun 2014 11:53:39 -0300, Numa Schmeder <n...@dfacto.ch> wrote: >> >>> Thanks for your answer! >> >> ;) >> >>> Yes that’s what I was meaning with one js file per page, you need to use >>> the @Import. >>> But I have a special use case where all js is not in the context but on >>> separate server. And the @Import makes things a bit complicated. >>> Would be nice to have @Import working with absolute path or have a special >>> @ImportUrl >> >> If there isn't a JIRA for that, please file one. >> >>> The thing is that when prototyping quickly, the ability to inline >>> javascript is very useful. >>> Once you are happy with your prototype you can do some cleaning and >>> organize your js better. >> >> Ok, but in software development, usually nothing gets organized with time . >> . . >> >>> Well actually we can use the documentLink.addScript, this one is not yet >>> deprecated… >> >> That's an internal service (DocumentLinker), so no guarantees about backward >> compatibility of it. >> >>>>> Is there a way to bypass pageinit to initialize or add scripts and have >>>>> them at the end of the page ? >>>> >>>> You can write and contribute a MarkupRendererFilter, but then it's not a >>>> component anymore. >>> This sounds over complicated and as you said it’s not a component anymore. >> >> Yeah, but you're requirements are too specific for a component. >> >>> Based on the initial work of Adam Henderson >>> https://github.com/adamhenderson/tapestry-dojo. >>> I have fully ported the dojo stack to tapestry. All core components do work >>> (forms, ajax, zones, confirm, autocomplete etc…) >>> I have kept only the underscore library dependency, though I could get rid >>> of it, as most underscore functions are available within dojo. >>> I will release all the changes in one jar and put on github. >> >> Nice! >> >>> I am just having some difficulties with the @Symbol usage. >>> The dojoConfig javascript object is created by contributing specific >>> symbols. >>> But some config properties of dojoConfig are optional, and if I set a >>> Symbol to null, I get an exception. >>> So the workaround is to set all my symbols to strings, and an empty string >>> value means don’t set this property. >> >> Symbols don't accept null values by design, so you're doing the right thing >> here. >> >>> When you update a zone or refresh it. The divs start to nest on inside each >>> other. Exemple: >>> >>> <div id=“zone"> >>> My initial zone >>> </div> >>> >>> After 2 updates, the zone content becomes: >>> >>> <div id=“zone"> >>> <div id=“zone_84847657567"> >>> <div id=“zone_874747899884"> >>> My initial zone after 2 updates >>> </div> >>> </div> >>> </div> >> >> You're probably returning the zone object instead of zone.getBody(). Did I >> get it right? >> >> -- >> Thiago H. de Paula Figueiredo >> Tapestry, Java and Hibernate consultant and developer >> http://machina.com.br >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
