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 20:00:06 GMT
On 22.11.2003 08:55, Antonio Gallardo wrote:

>>>....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 haven't looked at the latest Woody stuff so I cannot comment on the
>>details, but I'm with you here: the "basic" samples should use as
>>little javascript as possible, it is always possible to provide other
>>"browser-picky" samples which show a nicer face using javascript.
> I think we can make another set of woody samples without any javascript code.

I didn't proposed this. I wanted to have standard based JavaScript (e.g. 

>>The last thing we want is users thinking that Woody (soon Cocoon Forms,
>>remember) is dependent on client-side javascript, we know it is not the
>>case but I'd hate it if the samples conveyed the wrong idea.
> The feel I got from the GT2003 conferences was (I saw it thanks to
> Stefano): some people thought woody is HTML related and this is not the
> case too. AFAIK woody is independent of the final rendering of the forms.
> The current samples using javascript are just showing how easily woody can
> interact with javascript in a nicer way. That is all. Maybe a "note" about
> this in the samples is enough. The use of javascript in servered pages is
> a reality now:
> For me the idea of showing woody rendering with javascript show people how
> far they can go using woody. It is just an example in favor of woody and
> Cocoon.

Of course HTML forms are the most used ones. Providing any other samples 
like XUL or maybe PDF forms are nice and show the potential, but they 
never get that propagation. HTML is okay, JavaScript is okay.

>>Don't get me wrong, what's currently happening with Woody is great! But
>>as Cocoon is using javascript server-side already, we must be careful
>>to get the right message across.
> I think they are 2 separated beast. It is like we will make some demos of
> XSP using Java applets. I think people will not got the message:
> XSP can only works with applets.
> In this case both are Java based as an analogy to javascript based.
> Webapp are good, but many people stay away of them because they don't want
> to lose what they got with FAT clients. This is a fact. If not, what is
> the idea behind "Java applets", JME or "mobile java" and related
> technologies? Is they are all related attempts to reach the level of
> currently FAT clients on an average desktop PC while having all the
> advantages of web techno? I think this is the case. Often this is hidden
> by speaking about:
> More functionality, reacher clients, etc.
> So I think the javascript samples in woody are good, they show people out
> of the box the power of Cocoon and Woody. But javascript is not a must,
> this is not a casuality the related woody-samples-styling.xsl has the word
> "samples" in between his name.

Seems to be a bit off topic ...


View raw message