27 Jan
2009
27 Jan
'09
4:43 p.m.
Hi JV,
On Jan 27, 2009, at 4:23 PM, Jean-Vincent Drean wrote:
Hi,
I'm about to commit silk icons so that we bundle them with our webapp.
I want to commit them under xwiki-web-standard but we don't have any
standard place where to put this kind of common resources.
We currently have common resources (js and icons) under the root of
our webapp (yui,xwiki.js,etc) and in the albatross skin (most of
them).
Those resources are independant from a particular skin and thus
shouldn't be placed in one of them (at least imho).
I suggest that we move javascript and icon files out of albatross and
that we introduce a new rule: don't put javascript in our skins.
I don't really agree wit this (unless it's a wording issue ;)). We
should put in standard/web *only* web resources that are common to all
skins. We can have (and should have) js and icons which are only valid
for a given skin.
Note that I'm not suggesting to deprecate our
baseskin mechanism since
being able to use inheritance between skins is a good thing (it allows
to customize only part of the styles).
Proposal 1
========
Tree:
xwiki/
-- resources/
---- icons/
------ tango/
------ silk/
Do we need both icon library? Can't we move to using only silk?
---- javascript/
------ lib/ (we could minimize files in this folder at build time
with rhino)
Why the need for a lib/ subdirectory? XWiki could be viewed as a lib
IMO.
-------- prototype/
-------- scriptaculous/
-------- yui/
------ xwiki/ (files get from this directory would be parsed since
almost xwiki js files contains velocity calls)
Cannot this be decided by the user by using the proper API call?
-- skins/
---- toucan/
-- templates/
-- META-INF/
-- WEB-INF/
Getter methods:
Util.getJavascriptResource(String filename)
Util.getIconResource(String filename)
Why do we need methods for each type of resources? Can't we have a
generic getResource() method instead passing the path, i.e.
getResource("icons/silk/...")
Is it because we want to be able to change the top level location of
resources?
The resources directory would be held by
xwiki-web-standard.
Note that this way of getting resources would prevent overloading of
icons and javascript from the skin (unlike xwiki.getSkinFile).
Couldn't we figure out an algorithm that would allow that?
Proposal 2
========
Tree:
xwiki/
-- skins/
---- commons/
I don't like this too much. Commons is not a skin so it shouldn't be
at that level.
------ icons/
-------- tango/
-------- silk/
------ javascript/
-------- lib/ (we could minimize files in this folder at build time
with rhino)
---------- prototype/
---------- scriptaculous/
---------- tinymce/
---------- yui/
-------- xwiki/ (files get from this directory would be parsed since
almost xwiki js files contains velocity calls)
---- toucan/
-- templates/
-- META-INF/
-- WEB-INF/
Getter methods:
Modify getSkinFile to look into commons after looking into skin and
baseskin (toucan then albatross in our distrib).
If we can do this then we can also do the same for proposal 1 I think.
The skins/commons/ directory would be held by
xwiki-web-standard.
I'd also like to take advantage of this refactoring to remove some
files from the root of our webapp if we all agree:
- JSTrim*
- freemind (unused)
- s5 (moved out of XE 2 years ago IIRW)
The presentation app was moved to the sandbox not that long ago.
+1 for removing these.
Conclusion:
* I'm ok to regroup all common stuff under a single directory
("resources", "common", "base", etc) but not inside skins.
I'd prefer
it to be at the same level as skins/.
Thanks
-Vincent