[Pangloss] [RFC] OpenFrame AppKit ideas

[Steve Purkis]

Hi,

This is a [long] cross-posted message.  Please watch replies.

Following are some of my working notes on adding some features to 
OpenFrame + AppKit.  My eyes are going fuzzy from reading it over too 
much, so I thought I'd best post it and see what people have to say :).


Application Kit
---------------
OpenFrame::AppKit is a good example for OpenFrame, but it doesn't
quite meet my needs.  For example, it limits:

     +	Support for different template engines (Petal)
     +	Support for multiple languages / localisation
     +	Cookie-less Sessions

With some refactoring, I could achieve the above:
     +	write a Petal segment
     +	move hard-coded HTML out of Segments that use it,
	sub-class & wheel in Locale::Maketext or Locale::gettext
     +	make SessionLoader segment abstract, then subclass for
	Cookies, URL's, and Form params.

But I still wouldn't be happy, because while the AppKit does a lot
of things I like, it also does things I don't agree with.  Like:

I'm forced to invent a way of handling errors.  I suppose I could
just stick them in the Session and let the template writer deal
with it.  But then I gotta remove them on each request, and what
if I want to handle them before they get to the template?

Also, session storage should be more flexible - disk, memory, db,
etc.  Could make a cache interface and pass in a Disk/Memory cache
to the SessionLoader as desired.

But most importantly, I'm not convinced entry points are a good
idea.  They don't give enough control over the path of execution:
     +	What if the user leaves some required form fields blank?
	The entry point wouldn't fire, so you'd have to write
	lots of entry points in order to tell them what they need
	to fill in order to continue.
     +	What do you do if your parameter names are generated on
	the fly?

I'd prefer something that just dispatches a request to an object
based on the URI's path (ie: DispatchOnURI).


Alternative: Actions
--------------------

So with that in mind, I thought maybe the OpenFrame AppKit could do
with some tools similar to Jakarta's Struts?  For those of you not
familiar with Struts, I'll sum up what I think are some of its major
advantages:

   Actions
	A thing that gets done, like logging in, making a payment,
	or displaying a summary.  These are usually short 'n sweet
	ie, a thin layer passing messages to your app objects.

   Validating 'Action Forms'
	Each Action can have a Form with instance vars that are
	filled out from the HTTP request params of the same name.
	Or you can fill it out yourself, which is handy when your
	params are generated on the fly from a db or something.
	This form is then validated (ie: to make sure required
	fields are present and not garbage).

   URL -> Action mapping
	Each Action has a url, set in a config file.

   Action Forwards
	Each Action can have one or more named 'forwarding' url's
	which can be used to choose which template page to load.
	    success => "/success.html"
	    failure => "/failure.html"
	these are also set in a config file.

   Errors
	Named flags that are looked up in a messages file.
	Which means no more hard-coded HTML, and translatable
	message files.

   Scope
	There's 3 levels of variable scoping - jsp page, request,
	and application, which is handy.
		

Struts/JSP does a lot of other things for you.  Most make sense
for Java, and there are lots of other neat ideas, but I don't
want to bite off more than I can chew.


Actions Plan
------------

So if we start off with the above, and mix it with the things I
like about the AppKit, and Perl in general, bake for 3 hours and
let cool, we end up with something like this...

   OpenFrame::AppKit::Action	<abstract>
     +	dispatch_on_uri()
	validates & executes this action.
     +	validate()
	validates Request in store, producing an ActionForm.
     +	execute()
	executes the action...
	On success produces a Template (similar to idea of forwarding
	could get template from a config file, for example)
	Any Messages or Errors are stored in the pipe.

   OpenFrame::AppKit::Action::Form
     +	simple hash.  will probably look like the Request, but
	may differ if validate() processes things, like
	stripping .X/.Y off of image inputs.

   OpenFrame::AppKit::Session
     +	reserve the names:
		errors
		error.*
	for errors
     +	add localisation hooks here?

   OpenFrame::AppKit::Errors
     +	request-scope error flags
     +	this class would look just like Session except:
		has_errors()
     +	add localisation hooks here?

   OpenFrame::AppKit::Template
     +	Template name, and other params potentially.  Would be
	used by TT2, which currently gets template name from the
	Request.

   OpenFrame::AppKit::Segment::TemplateLoader	<abstract>
     +	Can be sub-classed for your favourite templating system
	(TT2, Petal, etc.).
     +	Looks for OpenFrame::AppKit::Template object in Store.
     +	Creates template processing vars with scoping like this:
	  Session	no prefix
	  Errors 	'error.' prefix
	So it's easy to add other scoped variables.  all you need
	to do is reserve a prefix (or sub-class)...

   OpenFrame::Response::NotFound
     +	HTTP 404 error, replacing hard-coded version in
	OpenFrame::Segment::ContentLoader
     ?	Not ideal, but easier to localise than current version.

   OpenFrame::Response::InternalError
     +	HTTP 500 error, replacing hard-coded version in
	OpenFrame::Segment::HTTP::Response
     ?	Not ideal, but easier to localise than current version.


Localisation
------------
I'm still a bit fuzzy on this.  AFAICS, localisation needs to
be done in three places:

	1. Reporting Application Errors (404, 500, etc.)
	2. Choosing which template to process
	3. Displaying messages to the user from a template

Which means we need hooks in these places.  But perhaps the
problem could be solved in general by a Localisation segment
that puts something in the Store that other segments can use?


Configuration
-------------
Again, something I've not thought through.  Perhaps have a Config
object in the pipeline's Store.  Or maybe this would be better
left to the developer?


-Steve