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
