Jerome Velociter wrote:
Jerome Velociter wrote:
Hello everybody,
Right now with Skin eXtensions we can hit "jsx" and "ssx" action URLs
to
retrieve JavaScript and CSS files, that either comes from XObjects (the
original SX idea) or from JAR resources (since SX 1.3). I'm playing with
the idea of adding a new action that would return text/html, possibly
available as JAR resource extension _only_. I explain below how I came
to this need.
This morning I gave some thoughts on the behavior the {{map}} macro
should have when the Internet is not reachable, but the wiki is (any
resemblance to actual facts is... not coincidental;)). The only
alternative I found not to have the macro blocking the whole page
loading until the HTTP requests gives up trying to get the library from
the service provider (google, yahoo, etc.) is to have it being loaded in
an iframe (and then display the map in that iframe, too). For this to
happen however, I need to pass an URL to that iframe which will give the
html needed (<script> tag for the library, <script> to consume the
library, and probably a <div> container for the map itself, etc.) Since
I work with the constraint of being to publish the macro as a jar only,
I would like this HMTL file to be a resource file of my macro
(otherwise, a simple wiki page called with "xpage=plain" would do the
trick, obviously).
Since ssx and jsx returns content type according to the resource they
provide, we cannot use them for this purpose (and it would be hackish
use anyway). Thus I propose we add a new action "hsx" for example, to
return "text/html" content. This extension does not have much sense as a
document extension (since we don't know where to inject the result,
unless the new XClass has a "extension point" field but then it becomes
somehow an IX class), so I it would be available only as JAR resource
extension.
Did I miss something there ?
Yes :) As an alternative to what I proposed above, I can inject the
iframe and write its content from a resource JSX...
I have a working prototype of this now.
The not so nice thing about it is that I had to use intervals + timeout
to check whether or not the library is loaded. I could not find a way of
properly observing the loading of the document inside the iframe. As
soon as I start injecting the script element for the gmaps API (which
itself, on loading, will inject some more scripts elements to load its
actual code), onload events on the window inside the iframe become
unreliable and are never fired. The only way I could have such events
fired is writing the whole iframe content with its own document.write().
I thought about binding prototype on the iframe window to see if it can
handle those events better, but even this does not appear to be easy,
see
http://www.ruby-forum.com/topic/157409#693992.
What I currently do is this :
Once the initial <script> (the one that loads the gmaps API, which
itself will load its own files) is loaded (this event is reliable), I
start evaluating the availability of the actual library every 100ms for
example. I also set a global timeout of for example 10 secs, in case it
never comes (at this point we know we have the internet accessible,
since the initial API was loaded, but it could still fail for whatever
reason). When the library is retrieved I consume it to display the map
and remove the timeout. If the library never comes, on the timeout I
inject a warning message in place of the map. (same behavior if the
first API loading fails)
This way, we can have maps that loads separately from the wiki page not
blocking it, and we can distribute the macro as jar only :)
Note that we will have to replace the call that fires the ajax request
for the footer by document.observe("dom:loaded") as evoked in another
thread, otherwise (with Event.observe(window,'load',...) it fires after
all iframes are actually loaded.
Jerome.
Jerome.
Sergiu what do you think ? Others ?
Jerome.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs