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

  • From: <stefan.pollach@xxxxxx>
  • To: <jala-dev@xxxxxxxxxxxxx>
  • Date: Thu, 3 May 2007 13:17:11 +0200


Finally, here are my comments to the feedback so far:

+1 for checkRequirements and Component#require() as Tobi proposed, plus
using constants for MINLENGTH etc. That solves the raddled terminology
with "basics" and "syntax" in very elegant way and reduces the number of
methods en passant.

+1 for renaming check to validate.

+1 for the separation of FileComponent and ImageComponent. The latter
should be a subclass of the first.

+1 for handling getter and setter via properties. Didn't like setSetter
either, but implemented it for the sake of consistency.

Reg. parseConfig()
I'd like to keep that as a static method. It is nothing else but a
helper method for a less verbose config. This way, we have one way of
configuring a form instance (using methods) and a helper taking away
As for a different name for that method: "createInstance" states that
this method creates a new object (same as java.lang.Class#newInstance).
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)?

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.

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

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.

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


Other related posts: