[Perl-workflow-devel] Changes commited for developer release 1.33_6

[Alejandro I. <ai...@p2...>]

Hi all,

I have committed my proposed changes to the branch "field_types",
corresponding to the next correlative developer release 1.33_6
(committed to svn revision 491)

These changes allow users to formally override new() in Actions and
InputFields to better adapt Workflow.p;m to their specific
implementations. My first thought at this was to extend and complete
the InputField "type" which was a work in progress according to the
pod, but later realized that this be better left implementation
dependent, and it was way more generic to formalize an extension
mechanism for actions and fields.

Here are the detailed changes:


aimass@ctlt10:~/projects/perl-workflow/branches/field_types$ svn log -v -r491
------------------------------------------------------------------------
r491 | aimass | 2009-09-26 14:05:54 -0400 (Sat, 26 Sep 2009) | 1 line
Changed paths:
   M /branches/field_types/workflow/Changes
   M /branches/field_types/workflow/lib/Workflow/Action/InputField.pm
   M /branches/field_types/workflow/lib/Workflow/Action.pm

formalization of action and input field extentions by making new()
formally public and safely overrideable; modified pod accordingly with
detailed examples
------------------------------------------------------------------------

aimass@ctlt10:~/projects/perl-workflow/branches/field_types$ cat
workflow/Changes

# $Id: Changes 491 2009-09-26 18:05:54Z aimass $

1.33_6

Patches from Alejandrop Imass

- Changed @FIELDS to @PROPS in Action.pm and InputField.pm for
  mk_accesors as FIELDS was very confusing with regard to action input
  fields.

- Formalized Workflow::Acction::new() as a public method with
  corresponding pod example.

- Optional class property for Workflow::Action::InputField.
  Previously, public method new() made little sense if InputField
  always instantiates from Workflow::Action::InputField. Now fields
  can derive from custom class.

- Updated pod to reflect the new formal abillity to add extra
  properties for actions and input fields.

- With the ability to derive custom properties for classes and fields
  there is little need IMHO to define InputField "type" any further
  but leave it implementation dependent. The rationale is that
  validators intrinsically define this. Updating pod accordingly.