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

  • From: <robert.gaggl@xxxxxx>
  • To: <jala-dev@xxxxxxxxxxxxx>
  • Date: Wed, 2 May 2007 19:01:04 +0200

hi tobi,

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

the problem with passing the form definition object as argument to the
constructor is that it is not distinguishable from a plain JS data
object. so in some cases we'd end up with constructor calls like

var f1 = new jala.Form(null, dataObj);

which i personally don't find very good. that's why i'd prefer the

var f1 = new jala.Form("formName");
var f2 = new jala.Form("formName", dataObj);

plus keep parseConfig() for creating a form instance based on a form
config object. parseConfig() is merely a helper method that converts a
form config object into the appropriate getter/setter calls and returns
a jala.Form instance, that's why i thought createInstance() would be a
better name - somehow parseConfig sounds like i would get a parsed
configuration back.

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

you're right, of course it would be jala.Form.Text(). nevertheless that
method name doesn't tell me that i'm instantiating a form component
(same with "new jala.Form.Input()" and the like). imho it's a benefit to
stick with the html form element names where possible, and to add
"Component" to the constructor name just to make clear you're not
instantiating some kind of html element wrapper but a full blown
jala.Form component.

> 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"
> }]

as i wrote in my previous mail, i second replacing "class" with "type"
and using a string identifier instead of the constructor name. that
perfectly makes sense when using a form config object. nevertheless i'd
prefer to stick with the html form element names where possible, eg. to
use "textarea" instead of "text" as type value.

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

a downside of using constants is the long identifier (eg.
jala.Form.INPUT), plus i'm not sure if we can rely on the constants
already existing at the time a static form config of a prototype is
parsed - so this approach could end up in an exception under certain
circumstances. so i think you're right, using string identifiers is
probably the safest way, nevertheless i'd say that jala.Form should
internally use constants if possible.


Other related posts: