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
