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.
