You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jh...@virbus.de> on 2003/11/22 02:24:09 UTC
Woody Rant
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 +=
"<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.
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.
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,
Joerg
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106941742522128&w=2
[2] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24900
Re: Refactoring woody styling (was Re: Woody Rant)
Posted by Stefano Mazzocchi <st...@apache.org>.
On 24 Nov 2003, at 21:30, Joerg Heinicke wrote:
> On 22.11.2003 18:30, Ugo Cei wrote:
>
>> I'm with you here. Let's face it, what people are and will be using
>> Woody for is mainly HTML forms, and there's no way you can make a
>> decent form-based application without *lots* of DHTML code.
>
> But the current code is not DHTML, but document.write().
Excuse me, but what's the difference? I think I'm missing your point
Joerg.
--
Stefano.
Re: Refactoring woody styling (was Re: Woody Rant)
Posted by Joerg Heinicke <jh...@virbus.de>.
On 24.11.2003 22:32, Ugo Cei wrote:
> Joerg Heinicke wrote:
>
>> I'm with you here and would even not add a simple stylesheet. People
>> adding simply a guestbook won't use Cocoon, so it's more or less
>> useless effort. Cocoon Forms has "higher aims" :-)
>
>
> Sorry if I misunderstood you, but your sentence on "focusing on server
> side form processing" is the only thing I take issue with. As for the
> rest, I'm happy that we fully agree.
Focussing does not mean ignoring the rest. Woody is a server-side form
framework and so there should be the focus. We must provide a nice
default implementation of client side code, i.e. styling. But this
styling should not take to much effort and time. I had the impression
that it took to much in the last days/weeks, esp. as such a library like
the calendar is/has to be maintained and was extended by help popup
while this is in my opinion useless with the background of no being
future-safe for example for XHTML. I simply could not understand why we
put that effort into such outdated stuff while other work has also to be
done => re-focus.
Joerg
Re: Refactoring woody styling (was Re: Woody Rant)
Posted by Ugo Cei <u....@cbim.it>.
Joerg Heinicke wrote:
> I'm with you here and would even not add a simple stylesheet. People
> adding simply a guestbook won't use Cocoon, so it's more or less useless
> effort. Cocoon Forms has "higher aims" :-)
Sorry if I misunderstood you, but your sentence on "focusing on server
side form processing" is the only thing I take issue with. As for the
rest, I'm happy that we fully agree.
Cheers,
Ugo
Re: Refactoring woody styling (was Re: Woody Rant)
Posted by Joerg Heinicke <jh...@virbus.de>.
On 22.11.2003 18:30, Ugo Cei wrote:
> I'm with you here. Let's face it, what people are and will be using
> Woody for is mainly HTML forms, and there's no way you can make a decent
> form-based application without *lots* of DHTML code.
But the current code is not DHTML, but document.write().
> For example, in my
> current project we have forms with hundreds of fields, and having tabs
> is a huge usability improvement. So much that for an early prototype we
> developed our own "tabs" script on top of JXForms, but as soon as I saw
> Woody's tabs I threw the prototype away and restarted from scratch.
>
> If there are problems with the current implementation, let's fix them
> and provide a standards-compliant DHTML-based toolkit for those who need
> it (like me ;-) ). If we want to create the best web application
> development platform in the world, we cannot provide only a server-side
> solution and tell people to do their homework on the client side. This
> isn't going to sell.
I don't want it. But we should provide standard conform default client
side code.
> Let's not just provide something for the lowest common denominator
> (a.k.a. Netscape 4.X).
Exactly.
> We could do a simple stylesheet for people who
> just want a plain registration form for their guestbook, but I'd
> question the appropriateness of using Woody for that, the
> FormValidatorAction would work much better.
I'm with you here and would even not add a simple stylesheet. People
adding simply a guestbook won't use Cocoon, so it's more or less useless
effort. Cocoon Forms has "higher aims" :-)
Joerg
Keeping JavaScript out of the HTML (was Re: Refactoring woody styling)
Posted by Steve K <sh...@mm.st>.
If the goal of Woody is to include some rich client side functionality,
I would like to throw my two cents in with a little experience I've had
implementing something similar. I created a form framework that
required some support for non-standard HTML widgets, for example, a
multi-select drop down (MSDD). I also wanted to keep the javascript
code as separate as possible so it could be easily maintained, and make
it easily reusable so having many MSDDs on one page would be trivial to do.
What I wound up doing is implementing the controller code for the MSDD
as a JavaScript class. The class would take references to the three
elements participating in the UI of the MSDD (a select box to handle the
actual selection, a text input field to show the comma-separated list of
selected items, and a button to toggle the appearance of the select
box). It would then dynamically attach the various event handlers to
the UI elements to methods in the class. This way the controller code
remains loosely coupled with the HTML -- there is no need to attach
onXXX attributes to the HTML elements. This also allowed me to keep the
class in a separate source file to be included via XSLT or a client side
<script> tag.
In retrospect, one thing I would probably do differently is have the
javascript dynamically create the additional UI elements needed for the
display of the MSDD (text field, button). This way a browser that does
not support javascript would only see the select field and not the
additional elements needed to produce the MSDD effect.
So the form's xslt would have to do 2 things. First, see if there are
any MSDDs in the form, and if so, include the MSDD class either directly
or produce a <script> tag that includes it:
** Note that these code samples taken from the XSLT of my custom form
stuff and are not intended to have anything to do with woody **
<xsl:if test="form:fields/form:field[@style-hint = 'multidropdown']">
<xsl:call-template name="multidropdown_js"/>
</xsl:if>
Second, it needs to create an instance of the class for each use of the
MSDD. So the following code would have to be generated for each MSDD
element in a place that would be executed on load:
<xsl:for-each select="form:fields/form:field">
<xsl:if test="@style-hint = 'multidropdown'">
var <xsl:value-of select="@name"/>_multidropdown = new Multidropdown(
document.getElementById("<xsl:value-of select="@name"/>_input"),
document.getElementById("<xsl:value-of select="@name"/>_button"),
document.getElementById("<xsl:value-of select="@name"/>")
);
</xsl:if>
</xsl:for-each>
And finally, I'll leave you with the implementation of the MSDD class.
I hope that this can be of use to someone :)
<xsl:template name="multidropdown_js">
<![CDATA[
function Multidropdown(p_input, p_button, p_select) {
var input = p_input;
var button = p_button;
var select = p_select;
this.visible = false;
this.that = this;
var input_position = getAbsolutePosition(input);
// select.style.display = "none";
select.style.top = input_position[1] + input.offsetHeight +
input.style.borderWidth;
select.style.left = input_position[0];
select.style.width = input.offsetWidth;
this.hide = function() {
var that = this.that;
select.style.display = "none";
that.visible = false;
}
this.show = function() {
var that = this.that;
select.style.display = "block";
select.focus();
that.visible = true;
}
this.toggle = function() {
var that = this.that;
if(!that.visible)
that.show();
else
that.hide();
}
this.update = function() {
var a = [];
var o = select.options;
for(var i = 0; i < o.length; i++)
if(o[i].selected)
a.push(o[i].text);
input.value = a.join(", ");
}
this.selectOnBlur = function(e) {
var that = this.that;
that.hide();
that.update();
}
this.buttonOnClick = function(e) {
var that = this.that;
that.toggle();
}
this.selectOnChange = function() {
var that = this.that;
that.update();
}
button.that = this;
button.onclick = this.buttonOnClick;
select.that = this;
select.onblur = this.selectOnBlur;
// select.onchange = this.selectOnChange;
this.update();
}
]]>
</xsl:template>
Re: Refactoring woody styling (was Re: Woody Rant)
Posted by Vadim Gritsenko <va...@verizon.net>.
Ugo Cei wrote:
> Let's not just provide something for the lowest common denominator
> (a.k.a. Netscape 4.X).
On the similar note... As seen on the slashdot:
http://www.alistapart.com/articles/slashdot/
Vadim
Re: Refactoring woody styling (was Re: Woody Rant)
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Ugo Cei dijo:
> Sylvain Wallez wrote:
>> 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).
>
> I'm with you here. Let's face it, what people are and will be using
> Woody for is mainly HTML forms, and there's no way you can make a decent
> form-based application without *lots* of DHTML code. For example, in my
> current project we have forms with hundreds of fields, and having tabs
> is a huge usability improvement. So much that for an early prototype we
> developed our own "tabs" script on top of JXForms, but as soon as I saw
> Woody's tabs I threw the prototype away and restarted from scratch.
+1
> If there are problems with the current implementation, let's fix them
> and provide a standards-compliant DHTML-based toolkit for those who need
> it (like me ;-) ). If we want to create the best web application
> development platform in the world, we cannot provide only a server-side
> solution and tell people to do their homework on the client side. This
> isn't going to sell.
+1
> Let's not just provide something for the lowest common denominator
> (a.k.a. Netscape 4.X). We could do a simple stylesheet for people who
> just want a plain registration form for their guestbook, but I'd
> question the appropriateness of using Woody for that, the
> FormValidatorAction would work much better.
To be honest I love so much woody that even my simple login form use it.
The usability matters in my case.
Best Regards,
Antonio Gallardo
Re: Refactoring woody styling (was Re: Woody Rant)
Posted by Steven Noels <st...@outerthought.org>.
On Nov 24, 2003, at 9:14 AM, Ugo Cei wrote:
> Only problem with it: it's LGPL :-(. Maybe we can bug the author to
> switch to an Apache-compatible license or release it under a dual
> licensing scheme.
FWIW; this is also the guy behind HTMLArea, which is licensed BSD-ish,
though he did develop that for a customer (interactivetools.com) who
happened to make a wiser license decision. From reading his website, I
feel there's a slim chance he will be changing the license, since he
feels ripped off by some Rumanian company with some of his libraries.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Refactoring woody styling (was Re: Woody Rant)
Posted by Joerg Heinicke <jh...@virbus.de>.
On 24.11.2003 09:14, Ugo Cei wrote:
> Stefano Mazzocchi wrote:
>
>> At the same time, all the style should happen in the XSLT thus the
>> <HTML> calendar strings worries me.
>
>
> I am using another calendar with Woody:
> <http://dynarch.com/mishoo/calendar.epl>. As the author says:
>
> "It works with Mozilla, Netscape >= 6.0, all other Gecko-based browsers,
> Internet Explorer >= 5.0 for Windows, Opera 7, Safari and Konqueror."
>
> and has much better support for styling and i18n, AFAIU. Sincerely, I
> haven't looked at the code to check if it prints HTML strings.
This is an absolutely cool one!! The requirements point to its DOM
conformness and I had a quick view into the code and it looks good as
well. Clean CSS separation, i18n support (but there own of course, which
might be replaced by Cocoon i18n).
> Only problem with it: it's LGPL :-(. Maybe we can bug the author to
> switch to an Apache-compatible license or release it under a dual
> licensing scheme.
The virus is everywhere ... BTW it's a sourceforge project
(http://sourceforge.net/projects/jscalendar). This also includes a
community, it's not a one man show. The code can be found at
http://cvs.sourceforge.net/viewcvs.py/jscalendar/jscalendar/.
Is there anybody out there ... willing to ask the developers ;-)
Otherwise I will do it as I started the thread with my rant :-)
Joerg
Re: Refactoring woody styling (was Re: Woody Rant)
Posted by Ugo Cei <u....@cbim.it>.
Stefano Mazzocchi wrote:
> At the same time, all the style should happen in the XSLT thus the
> <HTML> calendar strings worries me.
I am using another calendar with Woody:
<http://dynarch.com/mishoo/calendar.epl>. As the author says:
"It works with Mozilla, Netscape >= 6.0, all other Gecko-based browsers,
Internet Explorer >= 5.0 for Windows, Opera 7, Safari and Konqueror."
and has much better support for styling and i18n, AFAIU. Sincerely, I
haven't looked at the code to check if it prints HTML strings.
Only problem with it: it's LGPL :-(. Maybe we can bug the author to
switch to an Apache-compatible license or release it under a dual
licensing scheme.
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
Re: Refactoring woody styling (was Re: Woody Rant)
Posted by Stefano Mazzocchi <st...@apache.org>.
On 24 Nov 2003, at 21:32, Joerg Heinicke wrote:
> On 23.11.2003 20:21, Antonio Gallardo wrote:
>
>> Stefano Mazzocchi dijo:
>>> At the same time, all the style should happen in the XSLT thus the
>>> <HTML> calendar strings worries me.
>> I think it can be easily addresses by "inspecting" with XPath if
>> there is
>> a widget with Date datatype. In that way we can enclose between an
>> <xsl:if> all the calendar sutff. Is this OK?
>
> No ;-)
>
> Stefano simply also dislikes document.write() and this should be
> replaced completely by a DOM conform JavaScript.
Ah, you mean using DOM instead of document.write()? ok, yes, I agree,
document.write() is just like out.println() in servlets. BAD!
--
Stefano.
Re: Refactoring woody styling (was Re: Woody Rant)
Posted by Joerg Heinicke <jh...@virbus.de>.
On 23.11.2003 20:21, Antonio Gallardo wrote:
> Stefano Mazzocchi dijo:
>
>>At the same time, all the style should happen in the XSLT thus the
>><HTML> calendar strings worries me.
>
>
> I think it can be easily addresses by "inspecting" with XPath if there is
> a widget with Date datatype. In that way we can enclose between an
> <xsl:if> all the calendar sutff. Is this OK?
No ;-)
Stefano simply also dislikes document.write() and this should be
replaced completely by a DOM conform JavaScript.
What you suggest is another issue. Sylvain also wants to remove the
calendar stuff from the resulting HTML if it is not needed, but I think
this can be done in a cleaner way :-)
Joerg
Re: Refactoring woody styling (was Re: Woody Rant)
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Stefano Mazzocchi dijo:
> At the same time, all the style should happen in the XSLT thus the
> <HTML> calendar strings worries me.
I think it can be easily addresses by "inspecting" with XPath if there is
a widget with Date datatype. In that way we can enclose between an
<xsl:if> all the calendar sutff. Is this OK?
Best Regards,
Antonio Gallardo
>
> --
> Stefano.
>
Re: Refactoring woody styling (was Re: Woody Rant)
Posted by Stefano Mazzocchi <st...@apache.org>.
On 22 Nov 2003, at 18:30, Ugo Cei wrote:
> Sylvain Wallez wrote:
>> 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).
>
> I'm with you here. Let's face it, what people are and will be using
> Woody for is mainly HTML forms, and there's no way you can make a
> decent form-based application without *lots* of DHTML code. For
> example, in my current project we have forms with hundreds of fields,
> and having tabs is a huge usability improvement. So much that for an
> early prototype we developed our own "tabs" script on top of JXForms,
> but as soon as I saw Woody's tabs I threw the prototype away and
> restarted from scratch.
>
> If there are problems with the current implementation, let's fix them
> and provide a standards-compliant DHTML-based toolkit for those who
> need it (like me ;-) ). If we want to create the best web application
> development platform in the world, we cannot provide only a
> server-side solution and tell people to do their homework on the
> client side. This isn't going to sell.
>
> Let's not just provide something for the lowest common denominator
> (a.k.a. Netscape 4.X). We could do a simple stylesheet for people who
> just want a plain registration form for their guestbook, but I'd
> question the appropriateness of using Woody for that, the
> FormValidatorAction would work much better.
I agree here. It is better to keep the common denominator much higher
than netscape 4.x, I would say IE 5.0 and NS 6 would target 95% of the
browser market. For the rest, well, up to them: if you need it, you fix
it.
As for Safari, by the time we are done, I'm sure they'll fix the
issues, they are fixing bugs at an incredible rate.
At the same time, all the style should happen in the XSLT thus the
<HTML> calendar strings worries me.
--
Stefano.
Re: Refactoring woody styling (was Re: Woody Rant)
Posted by Ugo Cei <u....@cbim.it>.
Sylvain Wallez wrote:
> 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).
I'm with you here. Let's face it, what people are and will be using
Woody for is mainly HTML forms, and there's no way you can make a decent
form-based application without *lots* of DHTML code. For example, in my
current project we have forms with hundreds of fields, and having tabs
is a huge usability improvement. So much that for an early prototype we
developed our own "tabs" script on top of JXForms, but as soon as I saw
Woody's tabs I threw the prototype away and restarted from scratch.
If there are problems with the current implementation, let's fix them
and provide a standards-compliant DHTML-based toolkit for those who need
it (like me ;-) ). If we want to create the best web application
development platform in the world, we cannot provide only a server-side
solution and tell people to do their homework on the client side. This
isn't going to sell.
Let's not just provide something for the lowest common denominator
(a.k.a. Netscape 4.X). We could do a simple stylesheet for people who
just want a plain registration form for their guestbook, but I'd
question the appropriateness of using Woody for that, the
FormValidatorAction would work much better.
Just my 0.02€
Ugo
Re: Refactoring woody styling (was Re: Woody Rant)
Posted by Sylvain Wallez <sy...@apache.org>.
Joerg Heinicke wrote:
<snip/>
> Of course. But as I pointed out the current solution is not really
> cross-browser, but only works for many browsers at the moment because
> they are backwards compatible. I don't know if you heard of it, but at
> the time Apple chose Konqueror as the base of Safari they said it was
> because of the FAT gecko engine. And why is it fat? Because they added
> backward compatibility here and there. But otherwise gecko browsers as
> Mozilla were not accepted. But we with our new Cocoon forms framework
> should not rely on browser backward compatibility, but exhaust their
> new features as far as possible and appropriate.
>
>> What do you think?
>
>
> Agreement in general :-)
Cool. I understand your concern now, which is about standards compliance
instead of old (dead?) browser support.
I totally agree with you. But being a relative newbie on the client
side, I picked up here and there what seemed interesting to me to
fulfill the features I needed for my current project.
Let's consider this as a prototype of the wanted styling features and
work now on a cleaner solution. And the nice XUL things you've done at
Virbus certainly make you, as we've just seen, a good candidate as a
standards-conformance checker ;-)
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
Re: Refactoring woody styling (was Re: Woody Rant)
Posted by Joerg Heinicke <jh...@virbus.de>.
On 22.11.2003 14:40, Sylvain Wallez 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.
Thanks ...
> 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):
Yes - and this was absolutely okay.
> - it displays nicely in many browsers (at least those I work with),
Especially in older browsers, but not with XHTML as it is understandable
because of document.write() usage. It's similar to <xsl:text
disable-output-escaping="yes"><element/></xsl:text> in XSLT.
> - 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.
Of course. The problem I see with the current code:
The calendar is optimized for older browsers (let's say NS 4, IE 4) and
works in recent browsers because of their backwards compatibility (up to
HTML 4.0).
The HTML elements like <label> and <fieldset> only work for recent
browsers (NS 6, IE 4 and above). So we have only a short time where it
works. Especially where XHTML is on the road our nice samples can not work.
(BTW are cross browser information like
http://selfhtml.teamone.de/html/formulare/strukturieren.htm#label
http://selfhtml.teamone.de/html/formulare/strukturieren.htm#gruppieren
also available in other languages? SelfHTML is really *THE* HTML
information source for German understanding people.)
>> 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).
I don't want to remove things like calendar or tooltip popups. That's
really cool stuff. But the implementation is really bad. And I had the
impression that we are focussing only on extending that JS library while
"it's not worth the time".
>> 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.
In which way? CSS? CSS and NS 4 is almost a contradiction in itself ;-)
> 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.
That would be cool.
>> 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.
Nobody else gave a comment on this, so it seems not important. I only
don't like it that prominent.
>> 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.
Fine.
> However, we cannot totally remove client-side JS, but the minimal
> requirement is really small.
I don't want to.
> 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 it's that easy (= a few general hooks, not here JS and there JS) I'm
absolutely okay with it.
> 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.
Okay.
> 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.
Of course. But as I pointed out the current solution is not really
cross-browser, but only works for many browsers at the moment because
they are backwards compatible. I don't know if you heard of it, but at
the time Apple chose Konqueror as the base of Safari they said it was
because of the FAT gecko engine. And why is it fat? Because they added
backward compatibility here and there. But otherwise gecko browsers as
Mozilla were not accepted. But we with our new Cocoon forms framework
should not rely on browser backward compatibility, but exhaust their new
features as far as possible and appropriate.
> What do you think?
Agreement in general :-)
Joerg
Refactoring woody styling (was Re: Woody Rant)
Posted by Sylvain Wallez <sy...@apache.org>.
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
> 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
Re: Woody Rant
Posted by Joerg Heinicke <jh...@virbus.de>.
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 ;-)
Joerg
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 +=
>>"<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.
>>
>>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,
>>
>>Joerg
>>
>>[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106941742522128&w=2
>>[2] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24900
Re: Woody Rant
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
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 +=
> "<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.
>
> 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,
>
> Joerg
>
> [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106941742522128&w=2
> [2] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24900
>
Best Regards,
Antonio Gallardo
Re: Woody Rant
Posted by Joerg Heinicke <jh...@virbus.de>.
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.
DOM).
>>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:
>
> http://www.securityspace.com/s_survey/data/man.200310/techpen.html
>
> 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 ...
Joerg
Re: Woody Rant
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Bertrand Delacretaz dijo:
> Le Samedi, 22 nov 2003, à 02:24 Europe/Zurich, Joerg Heinicke a écrit :
>
>> ....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.
> 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:
http://www.securityspace.com/s_survey/data/man.200310/techpen.html
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.
> 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.
Best Regards,
Antonio Gallardo
Re: Woody Rant
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Samedi, 22 nov 2003, à 02:24 Europe/Zurich, Joerg Heinicke a écrit :
> ....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.
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.
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.
-Bertrand