9 Jan
2011
9 Jan
'11
4:12 a.m.
On 01/05/2011 01:21 AM, Andreas Hahn wrote:
Am 04.01.2011 17:28, schrieb Sergiu Dumitriu:
Hm, I might have sounded a bit harsh, but I wasn't, I was simply voicing
my opinion. Look, I'm friendly:
:)
On 01/03/2011 11:47 PM, Andreas Hahn wrote:
Sergiu, thank you for the time you've taken for your answer. I can
hear
your haertbeat. Am 28.12.2010 16:13, schrieb Anca Luca:
As Anca
said, you can add classnames to any portion of text with (%
class="..." %)((( content here ))), and the macros for which a classname
makes sense do usually have such a parameter.
Hi guys,
Short story:
Where to put the css which is needed by java macros (e.g. the columns
layouting of the container macro)
1/ in colibri.css
2/ in a .css included on demand by the macro
a) from platform resources (using ssfx)
b) from the jar (using ssrx)
c) from an object in a page with ssx
3/ refactor the skin concept and create a 'platform css' to store all
these and not be affected by skin customization.
Long story:
I can see I've caused the web standards tests to fail for the trunk
(http://hudson.xwiki.org/job/xwiki-product-enterprise-tests/org.xwiki.enterp…)
because of the inline style attributes used by the columns layout of the
container, whijch is now used on the main page.
Now, I would like us to agree about where to store the styles needed by
the java macros to work right, such as the container macro with columns
layout. The options I see are:
1/ as until today (e.g. box macro, warning, error, info, etc), in
colibri.css/toucan.css/otherskinwehave.css. I don't like this solution
too much because it means that when another skin is used, things won't
work anymore unless the person writing the new skin takes care of
copying all these "things that must be there". The advantage of this is
having a single .css file to load on page load, the disadvantage being
that their css is loaded on all pages, regardless of it being used or not.
2/ loading of the styles on demand, each macro loads its style when it
needs it
a) from a .css file located in the platform resources, which the macro
has to include using the ssfx plugin when is executed -- much like a
wiki macro would to with a ssx.
b) from a .css file located in the macro archive (using ssrx), which the
macro includes when executed.
c) from a ssx page
c) has the advantage of being very very much more easy to change than a)
and finally than b) which is the hardest to customize. But on the other
side c) means the java macro depends on a page, which is not that good.
Note that "cascading" customization is possible for all these choices
(adding an extra css with rules to overwrite the rules in the default
css for the macro) and that in my view, it's enough, since the idea is
that the layout should be preserved no matter what (e.g. a user might
want to add a red border to the columns, but not make the columns
display as two paragraphs instead of two columns).
3/ refactoring the whole skin thing and creating a "platform" css, which
contains things that should work regardless of the skin used. Pros: it's
an adaptation of the current approach (1/), that solves the problem.
Cons: takes longer, might be very hard to separate what's platform and
what's skin.
These being said, I think I prefer 2/ if 3/ is not realistic, and for
the container macro at least, I would prefer to implement 2b).
Hi devs,
as an Xwiki user for about 2 years I'm not so deeply familiar with all
the nuances of styling capatibilities - ssx ssfx ssrx and all the like.
However this is an important topic and I would very much like to see
that XWiki would move toward a styling architecture comparable to that
of wordpress and other popular 'social publishing' tools so that it
becomes easier to customize the look and feel of a site.
I am aware of the contradiction between either offering components that
are fully self supported - meaning macros and style bundled somehow
together - and offering flexible code templates with separate styling (css).
As an example the ColumnMacro and its successor: the Container macro.
Both are IMHO a misconception leaving out the obvious solution.
The colum macro (java) is limited as it uses hardcoded inline styles.
This makes almost any useful layout modification impossible - ok you
might rewrite the .jar but that's beyond what most people are capable
and willing to do.
Same with the container macro: To modify the Layout you should really
write an implementation of LayoutManager ?
Someone must be kidding there - that's total overkill.
Why not just pass a parameter - say cssClass to such a macro (as it is
the case with other macros) for example the 'box'-macro. That's useful
because it can be easily customized and you can provide an own class
name and associated css.
IMHO it would be much more benefical if there were a style guide for
writing macros or templates making a small set of parameters mandatory,
for example the 'cssClass' and maybe an 'id' parameter. So if the parameter is not supplied you might go
ahead with some
internal or bundled styling (a default .css file) otherwise it might be
overridden.
I think there is a general risk thats XWiki is falling behind other
platforms because of the lack of design standards allowing designers to
customize solutions in terms of look and feel.
No, that's not true. Let me get
this straight: *It is much harder to
style WordPress or other "popular" frameworks than XWiki*.
And I mean that without any tutorials, samples or tools, styling XWiki
is much more flexible, and much easier. The advantage of popular
frameworks is that they are more popular, with much more users, much
more interest, and an already established market.
1. When you style WordPress, you don't write a CSS file for it. You
write the full frontend, from<html> to</html>, and you're forced to
respect their requirements: "you must call this PHP function to display
the login/logout section, you must call this PHP function to display the
panels, ...". In XWiki you write as much code as you need, you can start
with just a color theme (for which there's a nice WYSIWYG wizard), or a
SSX object, or a Skin document with overridden templates attached to it.
Sure, you can go low-level and write a full skin on the filesystem, but
that really should be avoided unless you need a major interface overhaul.
2. Installing a theme for all those PHP applications is hard. Sure, they
make it sound easy, "download the zip, extract it, put it in this folder
on the server, change this configuration file". Installing a proper
XWiki theme could be as simple as selecting a xar from the future XWiki
app store. We don't have support for .xar extensions in the extension
manager yet, but it will be available in 3.0, and during the 3.x cycle
we'll build a very user friendly extension manager. And we don't have
such easy to install skins yet because nobody provided one yet. The core
developers don't have enough time to write extra skins when the users
are complaining about core functionality. And the users aren't
contributing their skins back in the extensions.xwiki.org repository,
although I've seen spectacular skins on top of XWiki out in the wild.
3. XWiki is not a blogging software, it is a *Development Platform*.
This means that you can't style XWiki, you can style the generic layout,
and then you can style different components. We're adding new macros all
the time, and users can develop whatever application they want, so we
can't make a style for *everything that ever was and will ever be
running in a XWiki instance*. Thus, given the extraordinary flexibility
that only XWiki provides, we're doing pretty well when it comes to styling.
4. To help overcome a bit the many degrees of freedom mentioned in 3,
we're providing several tools. The most important one is the color
theme, which allows to style components in a consistent manner with the
global skin. Then there are all the skin extensions plugins that allow
to develop standalone components/applications which bring their own
style, of course closely integrated in the current theme, since they're
using the color theme. Then there are the standards that we've been
creating and documenting, like
http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms and
http://platform.xwiki.org/xwiki/bin/view/DevGuide/SpecialCSSClasses
which should help users (and committers as well) create extensions that
fit well inside XWiki. And we're planning more for the future.
5. Let me repeat that: XWiki is not harder to style than other popular
frameworks. There are so much more skins to use or buy for them simply
because there's a well established market for them. Simple users can't
easily write a skin for WP, but they can easily find an existing one to
download for free or for money. That's not a merit of the technical
aspects of WP, but of the community and market size.
> Don't get me wrong - I do like XWiki and its concept much - what worries
> me is that it is simply too much work to customize a site design that
> compares favorable with wordpress sites and others.
>
> regards
>
> Andreas You are right to some extent from a technical point of
view.
I'm operating XWiki for a couple of customers for our other consulting
business as a documentation platform.
No need for great designs - all are happy - they will go with what we offer.
Now I'm trying to set up another service in an area where we need to
catch attention.
It should be good looking - it should be distinctive - it's sort of
personal dedication: budget is small.
I don't agree with your conclusion that with WordPress
"*It is much harder to style WordPress or other "popular" frameworks
than XWiki*"
because for Wordpress you buy a tool like Artisteer for a few bucks to
do the job.
If you need a more individual solution you call for a tender on a market
place like 99designs.com.
Right, you either:
- get someone else to do it, which doesn't imply that it's easier to do
it for Wordpress, just that there are more people that do skins
- use a third party tool to help you with it, but that tool has nothing
to do with how hard or easy it is technically to style Joomla or
Wordpress, just that somebody took the time to provide a nice UI to hide
the messy details.
I haven't tried Artisteer yet, but looking at their demo, something
similar can be done for XWiki as well, just that nobody did it yet.
You say "I've seen spectacular skins on top
of XWiki out in the wild."
Could you name one or two (other than XWiki.com) that is publicly
accessible and compares favorably to one of the many custom WordPress
desings ?
The XWiki testimonials are not a real help they are either ugly or outdated.
A quick Google search gave me some results; they aren't necessarily
beautiful, but they are very diverse and can show that XWiki can be
changed drasticly if you want to:
http://www.spagoworld.org/
http://www.alenty.com/
http://www.curriki.org/
http://www.aelia.com/
http://www.espritsdentreprises.fr/
http://www.uaic.ro/
http://www.info.uaic.ro/
http://www.cinquiemesens.com/
http://www.socracy.org/
http://www.easybeans.net/
https://eu.globotraders-tahiti.com/
https://eu.hotelkiaora.com/
http://wiki.jonas.ow2.org/
http://www.antoniogoncalves.org/
http://i2geo.net/
https://wiki.noiv.nl/
https://www.goldenboysbet.com/
http://hub.opensolaris.org/
http://nepomuk.semanticdesktop.org/
http://www.ow2.org/
http://www.caast-net.org/
Plus, working for XWiki SAS I've seen lots of good looking designs
implemented as intranets, thus not public.
I understand what you are saying about a XWiki as a
development platform.
Question : Have you ever played with a tool like artisteer ?
I am sure you haven't. You should download the demo from artisteer.com
and look what it does.
Yes, but the ease of customization is actually a feature of Artisteer,
and that's shows nothing of how easy it is *internally* to create a
custom skin for the supported platforms. You don't know how many days or
months did the developers of Artisteer spent on making their tool
support each framework. Don't blame XWiki for the lack of support in
Artisteer, and don't praise WordPress for the existence of Artisteer.
I do agree that it would be nice to have such tools on top of XWiki, but
the platform developers have little time to work on one, and third party
companies didn't get enough requests to see the benefit of writing such
a tool.
Part of the problem is also the main target of the software.
The average WordPress installation has only one user, so there are
hundreds of thousands of WordPress instances, thus the request for so
many skins. The average WordPress user has NO knowledge of CSS, thus
most of those WordPress owners will buy a skin, either already made, or
designed in a visual tool. Thus, there's a huge market for WordPress skins.
The average XWiki installation has hundreds of users (the name, "XWiki
Enterprise", already defines the main target), thus the number of
installations is much smaller. Then, XWiki is usually installed by the
IT department of a company, or by a contractor, which IT
department/contractor knows how to play with CSS, this is their job.
I want to clarify that I'm not saying that you
should make XWiki
compatible to some individual tools.
But- what Artisteer does is that you can design the layout of a WebPage
- no matter if powered by WordPress or Joomla or Drupal by a couple of
simple steps
Header, Left, Right, Menu ...
The same can be done by the Color Theme Wizard introduced in 2.3, did
you try it?
http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise23#H…
The image selection is not very nice at the moment, it was left as a
TODO, but it's already flexible enough. It can be further improved, and
any contributions are welcome. Still, this is more than most other tools
provide *By Default* in their standalone installation, not as a third
party, non-free application.
And I'm really pissed that my 17 year old son
produces with a couple of
mouseclicks a smarter design than I will ever do in a day or two and it
seems such a bareer to join this creative output with an XWiki installation.
Ok, I'm sorry so much to say still left but I must come to an end now -
notebook battery is going low - and I need some sleep now.
If you like we might have a talk on skype - it is not so time consuming
as detailed mails.
kind regards
Andreas
Friendly,
--
Sergiu Dumitriu
http://purl.org/net/sergiu/