Hi, > 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).
That was one of the reasons I wrote jsPax. I chose not to use jQuery in jsPax, because I still have some applications that profit from jsPax but don't use jQuery. > This might not be what you specifically need, doesn't mean it's > useless. You are not the only possible user. Of course. I didn't mean anything as an offense. That doesn't keep me from thinking if I can imagine a usecase where your solution is better than existing ones. Actually there is something that is a lot cooler: the fact, that you simply call the plugin functions and don't have to care about that after registration. In such a case my approach would be to see first if an existing solution for something similar could be extended. Of course you can still come to the conclusion, that extending would have more drawbacks than doing it yourself - that's why I didn't use JSAN. > I'm glad you have a good technique to load your jQuery plugins, I > doubt everyone already has one. Of course everyone can use jsPax. Everyone can use JSAN, of course. Of course everyone can use your code as well - no problem with that. > 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. But every developer needs to manage his own database then. The URLs are different for every application. Thus the developer needs to change his database for every application. > 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. It is more that these are concerns I had to spend quite some thoughts to geht them fully solved in jsPax. Christof
