pjs/webtools/PLIF/PLIF
ian%hixie.ch b05e2a3df8 Don't add NULLs to the database when setting a field 2004-02-25 19:23:17 +00:00
..
DataSource Don't add NULLs to the database when setting a field 2004-02-25 19:23:17 +00:00
Database remove DESTROY code, rework the output system to use a single hash instead of passing arguments around, delay the loading of certain modules, fix some bugs with the removal of the built in property system, make the TemplateToolkit module only have one template object, and cache the precompiled documents, remove the HTTP output module, and other optimisations. 2003-03-15 14:14:21 +00:00
DatabaseHelper Stop perl parsing source files that aren't used. (Lazy loading using __DATA__ blocks) 2003-03-14 07:50:18 +00:00
Input Report an internal error when we have a malformed submission. Really we should return an error 400 but that can wait. 2004-02-25 19:19:51 +00:00
Output missed this in earlier changes 2003-07-03 17:59:17 +00:00
ProtocolHelper Improve the Exception class so it can work out what 'eval' numbers map to; remove the 'properties' stuff since it was taking a good 4% of the overall time of PLIF applications. THIS WILL CAUSE HUGE PROBLEMS WITH PLIF CONSUMERS. I REPEAT, THIS **WILL** BREAK YOUR CODE. DO NOT UPDATE TO THIS CODE IF YOU DON'T WANT TO SPEND A LOT OF TIME UPDATING YOUR CODE\!\!\! 2003-03-14 13:08:43 +00:00
Service Fix two misuses of pseudo-field methods (they are not lvalues). 2004-02-25 19:22:31 +00:00
Application.pm Stop perl parsing source files that aren't used. (Lazy loading using __DATA__ blocks) 2003-03-14 07:50:18 +00:00
Controller.pm Comment out the debug code in the DESTROY handler 2003-03-27 19:52:23 +00:00
DataSource.pm Improve the Exception class so it can work out what 'eval' numbers map to; remove the 'properties' stuff since it was taking a good 4% of the overall time of PLIF applications. THIS WILL CAUSE HUGE PROBLEMS WITH PLIF CONSUMERS. I REPEAT, THIS **WILL** BREAK YOUR CODE. DO NOT UPDATE TO THIS CODE IF YOU DON'T WANT TO SPEND A LOT OF TIME UPDATING YOUR CODE\!\!\! 2003-03-14 13:08:43 +00:00
Database.pm remove DESTROY code, rework the output system to use a single hash instead of passing arguments around, delay the loading of certain modules, fix some bugs with the removal of the built in property system, make the TemplateToolkit module only have one template object, and cache the precompiled documents, remove the HTTP output module, and other optimisations. 2003-03-15 14:14:21 +00:00
DatabaseHelper.pm Improve the Exception class so it can work out what 'eval' numbers map to; remove the 'properties' stuff since it was taking a good 4% of the overall time of PLIF applications. THIS WILL CAUSE HUGE PROBLEMS WITH PLIF CONSUMERS. I REPEAT, THIS **WILL** BREAK YOUR CODE. DO NOT UPDATE TO THIS CODE IF YOU DON'T WANT TO SPEND A LOT OF TIME UPDATING YOUR CODE\!\!\! 2003-03-14 13:08:43 +00:00
Exception.pm To get around some weirdness sometimes (you never know WHAT state you're in when you're in the middle of an exception handler...), use UNIVERSAL::isa() instead of the isa() method. 2004-02-25 17:50:24 +00:00
Input.pm Fix fallout in the Input modules from the removal of implied properties 2003-03-27 19:50:40 +00:00
MagicCollectingArray.pm
MagicPipingArray.pm Changed the magic piping array so that it is more consistent by removing the special casing of when there is only one return value. 2001-09-09 19:04:37 +00:00
MagicSelectingArray.pm Removed an unused variable. Made the selecting array always return an array even in scalar context. This makes using it in |if| statements a lot easier. 2001-12-26 19:03:07 +00:00
Output.pm Improve the Exception class so it can work out what 'eval' numbers map to; remove the 'properties' stuff since it was taking a good 4% of the overall time of PLIF applications. THIS WILL CAUSE HUGE PROBLEMS WITH PLIF CONSUMERS. I REPEAT, THIS **WILL** BREAK YOUR CODE. DO NOT UPDATE TO THIS CODE IF YOU DON'T WANT TO SPEND A LOT OF TIME UPDATING YOUR CODE\!\!\! 2003-03-14 13:08:43 +00:00
Program.pm Improve the Exception class so it can work out what 'eval' numbers map to; remove the 'properties' stuff since it was taking a good 4% of the overall time of PLIF applications. THIS WILL CAUSE HUGE PROBLEMS WITH PLIF CONSUMERS. I REPEAT, THIS **WILL** BREAK YOUR CODE. DO NOT UPDATE TO THIS CODE IF YOU DON'T WANT TO SPEND A LOT OF TIME UPDATING YOUR CODE\!\!\! 2003-03-14 13:08:43 +00:00
README
Service.pm Stop perl parsing source files that aren't used. (Lazy loading using __DATA__ blocks) 2003-03-14 07:50:18 +00:00

README

PLIF: Program Logic Insulation Framework
========================================

Overview
--------

PLIF is based around the idea of services. Some more text really
should go here, don't you think?

Note that in this document, the term "provide a service" is used to
mean what some people term "implement an interface". The terms are
interchangeable. Due to Perl's amorphous nature, I found the term
"interface" to be a bit inappropriate, in my opinion it has
connotations of strictness that are not really applicable to Perl...


Services
--------

The following services (also termed 'interfaces') have meaning in the
basic PLIF design:

   input                     - implements all of the Input API
   input.verify              - provides a verifyInput() method
   output.<protocol>         - implements all of the Output API
   dataSource.<dataSet>      - provides a data source for dataSet
   dataSource.setupAware     - knows how to set up the database


input semantics
---------------

These are not simple. See the example implementations.


input.verify semantics
----------------------

If you provide input.verify, then you should expect to get called each
time a set of input needs validating. Input validation means stuff
like checking that an e-mail's format is correct, or authentication
the user if they have tried to log in, or whatever.

When your "verifyInput()" method is called, you should return nothing
(not even undef) if everything is ok, and a reference to an object
that has a reportInputVerificationError() method if something went
wrong. If you return yourself (i.e., if you implement both methods
being discussed here), remember that there is no guarentee that you
will be destructed before the next time you are called, so don't
design your verifyInput() method in a way that assumes you won't have
pre-existing state. Also, since there is no guarentee that your
reportInputVerificationError() method will be called, don't hold on to
any references like, say, input. If you do you might end up leaking
memory, which we don't want!

Verifiers will be called in the order they were registered. If any
fail (i.e., return an object) then the verification loop is aborted.
For this reason, you should register verifiers in the order that they
are most likely to fail so that the loop ends in the shortest time.

If successful, the verifiers should initialise any objects (like user
objects from successful authentication) using $app->addObject(). The
first object claiming to provide the 'session' service is the object
that will be passed (by default) to output services.



output.* semantics
------------------

Output uses the following kind of command flow through services:

                   logic
                     |
           +---------+---------+
           |                   |
   output.<protocol>    output.generic
                               |
                  +------------+------------+
                  |                         |
        string.expander.<string>     string.expander
                  |                         |
                  +------------+------------+
                               |
                   output.generic.<protocol>


string.expander semantics
-------------------------

These services provide and |expand| function that takes four
arguments: the application object, the name of the protocol, the name
of the string to expand, and the data hash. The function should return
an opaque string.


dataSource.setupAware
---------------------

Most data sources are expected to provide the "dataSource.setupAware"
service, which basically means that they have a setup method that does
whatever is required to the databases. We should also introduce some
uninstall awareness, some default data populatingness, and stuff...


Class Tree
----------
                                    CORE
                                     |
                 +------+------------+-------------------+
                 |      |            |                   |
                PLIF   ...    MagicPipingArray  MagicSelectingArray
                 |
       +---------+-----------------------+--------------------+
   Controller                            |                    |
       |                              Service                DBI
    Program                              |              (ResultsFrame)
       |                                 |
  Application     +--------+-------+-----+-----+-------+-------+--------+
       |          |        |       |           |       |       |        |
      ...    DataSource  COSES  DataBase     Input   Object  Output   StdOut
                  |                |           |       |       |    (Outputter)
  +--------+------+----+        +--+--+    Arguments  ...   +--+--+
  |        |           |        |     |        |            |     |
 ... Configuration  Strings  CfgFile DBI +-----+-----+     ... Generic
                       |                 |     |     |
                     MySQL        CommandLine CGI Default



Contributions
-------------

Please make sure you read the STYLEGUIDE if you want to consider
writing code.