On Wed, Mar 18, 2009 at 3:29 AM, Remi <remi.pierrard(a)conseiltechno.com>wrote;wrote:
Thanks for you help, i doesn't know this technique
but i do same thing (i
think) overriding stylesheets by the Xwiki.XWikiSkins class...
When i say "from scratch" i heard "in darkness with firebug without
knowing
the tree of stylesheets and their roles". I would love to have a map of "
XWikiskins / toucan / albatross skin ", perhaps because i'm not the real
developper's profile, and because i think it could help me to save lot of
time!!
I think the difference between "my hack" suggestion and the one in
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Skins is that my
approach is simpler, less prone to leaving you with an unreadable site if
you make a mistake, and more immune to changes in the underlying skin as you
upgrade XWiki versions.
The problem with developing from scratch is that you have to develop from
scratch... I prefer standing on the shoulders of giants, and if you take a
look at the CSS involved in xwiki, you need to stand on the shoulders of
giants...
:-) But just like we don't go off creating new organisms from scratch, we
modify existing one's DNA, the same goes for software. It also doesn't help
that there's no formal way of defining, enforcing, or testing the semantics
occurring between DOM/CSS and javascript and velocity... other than poking
at it in different browsers and looking at how it behaves under the
microscope of 'firebug.'
Also, "my hack" can be done "interactively" by editing a xwiki
document
containing the css data, whereas the correct approach requires editing
XWikiSkins in the class editor, or the installation of a skin either as
files at the apache level (assuming you front your xwiki with httpd), or
into the servlet container itself requiring a relaunch for each iteration of
what is supposed to be rapid prototyping. "My hack" enables rapid
prototyping, but is less efficient as it requires all the overhead of an
extra xwiki document (the override css file) getting created or loaded from
the cache for each page.
There's no question that if you're building
http://idiva.com or
http://www.bestventes.com then "my hack" is not the way to go. However, it
might be the way to make incremental changes to the existing CSS before
rolling the changes back into the skin and pushing out a new release.
One question is could the "overriding" approach suggested by "my hack"
be
integrated directly into Admin->Presentation by having an wiki-specific area
in which CSS overrides reside. From there, some of the more common
customizations (e.g. changing the header-image and dimensions, changing the
background fill/color/pixmap, transparency on/off, etc) could be done in the
web-GUI by a wiki-owner, rather than becoming a sysadmin task.
FYI, here's the approach suggested in the documentation:
To start, the best is to copy-paste the original content and make a slight
modification.
If you want to derive your skin from another skin, you should write the
name of the skin to derive in the "baseskin" textfield at the bottom of the
page.
It is possible to modify the other templates. To do so you need to edit the
XWiki.XWikiSkins class using the Class Editor (
http://<yourserver>/xwiki/bin/edit/XWiki/XWikiSkins?xpage=editclass<http://%3cyourserver%3e/xwiki/bin/edit/XWiki/XWikiSkins?xpage=editclass>)
and add a TextArea field that has the name of the template (for instance if
you want to modify viewheader.vm which takes care of the action bar at the
top, you need to create a TextArea field named viewheader.vm)
Once you have make some modifications, you can test your skin by adding the
"skin=Main.MySkinPage" at the end of the URL. For example if you are
creating a skin on <yourserver>, you can test the skin on the Home Page at
http://<yourserver>/xwiki/bin/view/Main/WebHome?skin=Main.MySkinPage<http://%3cyourserver%3e/xwiki/bin/view/Main/WebHome?skin=Main.MySkinPage>
Finally, when you are really happy with your skin, you can apply the skin
to the whole wiki or to a space by modifying the "skin" field in the XWiki
or Web Preferences. You should also modify the default and alternative
styles (If you haven't created alternative styles, put 'style.css' in both
fields)
Niels
http://nielsmayer.com