[jala-dev] Re: AW: Code Convention in jalaForm.js

  • From: <tobias.schaefer@xxxxxx>
  • To: <jala-dev@xxxxxxxxxxxxx>
  • Date: Fri, 18 May 2007 11:01:14 +0200

hi kris

> The child elements of this div do not necessarily need an ID, but for
>      the sake of easy and direct accessibility in client-side JS we
>      suggest this notion: <div class="errorText"
>      id="form1Input2Error" ... <label id="form1Input2Label" ...
>      <input id="form1Input2Control" ... <div class="helpText" 
> id="form1Input2Help" ... 

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.

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

> Finally, it would be nice if the cursor or the focus changes to the
> component that has an error. This could be done in a small
> client-side JS.

yes, that would be nice (just as other client-side hooks); the problem is, 
though, that we then must make a choice of how we code client-side javascript 
code (or: which library we are going to use). and i'd like to leave that open 
to the jala user.

for what it's worth there are still some more open issues (at least i don't 
know if they have been addressed in the meantime):

 * jala.Form requires a (not required) input element due to its validator being 
set to jala.Form.isEmail; ie. if nothing is entered at all in such an element, 
the form is not valid.
 * https://opensvn.csie.org/traccgi/jala/ticket/60
 * https://opensvn.csie.org/traccgi/jala/ticket/61


Other related posts: