1 May
2008
1 May
'08
10:30 p.m.
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:
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs