Re: Evaluating Catalyst and other frameworks

[Chris Travers <..hidden..>]

On Wed, Mar 17, 2010 at 3:45 AM, Ed W <..hidden..> wrote:
> On 09/03/2010 21:11, Chris Travers wrote:
>> Hi all;
>>
>> I have spent some time looking at Catalyst to see what would be
>> required to make LedgerSMB run according to current development
>> approaches (close to the db, etc) and the result isn't easy.
>> Basically, at a minimum, the following would need to be ported:
>>
>
> Caveat I have only looked at Catalyst and not hacked in it...
>
> However, to a large extent you should be able to drop "code" into
> catalyst and use nothing more than the CGI handlers, plus the big blob
> of code which is sql-ledger?  The conversion to MVC is simply something
> which is highly desirable, but we had this discussion in the past and
> there is no reason you need to use any fancy ORMs or even anything other
> than "thick controllers" if you really don't want anything else?

Here's some more material that has come up since:

1)  Recent versions of Moose are not available on all major distros
without compiling from CPAN.  This makes packaging of Catalyst a bit
of a problem.  Consequently I don't think we can just push that
problem off to the packagers.  I don't want to give up on trying to
get into distros, so I think Catalyst is out as far as the primary
implementation.  I am open to other ideas though, and I have no
problem providing a separate port of many of our concepts to Catalyst
so that these concepts could be re-used by other developers as well.
(Dropping it into Catalyst wouldn't be too hard.)

2)  Currently there are some additional modules we would have to do
for things like views and auth.  More on this below.

>
> Also I'm not familiar with catalysts view rendering, but were I doing
> the views in rails (say) then not much would need to change to make it
> integrate the Latex stuff, I would just render the template to a file
> and stream the file.

The answer I got from folks in the Catalyst community is that
Template::LaTeX works out of the box.   However, that's not the whole
issue regarding views.  The basic issue is that we want to autoescape
all data going to a template for security reasons.  While
Template::Stash::Autoescape has been suggested as a solution, the
current core team has concerns about the maturity of that module and
are not sure that such would be the appropriate solution for our
project to rely upon.

Consequently we would have to subclass the view modules in order to do
this escaping ourselves.

> In rails I use some views which are stored in a
> database, some from flat files and some generated from a composition of
> templated templates which are composed hierarchically from other
> templates... I would be highly surprised to find that there is not at
> least the same level of flexibility to do the same in Catalyst?

The basic issue here is just that of ensuring that every variable is
escaped in every template.  This is to avoid things like persistent
XSS, and exploiting certain LaTeX configurations in order to execute
arbitrary shell commands on the server (all kinds of bad stuff....).
While it is true that a bad template can mess with your data, asking
template designers to assess the security implications of escaping
some data strikes me as asking for trouble.

> Unless you are a rails genius it might not help much, but there is an
> interesting Admin Site generator called ActiveScaffold which is worth
> picking ideas from.  They use an approach which builds templates from
> sub templates going down quite a few levels and making it very easy to
> override parts of the generic templates, customise the language, etc.
> The application is very different, but some of the basic ideas would
> translate very nicely and be useful

The second issue has to do with authentication and sessions, and the
fact that we are using these things in ways which are somewhat
atypical.  Most web auth stuff is assumed to work against a persistent
password store which the application accesses.  This is not what we
do.  We actually pass the credentials onto a third party (in this case
PostgreSQL) to check against it's password store.  A successful
authentication attempt will create a database connection which is then
available to the application to use.  Also, for this to work, we have
to remove database connections after each request.  While this can be
done, it just means that we have to come up with a way of gracefully
doing this in a way which is fairly native to the Catalyst framework
(I am aware we don't actually have to do that, but if we are going to
support Catalyst, I would rather support it all the way, not just use
it as a wrapper for mod_perl).

Similarly, regarding sessions, these are not just flat representations
of application session data.  These are fairly complex objects which
interface with the web application and database in a variety of ways.
Disclosure of session data is security critical and so it is one of
the few tables which will probably long-term be "security-definer
only" for access.

I don't think this would be too bad to port (would probably be the
easiest of the three areas).....

Best Wishes,
Chris Travers