W3C home > Mailing lists > Public > www-jigsaw@w3.org > July to August 1996

Comments on forms package

From: Anselm Baird-Smith <abaird@w3.org>
Date: Sat, 24 Aug 1996 16:19:55 +0500
Message-Id: <9608242019.AA06835@www18.w3.org>
To: Radomir Mladenovic <rade@ban.junis.ni.ac.yu>
Cc: www-jigsaw@w3.org
 > I hope it's not to late to say few words about forms package. This is
 > a result of my work these days.

It's never too late.

 > members and contructors in first line. For example, if I want to
 > extend FormCardResource, my class must be a part of the w3c.jigsaw.forms
 > package. I don't like that because I want to separate my classes from
 > w3c distribution. Just practical reasons. Otherwise, if I put my
 > forms resources in some other package I can't access to data members. :(
 > Everything is needed is to make data members and constructor protected.

Correct, this was an oversight, I will fix it.

 > Second, I think that FormFieldInterface and FormField should have 
 > methods for mutiple values fileds:
 > 	public Object getValues();
 > 	public boolean setValues( String nvals[] );
 > or some equivalent interface. Handle method in FormCardResource also 
 > does
 > not have support for multiple value fields. That shouldn't be problem to
 > implement. Now, I can extend handle method and support it, but form
 > field doesn't have propper interface (or I'm missing something). It can
 > be done with hacking, but I would rather see this in standard jigsaw 
 > release.

I am missing something here: is this for radio box, or for something
more elaborated. One thing I was lacking with this interface is the
ability to have a FormFieldInterface implementation that would wrap
several FormFieldInterface into one combo (to edit a date for example,
you may want to use several IntegerField combined together).

 > At the end, I think that dump method in ...Field classes should not
 > dump "th" tags, even Title. That's a job for a someone else (class
 > extended form HtmlGenerator or dump method in FormCardResource). Dump
 > method in field should dump just it self. It looks that current
 > implementations of dumps are adapted for property editor resources.

Correct again, the difficult thing is that in general, I beleive the
FormFieldInterface should not be aware of any geometry, which is what
dump and dumpTitle currently does. In an ideal world, there would be
some sort of layout manager that would take care of using the
appropriate idioms (table, <pre> tags or whatever to layout the form
items correctly). I am afraid this will not be changed in next
release, but the form package all together needs more work, I would be
more then happy to rework it entirely (or include  someone else's
attempt to solve the problem in some futur release)

Received on Saturday, 24 August 1996 16:20:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:29 UTC