cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Refactoring woody styling (was Re: Woody Rant)
Date Sat, 22 Nov 2003 13:40:44 GMT
Joerg Heinicke wrote:

> It's maybe to late in the night to start a rant, but I will do it.

Rants are more "ranty" late in the night ;-)

I hear your concerns an try to turn them into constructive criticism. 
See below:

> The problem I have with Woody at the moment is, that it becomes more 
> and more a client side styling and JavaScript library while it should 
> focus on the server side form processing.
> Especially the JS stuff is ugly and horrible. If I see things like
> result += 
> "<HTML><HEAD><TITLE>Calendar</TITLE>"+this.getStyles()+"</HEAD><BODY

> I wonder why you are doing/choosing/accepting such an approach. How 
> should this work in future? It might work for many cases at the 
> moment, but not all browsers are supported, Safari does even crash on 
> such stuff [1]. You will get more and more bug reports in the future 
> about any JS not working in a browser or a styling not looking correct 
> like [2]. Strict HTML 4 has little problems at the moment, XHTML does 
> not work completely! And I do not wonder about this. Might all be 
> little fixable bugs, but it's not worth the time IMO.

The main reason why I chose this is because of the calendar. I spent 
some time searching for a good calendar, and chose this one for the 
following reasons (in no particular order):
- it displays nicely in many browsers (at least those I work with),
- it isn't bloated with unnecessary features,
- its date format is the same as java.text.SimpleDateFormat, which will 
make it very easy to "propagate" the server-side convertor format on the 
client-side (still to be done, however),
- it's licence is compatible with inclusion in Cocoon's CVS

Now I'm definitely not a cross-browser compatibility expert, and I'm 
open to any improvement, as long as the above requirements are met.

> IMO Woody should re-focus on form processing. Yes, we should provide a 
> default view, but a simple one. If there must be used any JS as I see 
> it for the calendar or the help popups then it should definitely be 
> done the standard way (i.e. W3C DOM) and never using document.write(). 
> We can show nice gimmicks, but not "everything that's possible".

I don't agree with you here: you cannot seriously convince people to use 
Woody if it doesn't provide the minimal "fancy features" that every 
other form framework provides. You won't convince anybody with flat 
inputs. We need tooltips, help popups, calendars, etc. But I also think 
the current field-styling.xsl has reached a size where it must be split 
into smaller units that everybody can assemble depending on their needs 
(see below).

> Who wants to maintain the recent code?

Well, I have to do it since I primarily develop this for my current 
project. But as I said above, I ain't no cross-browser expert, and the 
range of browsers I have to support in the project is limited.

> Is the calendar styleable to get it in Corporate Identity? In 
> contradiction to "all browser support" ("works with Netscape 4.x, 6.x, 
> IE 5.x ...") new stuff like <label/> and <fieldset/> is used, that 
> only works in recent browsers, while for JS you want to support 
> NetScape 4.x.

Yes, the calendar is stylable. Following a recent remark of Leszek 
Gawron (aka "ouzo"), I wanted to remove the calendar stuff that is 
always produced even if you don't use it.

> I also don't like "mattkruse-lib". I thought we have no 
> code-ownership? Mentioning him like @author is absolutely ok, but not 
> that conspicuous.

Well, IMO the notion of "code ownership" as we usually use it here 
doesn't apply in this case: Matt Kruse is not a Cocoon committer, and 
his libraries are available at I named the file after the 
web site name which happends to be also the guy's name. I considered 
this a giving proper credit to someone not involved in Cocoon, but 
there's absolutely no problem with renaming the files if you don't think 
that it's appropriate.

> I don't know if I forget any detail I wanted also to point out. Maybe 
> I can add it in the (hopefully raising) discussion.

Sure. As a first step, I propose to refactor the current woody styling 
into smaller units. This will allow us to separate basic styling from 
advanced styling (something I started to do with page/field styling), 
and allow people to build their own styling with these more granular blocks.

However, we cannot totally remove client-side JS, but the minimal 
requirement is really small. My recent additions led me to identify 3 
hooks where Woody has some work to do in the lifecycle of a form:
- at page load time: the <body> tag must call "woody_onload" in its 
"onload" event.
- at form submit time: the <form> tag must call "woody_onsubmit" in its 
"onsubmit" event
- if some non-input fields submit the form (such as in an "onchange"), 
they must call "woody_submitForm(element)".

These 3 hooks should allow to handle all kind of complex JS-driven 
widgets and styling. The first 2 ones just call event handlers that can 
be registered at any time using the "woody_onloadHandlers" and 
"woody_onsubmitHandlers" arrays.

If we agree on this minimal contract, we can split the styling into 
independent elements that are assembled through includes/imports by the 
main stylesheet. This will allow people to choose which of the provided 
"styling snippets" they want to use, and plug in their own specific 

But once again, I think Woody must come with some decently featured 
styling out of the box, and we must work together to have a robust 
cross-browser solution.

Now, as outlined by Antonio and Bertrand, Woody is a server side 
framework and as such is not intimately tied to HTML. So it would be 
good to provide other stylings as well, as it would make it even more 
convincing. What comes to mind is WML, Word documents or Acrobat forms 
(and OpenOffice?). But HTML is still the predominant target and finding 
the necessary amount of time and energy to write the styling for new 
targets may be difficult if there's not a immediate need (in other 
words, people don't scratch if there's no itch).

What do you think?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message