Forgot your password?
New user?
Document Actions
#139: Standard support for alternate js libraries
- Contents
- Proposed by
- Jonah Bossewitch
- Seconded by
- Anders Pearson
- Proposal type
- Process
- State
- being-discussed
Definitions
Motivation
Resource Registries goes a long way towards allowing third party products to manage and coordinate javascript dependencies. However, with javascript libraries like MochiKit becoming more popular, it is ineveitable that some third party Plone Products may choose to develop using these libraries. Plone may have a preference for what it uses to develop its own ajax functionality, but it should be agnostic with regards to third party javascript development. Trouble is, with popular libraries emerging, it is only a matter of time before multiple products begin wanting to install the same javascript files.
Plone should consider shipping with these libraries, which could be enabled optionally when needed to mitigate the inevitible conflicts that may arise if these libraries are not standardized on. No matter what, some strategy should be devised so that product developers using these libraries do not stomp on each other or conflict with each other.
First, libraries like MochiKit need to be installed under a common key in the registries, or else mulitple copies of the libraries may end up being managed. Second, these libraries come in different versions, and third party tool developers should be writting against the same version of these alternate libraries, or else some applications may end up needing to ship multiple versions of the same libraries.
Proposal
Ship with a MochiKit redistribution. Allow for the Product (or maybe even just a skin) to be optionally installed when specified as a dependency by a third party product. If this doesn't happen, things might start getting chaotic soon.
Re: size
Yeah, I suppose it might suck to download both Prototype and Mochikit. But it would suck even worse to download Prototype and 2 copies of MochiKit. Or Prototype and 2 copies of Mochikit of different versions which break each other.
This should be addressed, perhaps by convention (store Mochikit under foo key in the resource registry, and prefer a particular version, all other considerations being equal). And is download size of Plone really a problem? Ship with it, and only enable it if a Produce depends upon it?
Alternatively, create a razor thin MochiKit Product in the collective which is nothing but a skin containing MochiKit and an installer to put it in the right place. T hen, products using MochiKit can at least depend upon the same one. This could do most of the trick, but people need to know about it.
/jsb
Plone own js code
I've digged into MLs and Plips but didn't find any info or ongoing work about this.
all js functions in plone could have a top-level namespace like 'plone', then nested namespaces for each functional area for instance. This would avoid name conflicting with other javascripts and provide a self documentation.
Size
I would prefer if Plone only shipped with one framework and preferred that framework. I'm not sure how realistic that is, though, given that there's not so much consensus in the community about which is better. Bling uses Prototype/Scriptaculous, Kukit uses Mochikit. I'm sure there are other choices as well.
We need to discuss this more than anything, and let evolution work to discover what's best.