Does it make sense to consider Curriki's need for extending Javascript and templates a "use case" for the proposed Xwiki skin extensions and interface extensions? Curriki represents a real-world case of needed extensions to the Xwiki platform, and it would be nice if the Skin and Interface extension design covered some aspects of Curriki's extensions. Another way to put it is to "refactor" some of Curriki's UI extensions out of Curriki and back into the platform via these extension plugins. In addition to Skin extensions, interface extensions, what about back-end extensions, which also seem to be needed by Curriki? It would be synergistic for Curriki to be able to use the design/functionality discussed here, for a more "standard" way of doing UI extensions; I'm sure Xwiki would be enriched by making some of the curriki UI extensions available as platform functionality. Comments? -- Niels. http://curriki.org PS: while we're at it, also consider a automatic means of having each space or group of spaces be able to create a single-file for the CSS and javascript associated with the space(s). It is very inefficient to be have each page-view also potentially cache-check&DL a slew of files. Furthermore, there is no need for a static CSS/JS file to be served through Java. So there ought to be a way of having all the fragments "compiled" (or rather catenated with removal of duplicates) as a file that can be served up directly by apache httpd, rather than yet another unecessary servlet invocation that forces the garbage collector to run in tomcat.... On Wed, Apr 30, 2008 at 4:57 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: