Fwd: [dojo-contributors] Re: Bootstrap Bloat documentation

James Burke jburke at dojotoolkit.org
Sun Apr 9 20:02:55 EDT 2006


Oops, forgot to Reply All...

---------- Forwarded message ----------
From: James Burke <jburke at dojotoolkit.org>
Date: Apr 9, 2006 5:01 PM
Subject: Re: [dojo-contributors] Re: Bootstrap Bloat documentation
To: alex at dojotoolkit.org


On 4/9/06, Alex Russell <alex at dojotoolkit.org> wrote:
> You know, a module like "dojo.backcompat" or something seems to make
> more and more sense to me. It would allow us to keep our "we provide
> back-compat stubs" policy, provide a single place to provide method
> forward and deprecation, and provide a single location to cull
> deperecation and back-compat stubs from in the future. I can imagine it
> including a lot of code that looks like:
>
> if(dojo.evalObjPath("dojo.whatever.foo")){
>         dojo.whatever.foo.bar = function(){
>                 dojo.deprecated(...);
>                 // ...
>         }
> }
>
> The only downside is that it would then of course need to be require()'d
> last and I'm not sure how to garuntee that today.

Perhaps we can do something wicked like have this backward
compatibility package not define anything as it is included, but do
some aspected oriented interception on a
dojo.packageLoaded(packageName) method. The package loading stuff
would call this method as it loaded a package. Since the compatibility
layer is intercepting calls to that method, it could check the
packageName and add the shims at that point.

So the cost of using the shims means the user has to bring in more
code (AOP event stuff), but I think that is OK for getting backward
compatibility. The AOP event stuff would not be needed for the package
loader since it is just calling (a possibly empty) method -- some
method that would allow attaching of the AOP advice.

We should probably version the compatibility packages too, to indicate
what shims are for what releases.

The only trick with this model is that the compatibility shim should
be the first thing to get loaded, so it seems like we might need a
djConfig thing that the package loading could use to know to include
it first. Maybe just djConfig.compatibility: "0.2.2", and that would
pull in src/backwardcompat/0.2.2.js, or something like that.

James



More information about the dojo-contributors mailing list