RE: [cgiapp] ANNOUNCE: CGI::Application::Framework (pre-release)

["Dan Horne" <suppressed>]

> CGI::Application::Framework is a fully-featured web 
> application development platform built on CGI::Application.

That's great! I wrote my first app with CGI::App and the first thing I
wanted to do when I finished was refactor the whole thing, as I realised I
could have done things a lot better. One reason is that until I'd used the
tool, I wasn't quite sure of the best way to do things. Plus I also learnt a
lot from reading the plugins (thanks, guys!), but these were coming out as I
was developing the code, so only the newer modules make use of some of these
practices...

> 
> Richard Dice and I have been developing it for the past six 
> months, and it grew out of an earlier system that Richard 
> made on his own called the MVC Framework.
> 

... I've been looking at Catalyst. It has a lot of features that I like, and
it does a lot for you, but it I like CGI::App. CGI:App is easier to get a
handle on, and the documentation is very good. Catalyst seems rather large,
and it's a bit daunting to know where to begin (plus the doco is pretty
sparse). The release of C:A:Framework seems to have arrived at the right
time for me

> 
> 
> Features:
> 
>   * Based on CGI::Application
>   * A recommended layout for modules, templates, config files etc.
>   * Choice of templating system (via CAP::AnyTemplate)
>     * HTML::Template
>     * HTML::Template::Expr
>     * Template::Toolkit
>     * Petal

This is excellent. I use H::T but I've been curious about TT. This allows me
switch templates without breaking anything

>   * Embedded page components (Headers, Footers, Navbars)
>   * Form Validatation and Sticky Forms (via CAP::ValidateRM)
>   * Easy (optional) Class::DBI integration

OT: I've never used Class::DBI - I've either used my own wrapper, or
hand-coded the SQL for the more complex queries. Does Class::DBI::Loader
understand the relationships between tables if you're using MySQL with
innodb?

>   * Session Management (Apache::SessionX)
>   * Authentication
>   * Login Managment
>     * login form
>     * relogin after session timeout
>     * form state is saved after relogin

As others have mentioned, it would be nice to have run modes separated from
authentication, and I understand that this is in the offing. Regarding
authorisation - I'm not a big fan of Catalyst's approach, at least as far as
I understand it. Roles are assigned to run modes and the framework checks
whether or not the user has any of the roles. However, in some applications,
roles are organised into hierarchies, with the understanding that higher
roles inherit from  lower roles - so some roles are implicitly assigned. I
wonder if something like this would work (excuse my Perl-Fu - I know it's
not as good as others on the list, but I hope this gets things across):

sub setup {
    my $self = shift;

    $self->start_mode('mode4');

    $self->param(
        '_run_modes',
        {
            'mode1' => {
                'method'      => 'content_form',
                'permissions' => [qw(writer editor admin)]
            },
            'mode2' => {
                'method'      => 'list_content',
                'permissions' => [qw(writer senior_writer editor admin)]
            },
            'mode3' => {
                'method'      => 'display_content',
                'permissions' => []
            },
		'mode4' => {
                'method'      => 'display_menu',
                'permissions' => []
            }
        }
    );
}

and then the class's prerun method checks the permissions and sets up the
run_modes

sub cgiapp_prerun {
    my $self = shift;
    die "Invalid permissions" unless $self->check_permissions();
    $self->run_modes($_, $rm{$_}->{method}) foreach (keys
%{$self->param(_'run_modes')}); 
}

sub check_permissions {
   # use whatever is appropriate DB , LDAP etc
}

It's up to the developers to code "check_permissions" depending on whatever
their business rules are - similar to the way that the login routines are
done with the new C::A::Framework. Perhaps this is how Cees' C:A:P::Auth
plugin works - as far as I can tell it's not on CPAN, so I haven't been able
to check.

> 
>   * Powerful configuration system (via CAP::Config::Context)
>   * Link Integrity system

I don't quite understand this. Does this mean that we no longer construct
links ourselves?

>   * Logging (via CAP::LogDispatch)
> 

1. Catalyst also serves static files. That's nice if you publish to the file
system but still want a private section on an intranet - the Framework's
authentication model can mediate access
2. C:A:F is pre-release. How risky would it be to use it now? I don't mean
in terms of its quality - which I'm sure is good, but in terms of the APIs
changing.
3. Is C:A:F largely done, or a whole lot of features envisaged?

Dan


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed