Ryan, of the scenarios you propose, I'd advocate the principle that the
user should never need to write js just to load extensions. I don't
know enough about labjs to be sure but I think this rules out direct use
of labjs, and possibly the exhibt-specific version. On the other hand,
if there were a way to use labjs "invisibly", embedding its invocations
inside the exhibit api and extensinos, it would be great.
An option you didn't mention would be to incorporate a "just in time"
approach to the extensions. As you say, exhibit runs into problems when
if it starts running before all extensions have loaded. But more
specifically, the problem only occurs when it tries to use the
functionality offered by the extension. Canonical examples include
trying to generate a view provided by an extension that hasn't loaded
yet, or to import data using an importer that hasn't loaded yet. What
if exhibit were designed such that, if it got into that situation, it
simply registered a callback to be invoked when the necessary
functionality was available? e.g., view rendering could be gated by a
"require" method that wouldn't run its argument until a corresponding
"provide" method was called. I think this is the kind of functionality
offered by labjs, right? So as long as extension authors followed the
right design pattern, invoking labjs at the right moment, we'd be ok.
Of course, you'd want to handle the case of the necessary element
*never* being provided---but I think the page's load event, which tells
you all scripts are loaded, could be used to trigger a "timeout" that
would signal an error if some necessary functionality were still missing
at that point.
I agree with you that it's premature to rely on "async" loading, and
that inline-extensions would be come a parameter management nightmare.
An alternative to abusing link tags is abusing script tags. One could
add an attribute <script ex:role="extension" src=...>; exhibit could
find such tags and use them to detect scripts it should wait for (using
onload events) before running. On the other hand, for fastest response
it would be better to use the just in time approach discussed before,
since that would allow exhibit to quickly render its initial view even
if other views in the viewpanel require specific extensions.
On 05/11/2012 03:08 PM, Ryan Lee wrote:
Hi all,
We've traced this down to a problem with the current extension loading
mechanism. In an attempt to keep things from shifting too much between
Exhibit 2 and Exhibit 3, I tried to allow for the form:
<script src="exhibit-api.js">
<script src="extensions/map-extension.js">
But, with the varied ways released browsers now handle the script tag,
this introduces a potential network delay in loading everything in the
right order; sometimes the map code gets loaded after Exhibit's started
to initialize itself, which is too late.
You probably weren't expecting design proposals to your question, but it
seems an opportune time to share what I've been kicking around the past
couple of days, each with its own strengths and weaknesses.
* Use LABjs
In this scenario, the only script src tag will be to load the LABjs
library, then use its loading framework inline to bring everything
related to Exhibit, including extensions, in in an orderly fashion. The
major drawback here is that it forces users who don't necessarily care
at all about code to pay attention to the actual scripting. For those
who do pay attention, it makes things a bit easier to incorporate
extra-Exhibit material into the loading process.
A related scenario would be to mask LABjs entirely with an
Exhibit-specific mechanism, but this only really adds a layer that might
allow an easier departure from LABjs if needed in the future.
* Use async / defer
HTML 5 introduces attributes to the script tag that allow the page
author to give hints to the browser about whether some scripts can load
without dependency on one another and whether some need to be run in the
order they appear in. But support is not universal across browsers.
* Abuse link rel
Instead of listing extensions (or other scripts) as actual script tags,
just point to them with
<link rel="exhibit-extension" href="...">
and let Exhibit pick out and load extensions itself during its loading
process. Other than the fact that I've never seen anybody use<link> in
this way, this might be the simplest and least obtrusive solution I
could think of. It does tend to make it even harder for those who don't
control the<head> of a document to get Exhibit in.
* Cram in more parameters
Instead of listing each extension separately, they could also be set as
additional parameters to the core of Exhibit
<script src="exhibit-api.js?extension=extensions/map-extension.js">
which (aside from taking some steps backwards into Exhibit's history) is
not as dubious as the prior proposal but makes that one line difficult
to read and assemble and additionally makes it difficult for the
extensions themselves to extract any of their own parameters; it would
probably require an ad hoc solution for adding extension-only parameters.
If you have any other ideas or feedback on the above, I'd love to hear
from you (or get a pull request from you on GitHub ;).
As for the Tile view issue, it had to do with paging and localization;
that's been fixed in trunk [1]. Perhaps we can make a new release
candidate in the near future bundling some of these fixes together.
1.
https://github.com/zepheira/exhibit3/commit/0814c0b3695bb96e79272c2b00de8b3c17d1f784
On 2012-05-11 05:40 , Sima Kan wrote:
Hi!
I cannot view the Map or Tile views for the Senate example on the Mac
either. I'm using Safari 5.0.4
Any idea why?
Thanks!
sima
On Wednesday, April 25, 2012 10:02:49 PM UTC-4, Mark Baker wrote:
Hi again,
On Wed, Apr 25, 2012 at 5:31 AM, asmi<[email protected]> wrote:
Hi all,
Did anyone realize that the
demo: http://databench.zepheira.com/demos/nobelists/nobelists.html and
wiki
howto provided here: http://www.simile-widgets.org/wiki/NobelistsHTML,
doesnt work somehow?? it doesnt respond to the filters / navigators at
all!
same goes for Senate in html5
: http://databench.zepheira.com/demos/senate/html5.html
I tried them in latest chrome 18 and firefox both! is it just me or ?
The Nobelists exhibit worked fine for me in both Chrome 18 and Firefox
11 on Ubuntu 64, but I did run into some strange problems with the map
and tile views in the Senate exhibit on Firefox though.
Hopefully Ryan can have a look when he returns next week.
Mark.
--
You received this message because you are subscribed to the Google Groups "SIMILE
Widgets" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/simile-widgets?hl=en.
