Re: Evaluating Catalyst and other frameworks

[Chris Travers <..hidden..>]

Hi Roderick;

On Tue, Mar 9, 2010 at 1:52 PM, Roderick A. Anderson
<..hidden..> wrote:
> Chris Travers wrote:
>> Hi all;
>>
>
> Catalyst fan here though it has been awhile since I did any actual coding.
>
> I've been avoiding the discussion up to now since it was mostly heading
> in (my idea of) the correct direction.  :-)  Since I want to help and
> being in at the beginning, verses reverse knowledge engineering, is
> easier I'm chiming in now.

Ok.  Thanks for the input.    BTW, one thing you will note is that I
am not suggesting drop any attempts to make Catalyst-compatible
modules.  There is a substantial chance that if catalyst-compatible
mappings were done, that it would provide a great deal of benefits to
both projects.  However, some of our design criteria are unusual
because most of us are more db-centric than most other apps, and for
an accounting app, I think this is a good thing.
>
>> 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:
>>
>> 1)  Our model
>
> Current model or _planned_ "thick" model. (Not sure what the proper term
> is for what is proposed, ie. everything model and generic business-rule
> wise that will fit and work in the database.)

1.3/2.x model.
>
> If you're thinking of getting the current model into Catalyst then there
> would be some _work_ to do!

No way would I suggest porting the inherited codebase over to anything....
>
> If the new model then designing and creating it will be choke point.

Sure.
>
>> 2)  Authentication handlers and session handlers
>
> There are some excellent tools for this that are available for
> "Catalyst" already.

I spent some time asking around the Catalyst IRC channel and it seems
that authenticating against native db accounts, and the way we
actually use sessions in the db would both require some porting on our
side.
>
>> 3)  While HTML templates could use appropriate Catalyst classes,
>> LaTeX-based views would need to be ported....  Similarly plaint text
>> templates might or might not be able to be handled directly.
>
> I thought LSMB was using TT already.  Should be very minor/few changes
> make them work.

Yep.  However, the problem is a different one.

First, data has to be escaped before handing it to TT.  The escaping
criteria are different for different formats.....
>
>> 4)  Printing directly to a printer would require subclassing existing views....
>>
>> I don't see this being simpler on any other framework unless it
>> supports the sort of stuff we're doing and that would be unusual.
>
> OK. I guess you're thinking of doing this for 1.3+.  All Catalyst
> related comments above should be nullified for now.  :-)

Not prior to 2.0 :-).

This being said....  there are some really cool things that could come
out of such an effort.  In particular, it might allow other folks who
are doing db-centric app design to use frameworks of that sort as
well.

Hope this helps,
Chris Travers