[jala-dev] AW: Re: AW: Code Convention in jalaForm.js
- From: <stefan.pollach@xxxxxx>
- To: <jala-dev@xxxxxxxxxxxxx>
- Date: Fri, 18 May 2007 16:42:05 +0200
> i don't think client-side JS would require this, at least if
> one uses a meaningful library. currently, i'd vote for
> leaving away as much default attributes as possible -- makes
> the markup much cleaner.
You're right, even without a library it isn't very difficult to access
the child elements of an element with an id. So I dropped ids for the
tags wrapping label, error and help texts. The form elements keep their
id ("form1Input1Control") because the for-attribute of the label tag can
reference a form element only by id, not by name. This way we have an ID
for the element addressed by js most likely (the form element) but don't
clutter the other tags with ids.
> > Another issue that needs to be addressed in jalaForms is the
> > possibility to add handlers and additional attributes like
> > tabindex or accesskey to a component. Stefan suggested to add an
> > object called attributes in the form definition, e.g. name:
> > "author", label: "Author:", require: true attributes: {
> > onClick:"alert(this);",
> > accesskey: "t"
> > }
> > Whatever you write in this object will be added as and attribute to
> > the respective HTML tag.
>
> will this solution really make us happy in the long run? what
> if i define "class" or other attributes which already got set
> by jala.Form in the attributes object?
>
> i think this could cause some ugly confusion. however, i
> haven't any better solution at hand right now.
I was taken by an error here: While it would be useful to add further
attributes, we actually would like to add them to different html
elements. The accesskey attribute should be attached to the <label>
element, whereas the onClick-attribute should go into the <input>
element.
At the moment I can't think of a clear and simple solution (I would not
like to add setLabelAttribute(), setControlAttribute() and the like to
the components).
On the other hand, this feature is most relevant for client-side
javascript. Therefore, it's not a clean solution to specify
eventhandlers in the server code anyway.
So my proposal is: Attributes that are essential for the functioning of
the form or are mandatory in the w3c spec shall have their own
get/setXXX methods. If a component can't set such an attribute, this
should be considered a bug. All other attributes, especially client-side
js eventhandler should be set using client-side js.
Stefan
Other related posts:
