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 MARGINWIDTH=0 MARGINHEIGHT=0 TOPMARGIN=0 RIGHTMARGIN=0 LEFTMARGIN=0>\n";
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 mattkruse.com. 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 stylings.
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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
