NAME

Form::Factory - a general-purpose form handling API

VERSION

version 0.010

SYNOPSIS

  ### CGI, HTML example
  my $interface = Form::Factory->new_interface('HTML');
  my $action  = $interface->new_action('MyApp::Action::Login');

  ### Drawing the form contents
  $action->unstash('login');
  $action->globals->{after_login} = '/index.html';
  $action->stash('login');
  $action->render;
  $action->render_control(button => {
      name  => 'submit',
      label => 'Login',
  });
  $action->results->clear_all;
  
  ### Processing the form result
  my $q = CGI->new;
  $action->unstash('login');
  $action->consume_and_clean_and_check_and_process( request => $q->Vars );

  if ($action->is_valid and $action->is_success) {
      $action->stash('login');
      print $q->redirect($action->globals->{after_login});
  }
  else {
      print q{<p class="errors">};
      print $action->error_messages;
      print q{</p>};
  }

DESCRIPTION

ALPHA API. This code is not fully tested (if you look in the test files you will see a long list of tests planned, but no yet implemented). It is currently being employed on a non-production project. The API will change. See "TODO" for more.

This API is designed to be a general purpose API for showing and processing forms. This has been done before. I know. However, I believe this provides some distinct advantages. However, you should definitely check out the alternatives because this might be more complex than you really need.

That said, why would you want this?

MODULAR AND EXTENSIBLE

This forms process makes heavy use of Moose. Nearly every class is replaceable or extensible in case it does not work the way you need it to. It is initially implemented to support HTML forms, but I would like to see it support XForms, XUL, PDF forms, GUI forms via Wx or Curses, command-line interfaces, etc.

ENCAPSULATED ACTIONS

The centerpiece of this API is the way an action is encapsulated in a single object. In a way, a form object is a glorified functor with a run method responsible for taking the action. Wrapped around that is the ability to describe what kind of input is expected, how to clean up and verify the input, how to report errors so that they can be used, how entered values can be sent back to the orignal user, etc.

The goal here is to create self-contained actions that specify what they are in fairly generic terms, take specific action when the input checks out, to handle exceptions in a way that is convenient in forms processing (where exceptions are often more common than not) and send back output cleanly.

MULTIPLE IMPLEMENTATIONS

An action presents a blueprint for the data it needs to work. A form interface takes that blueprint and builds the UI to present the user and consume the input from the user to present back to the action.

As mentioned above, a form interface could be any kind of UI. The way the form interface and action is used will depend on the form interface implementation, but the action itself should not need to care overmuch about that. It might specify something related to a specific interface, but it would still work with a different interface anyway.

CONTROLS VERSUS WIDGETS

We specifically separate the logic for specifying controls from the widgets implementing those controls. A control specifies that the action expects some user input and a description of how that data is expected. The widget then implements that using whatever form control is most appropriate.

FORM FEATURES

Forms and controls can be extended with common features. These features can clean up the input, check the input for errors, and provide additional processing to forms. Features can be added to an action class or even to a specific instance to modify the form on the fly.

METHODS

new_interface

  my $interface = Form::Factory->new_interface($name, \%options);

This creates a Form::Factory::Interface object with the given options. This is, more or less, a shortcut for:

  my $interface_class = 'Form::Factory::Interface::' . $name;
  my $interface       = $interface_class->new(\%options);

interface_class

  my $class_name = Form::Factory->interface_class('HTML');

Returns the interface class for the named interface.

control_class

  my $class_name = Form::Factory->control_class('full_text');

Returns the control class for the named control.

feature_class

  my $class_name = Form::Factory->feature_class('functional');

Returns the feature class for the named feature.

control_feature_class

  my $class_name = Form::Factory->control_feature_class('required');

Returns the control feature class for the named control feature.

TODO

This is not definite, but some things I know as of right now I'm not happy with:

• There are lots of tweaks coming to controls.

• Features do not do very much yet, but they must do more, especially control features. I want features to be able to modify control construction, add interface-specific functionality for rendering and consuming, etc. They will be bigger and badder, but this might mean who knows what needs to change elsewhere.

• The interfaces are kind of stupid at this point. They probably need a place to put their brains so they can some more interesting work.

CODE REPOSITORY

If you would like to take a look at the latest progress on this software, please see the Github repository: http://github.com/zostay/FormFactory

BUGS

Please report any bugs you find to the Github issue tracker: http://github.com/zostay/FormFactory/issues

If you need help getting started or something (the documentation was originally thrown together over my recent vacation, so it's probably lacking and wonky), you can also contact me on Twitter (http://twitter.com/zostay) or by email.

SEE ALSO

Form::Factory::Interface::CLI, Form::Factory::Interface::HTML

AUTHOR

Andrew Sterling Hanenkamp <hanenkamp@cpan.org>

COPYRIGHT AND LICENSE

Copyright 2009 Qubling Software LLC.

This library is free software. You can redistribute it and/or modify it under the same terms as Perl itself.

cpanm Form::Factory

perl -MCPAN -e shell
install Form::Factory