On Wed, Feb 13, 2002 at 10:56:25AM +0100, Jonas Liljegren wrote:
> The examples consists of just one page. I would like to se how it
> works then you move between diffrent pages. Why not an example with a
> typical DB interface with just search, list and view pages?
In the current (v2) model, you have a bunch of slots which get called
in turn. e.g.
* -> get a session
* -> do something codelike
* -> generate some output
* -> free up the session
It's quite difficult to serve multiple pages without having to hardcode
lots of messy stuff.
With the new architecture, slots are named and a separate dispatch list
determine which slots get called.
SLOTS => {
session => # a module/code/service to get a session
codelike => # ditto to do something codelike
output => # ditto to generate some output
},
DISPATCH => [ qw( session codelike output ) ]
Slots can schedule cleanup operations to make things like cleaning up
sessions happen automatically (i.e. we no longer need to explicitly
schedule something to free up the sesssion).
Best of all is that the DISPATCH list can be generated at runtime based
on a particular algorithm (e.g. mapping URL to dispatch lists):
DISPATCH => OpenFrame::Dispatch::URL->new({
'/search' => [ qw( foo bar baz ) ],
'/edit' => [ qw( wiz bang waz ) ],
'/view' => [ qw( crash bang ) ],
});
You could just as easily dispatch a series of slots based on a CGI parameter,
environment variable, etc., and if that's not enough, you can provide a CODE
ref to determine the DISPATCH list based on your own algorithm:
DISPATCH => sub { my $request = shift; return \@whatever };
I think these changes will make OpenFrame much more generic, useful and
easier to deploy.
A
