Given RequireJS is a widespread ecosystem, I'm not sure why you would want to take on the pattern, but only in-house, foregoing all of the other possibly useful code out there available to you. At any rate, I *am* suggesting it as a valid development path with potential for uptake for someone to pursue if I don't get to it first.
In case you're not clear on RequireJS use, you don't have to specify dependencies in the HTML. You can list requirements in code. This is where the experimenting comes in, but it seems possible that we might adopt RequireJS without needing to amend any of the instructions for including Exhibit in a page. On 2012-07-05 15:05 , David Karger wrote: > 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 [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.
