[jala-dev] AW: Further feedback on jala.Form

  • From: <stefan.pollach@xxxxxx>
  • To: <jala-dev@xxxxxxxxxxxxx>
  • Date: Thu, 10 May 2007 14:54:43 +0200

>  1. I noticed that it's the "require()" method vs the 
> "required" declaration; no tragedy, but in the first place I 
> entered "require" in the form object structure. maybe, you 
> could indeed rename the latter to "required"?

Intuitively, I'd say a the name of method describes an action and should
therefore be a verb, whereas a the field names describe a state and
should so rather be an adjective ("invalid", "required"). Yet, most of
the other markers ("maxlength", "maxwidth") don't really fit with that
scheme anyway, so I'd be fine with changing that to "require"
everywhere. Any other opinions?

>  2. The exclamation marks in the default error messages are a 
> little bit bossy (the old shouting thing). Thus, I always 
> would want to overwrite the default messages with the 
> corresponding method or declaration to be nice to the users 
> of my app. If we'd drop the exclamation marks I could spare 
> me this extra work. Furthermore, the wording of the messages 
> themselves could need some elaboration, generally. (If I only 
> could find them more easily in the code...)

The exclamation marks will be gone in the next commit. As for the
general wordings feel free to improve.
>  3. In the application I am testing jala.Form right now I 
> have just a few generic HopObject properties and quite a lot 
> of XML-encoded ones (ie. using PropertyMgr). Thus, I need to 
> set custom setter/getter methods to almost every form 
> component. It would be helpful if I could define default 
> methods for the whole form object and thus, simply override 
> these with component-specific ones.

What about having getter and setter properties (validator too?) at the
form object? By default this methods would do what get/setValue method
currently does: Returning or setting the properties of the data object.
If you change form.getter or form.setter you can change the default
behaviour, if you change the component's getter/setter functions you can
specify individual behaviour.

In order to have a custom getter/setter at the form and still be able to
use the default getter/setter-behaviour for a single component, the
default method should be a static function like isEmail or isUrl.

> Finally, I still think we need to find better names for the 
> following methods / properties, and this time I provide some 
> proposals:
>  * setDataObj - what about "setSource"? or at least: "setDataObject"?

Not sure about these: it's not just the "source", it's the target too.
Data object would be ok with me because that's pretty much what it is,
for naming the methods getObject/setObject could be enough.

>  * submitCaption - why not simply "label", just as for 
> components? (Just for a reason to rename this: "A caption is 
> a concise and descriptive bit of text that labels a picture, 
> chart, or table", says Wikipedia. The submit button doesn't 
> have a caption IMHO but it is labeled or named.)

In the context of forms label is used for text that appears next to the
actual element, describing it (<label for="element">text</label>). Even
though such a label doesn't make a lot of sense for a submit button, I
am against assigning "label" a different meaning here.

The <caption> tag does to tables what label does to form elements. So
from an html viewpoint "caption" doesn't fit neither. Note that in
Visual Basic "caption" is used for the text actually seen on the button
(I think that was my inspiration). Java 5 has deprecated the setLabel
method for buttons and replaced it with setText.

So, I'd suggest sticking to html and the attribute-name of the submit
button's text: setSubmitValue()


Other related posts: