AxKit::XSP::PerForm 1.83

AxKit::XSP::PerForm is an XSP Taglib for making complex forms easy.

SYNOPSIS

AxAddXSPTaglib AxKit::XSP::PerForm

PerForm is a large and complex taglib for AxKit XSP that facilitates creating large and complex HTML, WML, or other types of data-entry forms. PerForm tends to make life easier for you if your form data is coming from different data sources, such as DBI, or even XML.

PerForm works as an XSP taglib, meaning you simply add some custom XML tags to your XSP page, and PerForm does the rest. Well, almost... PerForm works mainly by callbacks, as you will see below.

EXAMPLE FORM

Ignoring the outside XSP and namespace declarations, assuming the prefix "f" is bound to the PerForm namespace:

< f:form name="add_user" >
First name: < f:textfield name="firstname" width="30" maxlength="50"/ >
< br / >
Last name: < f:textfield name="lastname" width="30" maxlength="50"/ >
< br / >
< f:submit name="save" value="Save" goto="users.xsp" / >
< f:cancel name="cancel" value="Cancel" goto="home.html" / >
< /f:form >

Now it is important to bear in mind that this is just the form, and alone it is fairly useless. You also need to add callbacks. You'll notice with each of these callbacks you recieve a $ctxt object. This is simply an empty hash-ref that you can use in the callbacks to maintain state. Actually "empty" is an exhageration - it contains two entries always: Form and Apache. "Form" is a simply a hashref of the entries in the form (actually it is an Apache::Table object, which allows for supporting multi-valued parameters). So for example, the firstname below is in $ctxt-{Form}{firstname} >. "Apache" is the $r apache request object for the current request, which is useful for access to the URI or headers.

sub validate_firstname {
my ($ctxt, $value) = @_;
$value =~ s/^s*//;
$value =~ s/s*$//;
die "No value" unless $value;
die "Invalid firstname - non word character not allowed"
if $value =~ /W/;
}

sub validate_lastname {
return validate_firstname(@_);
}

sub submit_save {
my ($ctxt) = @_;
# save values to a database
warn("User: ", $ctxt->{Form}{firstname}, " ", $ctxt->{Form}{lastname}, "n");
}

Now these methods need to be global to your XSP page, rather than "closures" within the XSP page's main handler routine. How do you do that? Well it's simple. Just put them within a < xsp:logic > section before any user defined tags. For example, if your XSP page happens to use XHTML as it's basic format (something I do a lot), your page might be constructed as follows (namespace declarations omitted for brevity):

< xsp:page >
< xsp:logic >
... form logic here ...
< /xsp:logic >

< html >
< head >< title >An Example Form< /title >< /head >
< body >
< h1 >An Example Form< /h1 >
< f:form >
... form definition here ...
< /f:form >
< /body >
< /html >
< /xsp:page >

[Note that the page-global methods is a useful technique in other situations, because unlike Apache::Registry scripts, this won't create a closure from methods defined there].

Product's homepage

Requirements:

· Perl