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 <[email protected]> wrote:

Jean-Vincent Drean wrote:

...

Hi XWikiers

There are open question about the new skinx plugin, I'd like to discuss about the first one : http://dev.xwiki.org/xwiki/bin/view/Design/SkinExtensions#HUsage "Should $xwiki.jsx.useFile("filename.js") work for files located on the disk? This allows the same pull process to be used with files located in the skin, without requiring SX documents and objects. I'd say yes. Then, what should the URL look like? /xwiki/bin/jsx/skins/albatross/somestyle.css is OK?"

We definitely need this to be able to load some libraries condditionaly, for example usersandgroups.js or lightbox.js. I don't see the need for some special URLs, would it be a problem that useFile() adds the result of a xwiki.getSkinFile() to the header ?

Wouldn't it be better to NOT have this kind of files on the filesystem? Instead, every optional thing would be a SX document. Some pros and cons:

+ they can be easily reused between skins + if they can't be reused between skins, then they clearly show a bad design of either the skin or the component + no need for two API methods + easy configuration for the cache policy and parsing option + grouping several files in a "component", not just some other files in the skin directory - upgrades are a bit harder, as it isn't enough to just unpack the new version and point it to the old database - too much granularity? Or is that a +?

Right now I'm in favor of creating a new type of modules in our source repository, let's say xwiki-platform/xwiki-components, and move there things from the albatross skin. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs