cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: Woody Rant
Date Mon, 24 Nov 2003 19:55:20 GMT
Sorry Antonio, but you absolutely missed my points. I don't want to 
remove JavaScript or HTML, but I want to have good code - maintainable, 
readable, understandable, extendible and so on. Especially having the 
help popups based on the same bad code was one thing I didn't like.

I will answer to some of the other mails in this thread, so I guess my 
thoughts are clearer afterwards. The mail below was a rant and it was 
2:30 AM ;-)


On 22.11.2003 06:20, Antonio Gallardo wrote:

> Hi Joerg:
> Please remember woody is not tight to Javascript in any way. The
> wody-samples-styling.xsl is just an sample of what you can render the form
> and nothing more. You can use it or build your own.
> The current Javascript in the wody-samples-styling.xsl was introduced
> because people often ask about how to include javascript inside the woody
> rendering.
> I think the problems with safari are more related to KHTML problems. KHTML
> is still buggy. I used before Konqueror in KDE. Konqueror use KHTML too,
> but many web pages was bad rendered in KHTML (including the cocoon pages).
> I think this is not a cocoon problem.
> Best Regards,
> Antonio Gallardo
> Joerg Heinicke dijo:
>>It's maybe to late in the night to start a rant, but I will do it. 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 +=
>>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.
>>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". Who wants to
>>maintain the recent code? 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.
> Sometime it depends. If you develop for an Interanet environment, you can
> set easily an standard.
>>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.
>>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.
>>Good night,

View raw message