Bugds and desired features

36 views
Skip to first unread message

Kornel Umann

unread,
Feb 25, 2013, 5:18:50 AM2/25/13
to perl-for...@googlegroups.com
First of all, thanks for the good work!

BUGS:

Field name cannot be reserved JavaScript word now (e.g. 'var', 'new') because it becomes variable name in JavaScript. Also, field names 'foo_bar' and 'foo.bar' both become JavaScript variable foo_bar (rarely occurs, I know). Instead of simply using field name, it would be better something like {($jsvarname="FB$fieldname")=~s/[^a-zA-Z]/sprintf("_%02X", ord($&))/g;}

In case of {field->(name=>'foo', options=>[1,-1])}, both HTML input ID's will be 'foo_1'. The same hex encoding as above could be used.

ID and NAME tokens must begin with a letter ([A-Za-z]), so "_submitted" and "_submit" are not HTML-compliant. A workaround would be to allow user defined names for these fields.

linebreaks => 1 has no effect in new(), it must be used in each field() that has options.

Superfluous <form> attributes as pointed out by Victor Porton.

DESIRED FEATURES:

Support for semantic validation (in Perl only), e.g. duplication error when adding new record to db, with custom error message (besides the current validation with fix error message). I could not find it, sorry if I'm blind. I can change message text now, but I'd like to tell syntax errors from semantic ones.

Optional trim of input fields {s/^\s(.*)\s*$/$1/; s/\s+/ /g} both in JavaScript and Perl. Annoying extra white spaces often occur when copy/pasting.

For required=>1, it would be nice to have an explicit error message if field is left blank (after trim, of course) instead of general "Invalid entry".

Error messages should be written in a 3rd column. Between long text input fields, a message written right after the last label of a radio button group is hard to recognize.

HTML attrs (like size) to be defined not just in field->() but also in new->()

s/\b1 error\(s\) were/1 error was/ ;-)

Instead of alarm() popup onSubmit, JavaScript could check entered values' syntax on the fly (onChange, onKeyUp etc.) and colour the labels dynamically black if input is correct and red if not. At the age of limitless Ajax calls, there is not much use of a client-side check to save one submit to server. OK, I come down from the clouds...

BR,

Kornel
Reply all
Reply to author
Forward
0 new messages