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