AxKit-XSP-PerForm
view release on metacpan or search on metacpan
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].
=head1 SUBMISSION PROCEDURE
In PerForm, all forms submit back to themselves. This allows us to implement
the callback system. Of course with most forms, you want to go somewhere
else once you've processed the form. So for this, we issue redirects once
the form has been processed. This has the advantage that you can't hit
reload by accident and have the form re-submitted.
To define where you go on hitting submit, you can either return set the
I<goto> attribute on the submit or cancel button, or implement a callback
and return a URI to redirect to.
=head1 THE CONTEXT OBJECT
Each of the form callbacks is passed a context object. This is a hashref you
are allowed to use to maintain state between your callbacks. There is a new
context object created for every form on your XSP page. There are two
entries filled in automatically into the hashref for you:
=over 4
=item Form
This is actually an Apache::Table object, so it looks and works just like an
ordinary hashref, and contains the values submitted from the form, or is
perhaps empty if the form hasn't been submitted yet. It may also contain any
parameters passed in the querystring. For multi-value parameters, they can
be accessed via Apache::Table's get, add and set methods. See
L<Apache::Table>.
=item Apache
The Apache entry is the apache request object for the current request. You
can use this, for example, to get the current URI, or to get something out
of dir_config, or perhaps to send a header. See L<Apache>.
=back
To add an entry to the context object, simply use it as a hashref:
$ctxt->{my_key} = $my_value;
And you can later get at that in another callback via C<$ctxt->{my_key}>.
=head1 ARRAYED FORM ELEMENTS
Sometimes you need to display a list of items in your form where the number
of items is not known until runtime. Use arrayed form elements to trigger
the same callback for each item in the list. When setting up each element,
use an index to identify each member of the list. The callbacks will be
passed the index as a parameter. e.g.
Your form may have a section like this:
<xsp:logic>
for $index (0..$#shoppinglist) {
<p>
<xsp:expr>$shoppinglist[$index]</xsp:expr>
<f:submit name="SubmitBuy" value="Buy me">
<f:index><xsp:expr>$index</xsp:expr></f:index>
</f:submit>
</p>
}
</xsp:logic>
The submit callback might be:
sub submit_SubmitBuy {
my ($ctxt, $index) = @_;
return "purchase.xsp?item=$index";
}
This example produces a list of items with a 'Buy me' button next to each
one. Each button has an index that corresponds an array index of an item in
the shopping list. When one of the submit buttons is pressed, the
submit_SubmitBuy callback will be triggered (as part of the submission
procedure) and the browser will redirect to a page that handles the purchase
of the associated item.
NOTE: arrays not supported for file-upload elements.
=head1 XSP INHERITANCE
Starting with AxKit 1.6.1 it is possible to specify a class which your XSP
( run in 2.262 seconds using v1.01-cache-2.11-cpan-39bf76dae61 )