I've been working on a package for jqplot integration in Plone. The way I set it up (which may be wrong, this is why I'm adding this to the conversation here), is that the package is called blitzen.plone.jqplot (when I go to release it, I'll probably call it collective.jqplot or plone.jqplot or something like that). Anyway, the package has two purposes: first, it registers the jqplot javascript with plone, and then it provides a simplified API for other products to use. In addition, it registers a browser view that demonstrates the API.
So given your logic here, should my package be two packages? Three? One for just the javascript (collective.js.jqplot), and the other for the abstraction library (blitzen.plonejqplot or collective.jqplot, etc)? Another for the demo browser view? I think this may be close to the use case Johannes had in mind originally... JJ -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Matthew Wilkes Sent: Friday, July 09, 2010 4:47 PM To: Martin Aspeli Cc: [email protected] Subject: Re: [Product-Developers] namespace collective.lib.* On 2010-07-09, at 1727, Martin Aspeli wrote: > -1 to collective.js.* too, by the way. :) *holds his hand up to this one* I made the first of these, the logic was that we wanted a setuptools compatible way of distributing javascript with some way of getting to it easily from Zope/Plone. Calling it js.* would have been egocentric as other frameworks might well want to do the same. Of course, they are welcome to add non-zope things to collective.js.* as long as it doesn't break it for us, in which case collective signals where they can go. collective.jquery wouldn't work either, as we wanted this to be very much lightweight packagings, no integration beyond exposing the files. Imagine TinyMCE, if it were in the collective it would be collective.tinymce as it has lots of configuration that is exposed in plone. It may well also be collective.js.tinymce for the stock js that TinyMCE release, but that's probably overkill. Managing it like this makes it easy for us to see at a glance what version of various JS libraries we're using, for end-users to override those versions without fiddling with Plone's core JS and to prevent multiple inclusion of libraries. It also makes the licensing clearer, which is nice. I'm thinking about proposing a PLIP for 4.1 to move the actual JS files we use into this structure, but would be interested to hear from end-users as to if they think this would be useful to them. Matthew _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
