Recent changes to feature-requests

javascript validation

2006-05-18T19:47:32Z

http://jsval.fantastic-bits.de/ this project allows
for validating javascript on the client side easily.
If it works the correct way it uses styles instead of
modifying the form elements directly. In either case
it could be integrated into the form code.

The library works by looking at the form control for
extra parameters like required and regex. All we would
have to do is include the library and then output those
extra attributes as part of the form processing. The
user can ignore it or turn it on by calling the proper
functions from the submit onclick.

disable button after click

2006-02-13T15:25:55Z

We should add an option to the Submit buttons in
htmlobject::form that runs js code to disable the
button after clicking. this would prevent double
submissions (mostly).

It would be great if it could be added to regular
buttons also.

The code I'm using in the DB::Upgrade module is
onclick="javascriptFunction(); this.disabled = true;"

Notice that I am doing some other stuff during onclick.
so our api would need to add the disabled code to
whatever the user specifies.

submit => {
-Type => "submit",
-Label => "Click Me",
-ClickLabel => "Please Wait",
onclick => "javascriptFunction();"
-ClickDisable => 1,
# defaults to 1 for submit buttons and 0 for regular
buttons.

We also want to allow the user to specify different
text for the submit button after it has been clicked.

HTML::Object::Easy

2006-02-02T14:48:05Z

I'm thinking of developing an extension to htmlobject
called Easy or Ajax that aids in development. Perhaps
it would support both ajax and non ajax modes.

* template, profile, data, list, baseurl would all be
specified as part of the object
* for ajax mode the UI would be one page with multiple
forms in divs that are hidden/shown
* the superclass would output the edit form generated
from all of this into a div called 'edit'
* the list of data to work on would be output into a
div called 'list'
* under the list would be the buttons: new, and delete
* next to each list item would be a delete checkbox
* each list item will be a link to edit that item
* user can fill in the form and click Submit button
* after the user has entered the data the profile will
be used to validate it with js regex.
* After validation the js code will make another
httpmxl_request call to the backend to submit the data.
the backend will also validate with the same regexp
from profile bc the user could always disable js and
push back anything
* a return code will be sent to the callback with the
action (new, edit/update, delete) and success or
failure with a reason for the failure
* Upon success of new data sent to the backend, the
edit form is blanked and the item is added to the list
- a problem here is what format is the list in vs
what format would be taken from the new data?
- this may require a form element to be added called
list description
* or user clicks a link to edit an entry
-the js code will call the backend to get the data
with httpxml_request and push it into the form in the
edit div. It may also cache the data in xml on the
client side
* upon successful edit, the form is blanked and the
list item is updated
* delete code uses js confirm dialog for verification
* delete pushes list of ids to backend using
httpxml_request. response from server is success or
failure with reason
* after successful delete those items deleted are
removed from the list using dom

Rewrite

2006-02-02T14:40:57Z

We have decided to rewrite and change the APIs for
htmlobject for version 3.0. It will be renamed to
HTML::Object. The Form module will have a new API that
is more consistent. The javascript widgets may be
swapped out with some that are re-usable from other
projects (depends on timing). I will attach the API
document for forms.

James, please make a short list of things you would
like to clean up in other modules or attach a document
with a long list.

error and info console

2006-01-15T01:58:41Z

Therew will be 2 divs with id's consoleHeader and
consoleBody. consoleHeader can be absolutely
positioned and sized by the user and should be
always visible. The code will probably force the
visibility part and possibly set the zindex to make it
be above everything else.

The generateConsole() method will output the div's into
the current object (or would it output a string which
the programmer can $doc->print($doc->generateConsole);
? The developer can overload css entries to absolutely
position it, etc. if they so desire. Otherwise it
will be placed in the flow of the document based on
when you call it, so I'm just going to write into the
body string at the point you call me and I'm not going
to try and force it to be at the top/bottom/whatever.

The div consoleHeader will display "Console name | #
unread/new | Show/Hide button". We need to come up
with the "Console name" string and if we want #unread
or # new, etc.

The consoleBody div will be auto positioned under the
consoleHeader when it is displayed and the width/height
will be auto determined based upon the number of
entries to show (kindof like the searchBox does).

The methods pcxWarn, pcxError, pcxInfo will take an
object that defines the data to be displayed and a
boolean value that indicates if the console should be
displayed if hidden. The # unread will be updated
regardless. The object will contain at least the
following:

objtype - info, warn, error, critical?
line - line number
file - name of file the error is in
message - message to display
prgname - name of the program - optional (only used by
contact)
prgversion - version of the program - optional (only
used by contact)
type - js, db, user-input, etc. (This is totally user
definable and is just a filter for us)
email - e-mail address the contact form should be sent to.

JT says - having both type and objtype is redundant.
make the system flexible enough to just use type and
let users define new types if you really want that
functionality.

The reason I'm suggesting an object is that we can then
add extra attributes to work with for different objtype
values without having to go back and rewrite a lot of
function calls down the road.

The display code will then allow the user to not only
show All or just specify an objtype, but will also
provide a drop-down (possibly multi-select) of all the
unique type's defined for that objtype and allow the
user to just show them or all type's if desired. (JT
says clean that up. have type be the filter and no
subtypes.)

The user may want to allow or disallow messages. put a
boolean check on the console for the user to toggle.
the function should check it before unhiding the
consoleBody.

Errors of type js could add a link to popup the true js
console and thus be able to get at the source of the error.

If the contact email is specified, then I would provide
a "contact developer" link and when clicked it would
display the current js error handler form with all the
info populated to allow the user to send a bug report.

When the user clicks on an entry, the #unread/new will
be decremented in the consoleHeader div. That entry
will visibly change so the user knows it has focus and
the "Delete" button will then become available. The
"Delete All" button will always be available, as long
as there are entries in the console.

Value instead of Field in Forms

2005-12-23T16:57:17Z

I keep running into places where I need JUST the value
in a field on a template. When i use #FIELD=id# i get
the whole hidden field which doesnt work because I
might be using it inside of a link or something.

We NEED to support #VALUE=id# in addition to FIELD AND
LABEL and all the others.

this would substitute JUST the value in the field with
NO formatting or anything else.

Right now I have to do wierd stuff just to simulate
this behavior.

lang mapping in -Label

2005-09-23T12:41:26Z

I propose that the -Label substitutions be done BEFORE
the lang mapping in the templates so that I can use
#LANG=Foo# instead of manually mapping the Foo myself.

Right now i have to
"account" => { -Label =>
$self->{langObj}->map("Account"), -Type => . . .

but we could easily allow for
"account" => { -Label => "#LANG=Account#", -Type => . . .

if the #LABEL=Foo# substitution were done BEFORE the
langSubstitute call.

select name lookup from value

2005-09-23T12:29:43Z

The select fields are already filled in with names and
values. it would be nice to re-use this data store
rather than going to the database to get the
information again. I propose the following api:

=item string selectName(name =>, value => )

required: name - field to look at
optional: value - the value to look up
summary: this routine will lookup a name in an
Options hash for a select or multi-select field. If
value is not given it will default to the current value
in -Value. If nothing is set it will return nothing.

Ex.
data => { name => [ "BLUE", "BLACK", "GREEN" ],
value => [ "blue", "black", "green" ] }

$obj->selectName(value => "black") returns "BLACK"

=cut

Select Button Names

2005-09-22T21:24:21Z

The Select Buttons like "SelectAll", "ToggleSelect",
UnSelect All should be language nuetral.

I propose these to take up less space and be language
neutral.
All - [*]
None - [ ]
Toggle - ><

They could be put on one line instead of taking up 3 lines.

regexps in js

2005-09-08T13:44:35Z

The form object needs a feature which would take any
constraints defined in the profile and output them in javascript
on the client side. When the page is submitted if the
programmer wishes he can call a predefined methods such as
if (constraintCheck(this.form)) { this.form.submit(); }

The routine would run this algor.

potential problems:
P) if there is a constraint defined for a
special field that is not on the client side but is generated
during populate.
S) Programmer cannot use the automatic js constraints with
special fields.