search

amdjs / amdjs-api

Houses the Asynchronous Module Definition API
https://groups.google.com/group/amd-implement
4.31k stars 499 forks source link

Multiple plugins applied to a dependency #9

Open hallettj opened 11 years ago

hallettj commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 notifications@github.comwrote:

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/amdjs/amdjs-api/issues/9#issuecomment-13814311.

hallettj commented 11 years ago

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

rcgill commented 11 years ago

-----Original Message----- From: John Hann [mailto:notifications@github.com] 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 notifications@github.comwrote:

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/amdjs/amdjs-api/issues/9#issuecomment- 13814311.

— Reply to this email directly or view it on GitHub https://github.com/amdjs/amdjs-api/issues/9#issuecomment-13814423 .

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