[jala-dev] Re: AW: Re: Feedback to updated jala.Form

  • From: <tobias.schaefer@xxxxxx>
  • To: <jala-dev@xxxxxxxxxxxxx>
  • Date: Thu, 3 May 2007 13:57:39 +0200

hi stefan

> using constants for MINLENGTH etc. 

are you absolutely sure about using constants?

(we will get long lines and redundant occurences of jala.Form.WHATEVER, which 
i'd absolutely hate.)

still +1 for the feature itself, but still even more +1 for strings.

> But actually this method does quite a lot more: parsing a config
> object tree and creating instances of subclasses. Imho, the name of
> the method has to reflect that. What about
> jala.Form.createFromConfig(config)?

it does a lot more but in the end it returns an instance of jala.Form.
thus, and as the method shall survive, i'd vote for the name which is closest 
to java terminology. (is this createInstance or getInstance, though?)

> Reg. the constructor:
> I'd like the first argument of the constructor to be the name, so
> that it is consistent with the components. The data object could be a
> second argument but in that case I would change the behaviour of
> render() and   
> save() like this: A data object is bound to the form, either passed
> in the constructor or set later using setDataObject. Render() always
> uses the internally stored data object, save() uses a data object
> provided as argument or falls back on the internally stored object.
> If you want to edit an existing object, you need to provide it only
> once in the constructor. If you want to edit a not-yet-existing
> object or perform any other tricks with jala.Form, you may still hand
> over alternative data objects when saving.

that sounds plausible as far as i can theoretically think about it.

> Reg. components and type/class:
> I like the idea that constructor, type and css classes are all of the
> same name. That's pro shortening the constructor name. On the other
> hand, I'd like to see the word "component" in the constructor of a
> component for the same reasons Robert mentioned. What about new
> jala.Form.Component.Password(), with a type id "password" and the
> css-classname "password"? For macros you also have to use the path
> form.components.anyName.

i'd appreciate if we could follow this general, abstracted approach. 

> As for names: If there is no functionality added to the html element,
> the element's name should be the component's name. That works for
> input, password, textarea etc. Thus I'm against chooser, because that
> would imply more abstraction than a dropdown (a chooser might also be
> made up of radiobuttons or checkboxes). That's why I renamed
> CheckboxComponent to FlagComponent: Its purpose is to edit fields
> whose only contents are 0 and 1 (without considering setter/getter
> tricks) whereas a CheckboxComponent should be able to handle other
> contents too.

sorry for insisting but still FlagComponent is no good. it's neither 
straight-forward nor terminologically fitting in the area of form design. could 
we make a last effort and find another name for it?

> Reg. fieldsets:
> There's another issue related to that: It would be great if forms
> could be split up into pages/steps/parts with validation after each
> page, but saving only at the end. 

right. however, i would leave this to the application designer, at least at 
this point. there's a lot of room for improvements in a next version of jala...

furthermore, there are promising efforts going on regarding getting away from 
page-oriented form processing [1]. thus, i am pretty optimistic that there will 
be some fresher ideas around the corner we are currently heading to.
> As for fieldsets, I like Robert's approach of an extra class. We
> would have to make sure that all css-based layouts are possible
> without a fieldset, otherwise I'd say that a fieldset should be
> mandatory and created in the constructor of jala.Form.   

i cannot think of a situation where a css-based layout shouldn't be possible 
without fieldset. thus, it shouldn't be mandatory, but of course supported as 
an option.


[1] ``Much of the inspiration for Avi's work lies with WebObjects, another 
child of the pioneering work done at NeXT prior to its merger with Apple. 
WebObjects eschewed the HTML-centric, page-oriented mindset for a thoroughly 
object-oriented approach, where user interfaces are composed of stateful 
objects that send messages to each other based on user-generated events. 
"Apple's WebObjects was the first thing that I had seen that did things 
radically differently. It had this much richer notion of how you were 
processing events. It didn't explicitly deal with HTTP requests -- you would 
define callbacks, as you would in a desktop widget framework, and it figured 
out which of your methods got triggered when you clicked on a link or typed 
something into a form. It threw away the page as a unit of modularity and broke 
things down into components," said Avi.''

Other related posts: