[wp-hackers] Include popular libs with a function
dstewart at atl.lmco.com
Mon Aug 21 12:51:54 GMT 2006
-----BEGIN PGP SIGNED MESSAGE-----
Sean Hickey wrote:
> That only solves one problem. That still means every developer needs
> to include the libs with their plugin. That still means a developer
> will write a plugin that uses Prototype 1.4, and another developer
> will write a plugin using Prototype 1.3. Both libs will be included
> in the document's head, which is wasteful, and adds extra seconds to
> rendering the document.
> If developers stuck to using what was already included with WordPress,
> we wouldn't have that problem. But since nothing is included with WP,
> everyone is forced to home-grow a solution.
> This is also about breaking the cycle of reinventing the wheel. I
> don't know about you, but I'm getting tired of rewriting the same
> code, over and over again, each time I create a plugin. It's getting
> to the point that I can write half of the plugin's code blindfolded,
> because it's the same code I have to keep writing into every plugin,
> and I've done it a dozen times.
> When you have a situation like that, it's time for the WP devs to step
> back and take a good hard look at the API. Find out what the most
> comment tasks are in plugins -- like creating menus or Ajax enabled
> plugins -- and build an easy to use framework to streamline those
> Including a few more of the common JS and PHP libs helps. Creating
> some additional functions/classes to streamline plugin development
> also helps. Simply exposing the core API isn't enough to satisfy most
> developers. Some code needs to be written/included specifically for
> them to use.
I think you may be confusing a few issues here.
WordPress has to this point largely hewed to a UNIX-ish design
philosophy: be good at one thing, but leave your interfaces open so that
others can supplement/complement you easily. ("Everything's a file. |
is your friend." etc.). Tossing in libs that WP core doesn't use
inherently violates this mode of operation.
It's not up to the WP devs to be psychic enough to include and keep
track of the largest JS packages out there (I'd particularly argue
against Dojo being included, as it's fairly heavyweight compared to
Prototype and its derivatives). With Snoopy, TinyMCE, dbx and Prototype
now in core, I would make the claim that additional inclusions would
introduce undue burdens and potentially incur additional support
burdens. Including those packages makes for even nastier regression
testing (wait, what? We DO that? *grin*) and will likely add to the
IRC and forum traffic.
What I would hope would develop as a solution to your stated issues with
NOT including Dojo, et al, is the following: authors developing
WordPress plugins wrapping up/containing the JS libs and loading them
via the new Script Loader interface. (See
http://www.silpstream.com/blog/wp-scriptaculous/ for a pre-Script Loader
example) Then, politely request that plugin authors using JS libs take
a look at the JS package plugins available out there before they go
including another copy of Scriptaculous.
Just my (2 Euro/100) * (current exchange rate in USD).
Senior Systems Administrator/Web Applications Developer
Lockheed Martin Advanced Technology Labs
dstewart at atl.lmco.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the wp-hackers