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
