Re: Comments on forms package

>  > 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).

I mean on a ListBox control in the first place. Select field in the html 
form appears as a drop down list (combo control), or options list box if 
"select" tag contains "multiple" keyword. Multiple type allows (of 
course)  more the one option selection. I sent a mail with "Options 
field" subject witch contains class that produces both kinds of fields. 
If you take a look on a class code, you will see what I mean. I think 
that main problem is a handle method in FormCardResource:


public synchronized Reply handle (Request request, URLDecoder data) 
	throws HTTPException
    {
	…
	// Change the fields value apprpriately:
	Enumeration e = data.keys() ;
	while ( e.hasMoreElements() ) {
	    String name  = (String) e.nextElement() ;
	    String value = data.getValue(name) ;   <---------
	    try {
		updateField (name, value) ;
	    } catch (FormFieldException ex) {
		…
	    }
	…
	}
}

Method getValue in URLDecoder throws RuntimeException if field has 
multiple values. But, if instead getValue you call getMultipleValues and 
then appropriate method in FormFieldInterface (unfortunately setValue 
gets just a String, not String[] ), problem can be solved. As I said 
last time, FormFieldInterface can be extended with setValues and 
getValues functions, and FormField class with these blank functions. 
Everything else is as it was. Classes extended from FormField remain the 
same shape.


>  > 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)
> 
> Anselm.

Well, if you need new people in your team or just some help, I am 
available. :)

Rade.

Received on Sunday, 25 August 1996 08:06:14 UTC