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

  • From: <tobias.schaefer@xxxxxx>
  • To: <jala-dev@xxxxxxxxxxxxx>
  • Date: Wed, 2 May 2007 13:31:49 +0200

hi robert

> Reg. "components" vs. "elements": the reason for "components" instead
> of "elements" is imo to avoid confusion, since a form component
> consists of more than just the form element(s) (label, help text,
> error message etc.). That's why i think that "component" is a better
> term, although it might not be that intuitive.    

i see. this makes sense.

> Reg. instantiation: afais jala.Form doesn't depend on a HopObject
> containing the data (although in most cases one will use a persistent
> HopObject as basis), the data object can currently be any object, or
> none (think of a simple login-form). That's why getting rid of
> parseConfig and making both the form config and the data object
> required would imo limit the usage of jala.Form. However i think the
> constructor should accept the data object as second argument, so that
> calling setDataObj() shouldn't be a necessary step. And maybe
> "parseConfig"       
> should be renamed to "createInstance", as that's what it does (not
> only parses the form config, but also constructs a form instance
> based on that).

although i know createInstance() methods from java it is still not clear to me 
what they are good for. i think it has to do something with protected 

anyway, since we have a constructor method for jala.Form, i still don't 
understand why this shouldn't be enough to take care of the different 

var f1 = new jala.Form();
var f2 = new jala.Form({ /* form definition */ });
var f3 = new jala.Form({ /* form definition */ }, dataObj);

of course, in case of f1 we then again would need a setter method for the 
dataObj - but as i am just proposing options here, the point is that i'd like 
to avoid the parseConfig() or createInstance() methods generally because i 
cannot see the reason for the distinction they shall make, yet.

> Reg. getting rid of the "Component" part of the various constructors:
> i'd vote for keeping it, as eg. "new TextareaComponent()" is imo much
> clearer than "new Text()" or the like. And i'd prefer to keep
> "TextareaComponent" instead of renaming it to "TextComponent", just
> because the constructor name tells me what i'll get (i agree with you
> that CheckboxComponent is a much better name than "FlagComponent").

actually, it never would be "new Text()", would it? rather "new 
jala.Form.Text()" - which is saying enough IMHO.

moreover, we probably need to distinguish the two approaches provided by 
jala.Form: using an object structure vs. using instance methods.

i am taking the first approach and here it wouldn't make the structure less 
clean when i could drop the annoying "Component" suffix:

elements: [{
   type: "input",
   name: "subtitle",
   label: "Subtitle"
}, {
   type: "select",           // or rather: "chooser"?
   name: "mainCategory",
   label: "Category"
}, {
   type: "select",
   name: "subcategory"
}, {
   type: "text",
   name: "description",
   label: "Description"

> I personally find your idea with require() very appealing. Instead of
> using strings as identifiers (eg. "minlength") i think using
> constants would be a nicer way, plus we could allow passing an error
> message as optional third argument, eg.:   
> text.require(jala.Form.MINLENGTH, 2, "You must enter at least 2
> characters.");

although i consider constants as more bullet-proof, generally, i rather lean 
towards case-insensitive strings at the moment; main reason being brevity, it 
also looks more consistent to the overall approach in jala.Form. (otherwise i 
would suggest to use constants for the component types as well, and i somehow 
don't want that, either.)

> In relation to: how about renaming checkSyntax() to
> checkRequirements()? 

sounds good.

> There's one thing that i find a bit odd in the current jala.Form: it
> encloses all of its components in a fieldset that you can't get rid
> of.

oops, i did not notice this until now; i thought it was a relic of my own 

> Instead i would prefer it to provide a Fieldset(Component)
> constructor, allowing to create multiple fieldsets in a form, each
> one containing multiple components as children.  

i agree. fieldsets should be optional and flexible as any other part of the 

> I second renaming Form.prototype.check() to validate(). However this
> method should imho basically just loop over all components and call
> their validate() method. So every component (including Fieldset)
> should be somehow capable to validate itself.   



Other related posts: