This is a very clever approach to what will become a serious problem
for jQuery, the management of dependencies.
Playing around with YUI and YUI ext, it seems like to use a
signicant control like the grid, you must include huge swath of each
library, but not the entirety. The time it takes to figure out what
you need, exactly, would be better spent coding. Upgrades that
require new components will appear as bugs, and not dependency errors.
What drives the adoption of langages like Perl and now Ruby is the
ability to evaulate a new package quickly, and that is done by
pulling all the dependencies automatically.
A convention about plugins that runs the gambit from runtime
inclusion to deployment dependencies, with a jQuery Repository of
plugins, is an investment that pay for itself in new adoptees.
The trade off of speed versus size is ancient. There is no good
answer. It either leans toward speed or leans toward size...
..or else it leans toward tools. You could use a preprocessors and
choose between algorithms.
* Paul McLanahan <[EMAIL PROTECTED]> [2006-11-17 10:23]:
> Agreed. We need two new standards.
>
> 1. @requires in the docs format, which would only require a change in
> the API generating code to have it look for that (if it doesn't
> already).
> 2. A standard way and convention for specifying version numbers for
> plugins which can be read by the docs, and preferably by the JS
> itself.
>
> I'd like for the version to have a standard location and convention in
> the code of the plugin so that I can throw an error in my plugin if
> the dev has made a mistake by including an old plugin (or none at
> all). I'd rather alert during development, then have an obscure bug
> show up in production. I suggest something like:
>
> // inside block context
> var plugin = $.fn.myPlugin = function(){
> return this.each(...);
> }
> plugin.version = '0.0.1';
>
> or
>
> jQuery.fn.myPlugin = function(){
> arguments.callee.version = '0.0.1';
> return this.each(...);
> }
>
> Having it in the documents comments would be good as well so it can
> show on sites like visualjquery.com... but I think it would be quite
> advantageous to be able to require version 0.0.1+ in the code. Though,
> we would need a function to check version depending on the agreed upon
> version numbering scheme.
>
> I also agree with the recommended/custom approach for the download.
> People with the tools and knowledge are doing this now with the build
> system. Copying that system online (much like Corey did earlier in the
> thread) would be an excellent way for those with special needs for
> bandwidth or functionality to get their wish without having to install
> ant. Don't have the system on the download page, but have it linked
> from there.
>
> On 11/17/06, Stephen Woodbridge <[EMAIL PROTECTED]> wrote:
> > Jörn Zaefferer wrote:
> > >> jQuery documentation should clearly illustrate which base / core
> > >> jQuery is required and dependencies should be illustrated in a
> > >> clear manor. I think the php pear site exemplifies this, i think
> > >> this is mostly covered but could be a touch clearer.
> > >
> > > PHP PEAR is a bad example: In most cases you won't care about 5 or 50
> > > additonal php files on your server, but you can't do this with js
> > > files.
> > >
> > > I think the recommended/custom way is a good approach: API
> > > documentation and tutorials are all written with the recommended
> > > version as their base.
> > >
> > > When a single plugin has dependencies on another plugin, it must be
> > > explicitly stated somewhere. A package/requires system that
> > > automatically resolves those dependencies would be nice, but I don't
> > > think this should have a high priority.
> >
> > I would agree with Jörn, and expand that I think we need to require
> > plugins include a:
> >
> > @Requires: blahblah.js[, version: 29+]
> > @Requires: morestuff.js
> >
> > We are rapidly getting a large number of plugins and more and more of
> > them seem to be using other plugins which is really good. This will help
> > users figure out what plugins and versions they might need and it will
> > supply the info needed for some future package system to figure this out
> > also.
--
Alan Gutierrez - 504 717 1428 - [EMAIL PROTECTED] - http://blogometer.com/
Think New Orleans - http://thinknola.com/
_______________________________________________
jQuery mailing list
[email protected]
http://jquery.com/discuss/
