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

Bill Keese bill at dojotoolkit.org
Sun Apr 9 20:27:32 EDT 2006


Yeah, I think a separate file is better than the same file.

My only hesitation is that we will end up putting in the shim w/out 
really testing it, or we will test it once but then later it will break, 
so I wonder if it's really worth it.  But I know I have the minority 
opinion here.

Bill

James Burke wrote:
> 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
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors



More information about the dojo-contributors mailing list