From: Paul L. <pa...@sq...> - 2007-03-17 20:33:46
|
On 3/17/07, Paul Lesniewski <pa...@sq...> wrote: > > I built a plugin two months ago, called 'javascript_libs'. The purpose > > of the plugin is to: > > > > 1) Provide some popular javascript libraries and frameworks (prototype, > > scriptaculous, lightbox) in an easy to install squirrelmail plugin > > package. > > > > 2) Provide plugins or Squirrelmail core code, with a function that they > > can use to enable the usage of such a library / framework very easily. > > How easily you say? > > > > This easily: > > > > javascript_libs_register('read_body.php', array('spica', > > 'lightbox_plus')); > > > > > > 3) Handle some basic dependencies between libraries. For instance, if a > > plugin wants to use scriptaculous, then prototype.js is also included. > > > > 4) Allow two or more plugins to use the same javascript > > files / libraries, in the same page, but in the end include them only > > once. > > > > > > Unfortunately, as with many things I've layed my hands on, it's not > > finished yet. :/ Specifically, I need to implement duplicate inclusion > > suppression and test how well it behaves when two different plugins use > > the same js in the same page. > > > > Anyway, I'm attaching the javascript_libs plugin and a sample plugin > > that uses lightbox_plus to display an image attachment in this email, > > in order to get some feedback. Do you find it useful? Should we > > publish this in squirrelmail.org? I've coded this with STABLE in mind, > > do you see a different way of including javascript libraries in the new > > template framework? > > I see this as the biggest issue. If you saw in the past, I posted > some code that makes use of the RPC API in 1.5.2, and what I've been > saying around here is that I'd like to nail down a client-side > JavaScript library that knows how to communicate with that RPC API > (which is already in place). I had started to build a SquirrelMail > XMLRequest and associated library with an eye on simplicity and file > size. I haven't had time to finish it (but as I mentioned, I do have > working code), but was planning to look at the innards of things like > Prototype, Spry, and whatever else I found useful, and then take the > best ideas of the bunch and roll our own. I'm not against pulling > Prototype into SM and calling it done, but we should probably discuss Oh, I meant to note that licensing would have to be addressed too -- I think Prototype is licensed under the MIT license... need to figure out how/if that fits with GPL. -paul > (I didn't get any feedback when I posted my original example). FYI, > Prototype is around 70K to 90K, and if you use it with > script.aculo.us, you're looking at 200K, although hopefully the > browser caches these things. > > Now, more specifically about what you are trying to do and how plugins > figure into all this, as of 1.5.2, I think it is a Very Bad(tm) idea > for plugins to implement their own scripting environment. In fact, > I'd have to look, but it may not be possible (or easy) for plugins to > throw up their own JavaScript includes -- this is something that the > skin/template set is supposed to handle. It is probably important to > note that skins/template sets have the ability to turn on and off any > plugins they want -- this was designed into the template engine to > allow skins/template sets to make sure no plugins are used that do not > work with the skin or enhance the skin's own functionality with > plugins that work well with the skin (see how the preview_pane plugin > is used by the default_advanced skin). > > Also, I very much hope (require?) that no plugin does not have a > non-JavaScript fallback functionality, unless, of course, the only > thing it does is add some kind of scripty/visual effect. > > Of course, STABLE is a very different environment than DEVEL, but I am > still weary of the need for plugins to be responsible for adding > this...... although..... mmm.... I suppose it isn't an entirely bad > idea. I definitely don't want to get started on the wrong foot for > DEVEL -- I would be strongly against having any such plugin in DEVEL. > > I have not had time to look at your code yet, but I will try to do so > this week (and please refrain from posting until I can). > > One thing I want to point you to (without having looked at your code, > so I am only guessing that this may help) is that the Compatibility > plugin has a reposition_plugin_on_hook() function that you can use to > resolve the multiple inclusion problem you mentioned. How you use > this tool to resolve your issue depends on what hooks you are already > using: ideally, you would hook the javascript_libs plugin into a very > early hook that is run on all pages, such as config_override (which is > only in DEVEL, so you'd look for loading_prefs probably) and in the > hooked code, simply call this function and request to push yourself as > the last plugin on any hooks it is used on. > > If the ordering of plugins on hooks is such that the above won't work, > consider requiring the plugins who use javascript_libs to reorder > themselves appropriately (or make the reorder part of the > javascript_libs_register() code or something like that). > > > Notes: > > > > * Some javascript libraries might be outdated, I hear there's new > > prototype scriptaculous versions out. > > > > * The sample plugin actually needs a small patch in functions/mime.php > > in order to work, it is included in the tarball. > > > > * I'm coding some major UI improvements in avelsieve these days, and > > I just used javascript_libs to load scriptaculous and add some effects. > > I must confess it looks groovy. 8-) > > Please tell me there is a non-javascript version of the functionality. ;-) > |