My suggestion wasn't to switch to requirejs, but just this approach of
listing the desired extensions as attributes in the script tag so that
exhibit could take explicit control of loading them instead of leaving
it to the browser. I'm not sure if it's a *good* idea but it seemed
different so worth pointing out.
On 7/5/2012 6:01 PM, Ryan Lee wrote:
RequireJS is quite popular. We've considered looking into it at
Zepheira for Exhibit 3.0, but it's a big and somewhat experimental
change and not one we have slated for the immediate future. If you're
interested in pursuing it and submitting a pull request, I'd be happy to
look it over.
On 2012-07-03 12:11 , David Karger wrote:
Here's one other option, as demonstrated by the aloha editor, leveraging
their usage of requirejs:
<script type="text/javascript" src="Aloha/lib/aloha.js"
data-aloha-plugins="common/format,
common/table,
common/list,
common/link,
common/highlighteditables,
common/block,
common/undo,
common/contenthandler,
common/paste,
common/commands,
common/abbr,
extra/browser,
extra/linkbrowser"></script>
On 5/11/2012 3: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
--
You received this message because you are subscribed to the Google Groups "SIMILE
Widgets" group.
To post to this group, send email to simile-widgets@googlegroups.com.
To unsubscribe from this group, send email to
simile-widgets+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/simile-widgets?hl=en.
