Multiple plugins applied to a dependency

[hallettj]

In the Loader Plugins spec, I would find it useful to spell out what
happens when multiple plugins are chained.

For example, consider a dependency of the form,

define(['foo!bar!../resources/thing'], function(thing) { /* ... */ });

My first question is, is this allowed?

If it is allowed, what order should the plugin load() and normalize()
methods be called and what should be given as the resource id in each
invocation? It seems to me that there are a few possibilities:

Option A, plugins are applied from right-to-left and the normalized
dependency name is passed to the next plugin:

1. bar.normalize('../resources/thing', fn);
2. bar.load('/root/resources/thing', require, load);
3. foo.normalize('bar!/root/resources/thing', fn);
4. foo.load('bar!/root/resources/thing', require, load);

Option B, plugins are applied from right-to-left and each plugin gets
the original resource id:

1. bar.normalize('../resources/thing', fn);
2. bar.load('/root/resources/thing', require, load);
3. foo.normalize('../resources/thing', fn);
4. foo.load('/root/resources/thing', require, load);

Option C, the leftmost plugin is applied and is responsible for
interpreting the other plugin applications:

1. foo.normalize('bar!../resources/thing', fn);
2. foo.load('bar!/root/resources/thing', require, load);

In my personal option Option A is the way to go. I think that Option
B does not make much sense and that Option C, while providing the most
flexibility, pushes unnecessary work onto plugin implementations.

There is a complication with Option A though, which is that the Plugins
API does not appear to allow a loaded dependency to be passed from
plugin to plugin - only the dependency name can be forwarded. That
could make it difficult to implement a dynamic, chainable plugin.

Is there precedent for one of these options in the RequireJS
implementation?

[jrburke]

It is Option C, because the resourceId (IDs are pluginId!resourceId) should be opaque to the loader. The resourceId/plugin could be using ! for its own purposes and not mean for it to be a loader plugin call. Only the loader plugin should be deciphering those values. The only exception is if the loader plugin does not implement a normalize method. In that case, the loader will attempt to treat the resourceId like a regular ID and do ID normalization (resolving relative paths). Once normalized, it passes the normalized ID to the plugin's load method and then the loader plugin is responsible for doing whatever it wants with that ID..

If that makes sense, I can add that to the API page, and send a note the amd-implement list about the update.

[unscriptable]

Just confirming that curl.js operates like RequireJS: option C. IIRC, dojo
does the same. -- John

On Tue, Feb 19, 2013 at 10:42 PM, James Burke [email protected]:

It is Option C, because the resourceId (IDs are pluginId!resourceId)
should be opaque to the loader. The resourceId/plugin could be using ! for
its own purposes and not mean for it to be a loader plugin call. Only the
loader plugin should be deciphering those values. The only exception is if
the loader plugin does not implement a normalize method. In that case, the
loader will attempt to treat the resourceId like a regular ID and do ID
normalization (resolving relative paths). Once normalized, it passes the
normalized ID to the plugin's load method and then the loader plugin is
responsible for doing whatever it wants with that ID..

If that makes sense, I can add that to the API page, and send a note the
amd-implement list about the update.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-13814311.

[hallettj]

Cool, that seems quite sensible. Thank you for the clarification!

[rcgill]

-----Original Message-----
From: John Hann [mailto:[email protected]]
Sent: Tuesday, February 19, 2013 7:48 PM
To: amdjs/amdjs-api
Subject: Re: [amdjs-api] Multiple plugins applied to a dependency (#9)

Just confirming that curl.js operates like RequireJS: option C. IIRC, dojo does
the same. -- John

Confirmed.

On Tue, Feb 19, 2013 at 10:42 PM, James Burke
[email protected]:

It is Option C, because the resourceId (IDs are pluginId!resourceId)
should be opaque to the loader. The resourceId/plugin could be using ! for
its own purposes and not mean for it to be a loader plugin call. Only the
loader plugin should be deciphering those values. The only exception is if
the loader plugin does not implement a normalize method. In that case, the
loader will attempt to treat the resourceId like a regular ID and do ID
normalization (resolving relative paths). Once normalized, it passes the
normalized ID to the plugin's load method and then the loader plugin is
responsible for doing whatever it wants with that ID..

If that makes sense, I can add that to the API page, and send a note the
amd-implement list about the update.

—
Reply to this email directly or view it on
GitHub<#9 (comment)
13814311>.

—
Reply to this email directly or view it on GitHub
#9 (comment) .

<https://github.com/notifications/beacon/Lm1EgjW7zHYBhqEMEekR94fsWO
pyArIda-CPbqee3PT8TGr2zIR09mkXInk1fTjy.gif>