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

[Michael Graham <suppressed>]

Dan, thanks for all the great comments!

> >   * 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

Cool!  I'm going to attempt the same kind of thing at work.  We're using
a homegrown legacy mod_perl app with its own templating system. I'm
going to switch over to CGI::Application (eventually).

So I started by making an AnyTemplate driver for our legacy templating
system.  I'm going to convert our apps to C::A while continuing to use
our existing templates.  Then after the apps are written I can switch the
templates over to TT.

Mind you, If I'm honest I'll admit that I'm only really doing it this
way because I can :)

But I'm glad that other people are finding this approach useful.  When I
was designing AnyTemplate I knew we needed the CAF to support multiple
template systems, but I wasn't really sure that anyone besides me would
find it useful or interesting to mix and match templates in the same
project.

> >   * 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?

That's a good question.  I mostly use postgres these days, and I don't
have much recent experience with mysql.  Also (until now) I've always
hand-rolled all my Class::DBI classes for my own projects.  This is
mainly because I'm a control freak and I've never learned to trust the
automatic schema detection tools to "get it right".

But I think I'm comfortable with the balance that the CAF Example
project tries to strike, which is to use Class::DBI::Loader to detect
the columns, but explicitly declare the relationships myself.

> As others have mentioned, it would be nice to have run modes separated from
> authentication, and I understand that this is in the offing.

[...]

>     $self->param(
>         '_run_modes',
>         {
>             'mode1' => {
>                 'method'      => 'content_form',
>                 'permissions' => [qw(writer editor admin)]
>             },


This actually does look similar in spirit to Cees's CAP::Auth module.

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

...and this is a cool idea.  I really like providing a lot of hooks for
at different levels, but also providing defaults at each level.

So check_permissions could easily do:

    sub check_permissions {
        my $self  = shift;
        my $user  = $self->get_current_user;
        my @roles = $self->get_runmode_roles;

        return $self->user_has_roles($user, @roles);
    }

Override this one method and you get a completely different auth system.
Or better still, different auth strategies would be available as
plugins.

> 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.

It's not finished yet.  Jason Yates was working on it most recently -
his announcement (including a link to the tarball) was made here:

    http://www.mail-archive.com/suppressed/msg02928.html

> >   * Link Integrity system
>
> I don't quite understand this. Does this mean that we no longer construct
> links ourselves?

The idea is that you use the make_link API to create all your links.
The interface isn't quite finished, but the idea is you do something
like this:

    my $url = $self->make_link(
        url    => '/cgi-bin/app.cgi/Admin/docs',
        params => {
            'rm'  => 'edit',
            'gid' => 72,
        },
    );

    $self->template->fill({ edit_doc_url => $url });

And then in your template:

  <a href="<TMPL_VAR NAME="edit_doc_url">">Edit</a>

This will make a link that looks something like this:

  <a href="/caf/app.cgi/Admin/docs?rm=edit&gid=72&_checksum=abcdef">Edit</a>

It's the "abcdef" that's important.  In reality it would be a long hex
number.  The checksum prevents users from attempting to break into your
application by messing with the parameters in the URLS.  If the user
changes the 'doc' param to 73, the checksum won't match and the system
will treat it as a break-in attempt.

> 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

We've really have got to start stealing more stuff from Catalyst!
Having said that, I wonder how you control access to static files
without using HTTP Auth?  Unless you just have a very lightweight cgi
script that does a quick auth check and streams the static files.

> 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.

I'd like to say that the API is solid, and a lot of it is, but I know
that there are still three key areas in heavy development:

  * The Link Integrity system will likely become CAP::ParamIntegrity

  * The sessioning system currently uses Apache::SessionX but we may
    change to CAP::Session

  * The auth system may change to CAP::Auth or something new based on
    these discussions

> 3. Is C:A:F largely done, or a whole lot of features envisaged?

Here's my personal wishlist (I'm sure Richard also has his own ideas on
this):

   * Core features
     * Better out-of-the-box support for mod_perl and PersistentPerl
     * Unauthenticated sessions support
     * Better defaults, so a starter Project can be a one-liner
     * CAP::ParamIntegrity
     * Authorization system
     * Make it easier to push config values to templates
     * Improve docs
     * Improve test coverage
     * Improve error messages and diagnostics
     * Improve example apps

   * Add-on features
     * Improved tools for form building
     * Improved tools for passing form data to CDBI objects
     * Project package management (bundle and unbundle)
     * PAR installer support

   * Applets and tools
     * User & Group manager
     * Various CMS features


Michael


-----------------------------------------------------------------------
Michael Graham <suppressed>

YAPC::NA 2005 Toronto - http://www.yapc.org/America/ - suppressed
-----------------------------------------------------------------------


---------------------------------------------------------------------
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