Hi Christof It's certainly better if the developer organizes it's code. Using a package manager, or w/e script fulfills that need. Some frameworks, already are organized into packages, and they usually have a package loader integrated.
Now, jQuery is not structured in packages, it's a core. You could consider the plugins as package, but there's no jQuery module to load them orderly (that I know of). You can certainly just use $.getScript() and there you have your package loader. You worry about the requires and provides. Well, this is just another approach, integrated with jQuery, I don't think it's completely fair to straight compare it with generic loaders. This might not be what you specifically need, doesn't mean it's useless. You are not the only possible user. I'm glad you have a good technique to load your jQuery plugins, I doubt everyone already has one. As for what you replied on plugin registration. I agree that the user doesn't need to know the namespaces. Maybe doing that DB of registrations is one possible solution. As to your example, you don't need to put each one in a script. You can gather all those you need, concatenate and minify them. I doubt it will take more than 2-4kb for around 15-20 plugins. If you have 200kb of code to load (happened to me). I'm sure it's far better to have 3kb initially in one http request, than 20 requests of 10kb or 1 plain call for 200kb. The dependencies system can handle nested dependencies, also 2 plugins requiring the same dependency while it's loading. It can surely fail in some cases, as I said, this is the first release, it was mostly as a proof of concept, to get some feedback. Some of your concerns I consider too specific. Thanks for your comment Ariel Flesler On 6 mar, 06:50, Christof Donat <[EMAIL PROTECTED]> wrote: > Hi, > > > 1- First of all, do you frequently use jspax for your jQuery plugins ? > > no one said this plugin is the first of its kind. > > Yes I do. I have recieved reports from developers that have poblems with jsPax > and IE, but none of their testcases did show their problems for me. For my > part I never have experienced any poblems with it - except for the time I was > developing it, of course. > > > 2- jspax requires you to organize it all in packages, and "require" > > them when the moment comes. It also requires to structure your code > > with callbacks. When you summon a package, you need to pass in a > > callback. I tried that some time ago, it's not that easy and makes the > > code kinda weird. > > Well, weirdness of code seems to be an emotional measure to some extend. > Actually I find, that code that uses jsPax is very well stuctured. If you > don't like the callback stuff, you can use JSAN that loads its packages > synchronously. > > > This plugin requires you to register for the plugins, the namespaces > > they take. You need to specify what functions it adds to $ and $.fn. > > So I as a plugin user need to know which functions a plugin adds? I haven't > written that plugin. I only use part of its functionality. I whant to be able > to replace it with a newer version which might add additional functions. > > I don't think that this is really a so great Idea. > > > @Christof (cool name) > > :-) > > > 2-The code can resolve dependencies, that's the option "require" which > > is an array of ids of plugins required, that is all explained in the > > project page. > > While I was developing jsPax I found out, that resolving dependencies can be > quite tough. I have not read your code in full detail, but are you shure, you > have checked all possible cases (like, e.g. two scripts loaded as a > dependency for a third one both depend on the same fourth script, timing > issues with such situations, etc.)? > > > 3-It should work with all the browsers jQuery claims to fully support. > > No new technique is used here to load the packages, just jQuery. > > OK, I even load jQuery as a jsPax package. > > > 4-The only thing you need for each plugin, is the list of functions/ > > namespaces it registers. > > Well, I may not really have them. I may only have a packed version of a plugin > together with mediocre documentation. For no plugin I have seen so far that > is an issue, but it might be in future. > > What still makes me feel bad is, that in your main script you need to write > down all the function names all the plugins you use provide. In some cases it > might be not much more code to stuff the packed plugin on top of your main > script instead. > > In contrast to that with jsPax I only have to write down the package names in > the main script file - no function names, etc. Of course that means, your > really cool usage of simply calling the needed functions is not possible with > plain jsPax. > > > I could add a link to a list of pre made registrations, that I add as > > I get them reported by plugin owners or users. > > Then you have as many script tags in your head as you have without lazy > loading: > > <script src="jquery.js"></script> > <script src="pluginplugin.js"></script> > <script src="plugin1_registration.js"></script> > <script src="plugin2_registration.js"></script> > <script src="plugin3_registration.js"></script> > <script src="plugin4_registration.js"></script> > ... > <script src="main.js"></script> > > That means, you have to know all dependencies of all plugins. > > > 5-That's a very specific question, this is the first release, a draft > > you could say. I don't think this point has much importance. I could > > for instance check that. But the dev is the one registering, so it's > > not likely to happen. > > Maybe a plugin registeres another plugin that already is registered in the > main script file. I do think that those things will happen. I understand, > that you did take that issue out for the first beta release. For further > releases you should take it into account. > > Christof
