On 2012-07-05 15:29 , David Karger wrote:
> Most of what you responded to was pure brainstorming that I don't feel
> strongly about. My one serious concern is about the non-developer's
> experience. Anything forcing them to use requirejs or labjs code
> explicitly is bad.
I never suggested that it was good. I pointed it out to note it had
fatal drawbacks.
> The experiment with the <link> method isn't that bad
> but is still unfamiliar.
I am also pointing out to you why your suggestions are not feasible; I
get that they're a bit fluffy - you have yet to follow up these
discussions with code - but you are airing them in public as if they are
worth consideration. I understand this is part of your process, but
some of your brainstorms, light as you hold to them, have been tending
to neglect very pertinent details that make it difficult to take them
seriously enough to respond.
> On the other hand, I'm happy to require any extension developer to
> follow a specific contract. For example, if we forbid the extensions
> from relying on any dependencies at load time, and instead require all
> dependent behavior to occur in an init method, then we don't have to
> worry about script load order if exhibit takes care of invoking the inits.
Case in point. You have to take script load order into account if you
have dependencies.
> e.g., refining the old exhibit_onload approach, we can require every
> extension script to begin with:
>
> if (typeof(Exhibit) == 'undefined') Exhibit = {};
> if (typeof(Exhibit.onload) == 'undefined') Exhibit.onload = [];
>
> and end with:
>
> if (Exhibit.loaded == true) {
> init();
> }
> else {
> Exhibit.onload.push(init)
> }
It would make sense to run this only after the DOM has loaded, no? Do
you intend for this contract to require redefining cross-browser
compatible DOM load event management in each extension, given you can't
expect anything like jQuery to have loaded?
Extensions may have their own dependencies within dependencies (e.g.,
maps requires loading its own details which strongly depends on the map
provider scripts being loaded, especially if you're showing a map
immediately). How do you propose to manage loading those
sub-dependencies in the right order? Or load them in a cross browser
fashion - especially when browsers have different ideas about what order
scripts are going to be loaded in? This seems like it's just pushing
the problem down another level. Is that more code each extension would
also have to paste in and include? What happens if the contract changes?
> Then exhibit core can take care of loading anything in the
> Exhibit.onload queue once it is ready to do so.
> I recognize that this is much more limited than what you can achieve
> with labjs etc., but I see that simplicity as part of its appeal.
It is not at all simple. It sounds unsustainably onerous to me.
> On 7/5/2012 6:02 PM, Ryan Lee wrote:
>> As a follow on, I've already pushed an experiment using the <link>
>> method I discussed. We're currently considering other libraries to help
>> manage dependencies, too (cf., RequireJS).
>>
>> On 2012-06-05 14:31 , David Karger wrote:
>>> 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.
>> LABjs has been in use within the Exhibit 3 codebase since it was
>> started. The problem with merely embedding it in Exhibit and then
>> allowing the specifying of extensions outside of that scheme is [see all
>> of previous message].
>>
>>> 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.
>> No, not at all. LABjs documentation is brief and readily available, I
>> suggest you read it before making suggestions on how it might be applied.
>>
>> Making a UI seem responsive even if it isn't all there is a great way to
>> design things, but what was under discussion was load ordering - not
>> load transport delays. Comparing loading Exhibit, loading extensions,
>> loading data, and parsing data, network costs of loading extensions is
>> highly unlikely to be the reason the UI is blocked. It may interfere
>> due to indeterminate ordering; it is far less likely that it interferes
>> due to transport matters.
>>
>> Still, if you want to redesign all of Exhibit along those lines, I'm
>> happy to look over a pull request. Making Exhibit initialization as
>> asynchronous as possible is a worthwhile goal.
>>
>>> 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.
>> This isn't related to the general topic, but as it pertains to Exhibit,
>> "the page's load event" does not tell you all the scripts are loaded.
>> Exhibit's capacity to load additional scripts means the page load event
>> (which specific one you're referring to is unclear) is definitely not a
>> reliable indicator of completion. Exhibit itself (now reliably) fires
>> its own scripts loaded event.
>>
>>> 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.
>> Using script tags just comes back to the original problem that brought
>> us here, of browsers handling how they load scripts differently. If you
>> want Exhibit to get to the tags before the browsers themselves do, you
>> go back to the bad days of working with each browser's DOM ready event
>> and DOM manipulation inconsistencies to find them.
>>
>>> 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
>>>>
>
>
--
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.
