Forum OpenACS Development: Suggesting a convention for managing external JavaScript and CSS frameworks

Hi all,

in many OpenACS installations I run across, external JavaScript libraries like JQuery or YUI reside either in the global /www/resources directory, or within the www/resources directories of the package that utilizes the library. For example, XOWiki (HEAD) ships with a JQuery file. Also the resources inside the ajaxhelper package are often used, as this package contains a range of JavaScript libraries.

Obviously, this is not the biggest issue. However, the current situation (no best practice; ajaxhelper as the only "solution") supports creating a mess in an OpenACS installation.

From a developers point of view (more precisely "from my point of view"), there are typically two main needs a developer wants his web framework to meet, i.e. a simple approach to

* include the latest version of <library>
* include a specific version of <library>

Therefore, I want to bring the following suggestion up for discussion: What do you think about the following simple approach to handle external JavaScript and CSS frameworks:

1) Create an OpenACS package for each framework
2) Create a directory for the frameworks version under /packages/<library>/www/resources/<version>
3) Create a linux shortcut /packages/<library>/www/resources/current to the latest version
4) Unpack the framework (as is comes from the vendor) into the versions directory
5) Preserve older versions of the package
6) Optionally, provide some unified TCL API

Consequently, a developer who wants to use jquery in his package, would simply put a

<requires url="jquery" version="1.0"/>

into the .info file of his package, and use statements like

::template::head::add_javascript -src "/resources/jquery/current/jquery.js"
::template::head::add_javascript -src "/resources/jquery/1.2.3/jquery.js"

I am aware, that this short proposal does not tackle every aspect of the topic. There are numerous questions, which can make this thing more complicated again (How to link the frameworks version to the packages version; how to handle frameworks, which dont work when included more than once (in different versions); how to handle dependencies or exclusions (e.g. if JQuery doesnt work with prototype.js), ...) ...

However, I think following this approach (a package for each framework) is a "safe first step" and would make it easy to reduce the mess immediately. Further fancy improvements (e.g. discussing a "general proposed api", like ::<library>::add_to_head or ::<library>::get_current_version) could still be made later on.