[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
constructors...
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.
> 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
code...
> 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
form.
> 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.
+1
ciao,
tobi
Other related posts:
