in reply to Transferring a Catalyst installation

This "crust" method of supplying templates for your own code is one of two reasons why I'm not comfortable with catalyst and I'm really thinking of using CGI::Application in my upcoming web project.

Do you have any info on how the crust changed over time? Should be easy to find out, just use myapp_create.pl with an old catalyst version and a new one, then diff. If you see functional differences then catalyst has a design weakness, otherwise it probably is no fault of the "crust". It also depends on what else myapp_create.pl is doing. If it modifies internal configs or lists, it might be even worse. But that is a question best put to someone working in the catalyst team

  • Comment on Re: Transferring a Catalyst installation

Replies are listed 'Best First'.
Re^2: Transferring a Catalyst installation
by thargas (Deacon) on Nov 02, 2010 at 15:52 UTC

    I have to agree with you about the crust. I've had to patch Catalyst::Helper's templates (site specific; don't ask) to get catalyst to generate working scripts. It'd be nice to have a standard way that a site could hook site-specific stuff in here without having to maintain this kind of thing.

    You said two reasons. What's the other one?

      The other reason is that I think the strict MVC model is not consistent with a good object oriented design . Not my own idea, there was a nice article that convinced me (it may have been the paper talked about here UPDATE: No, it was a different one, but making a similar point).

      Now I have not much practice in OO programming and none in web programming, so don't listen to me. But the paper makes some very good points.

      Also the data of my web project is very "departmentalized" (i.e. one web page would usually access two and write to one small part of the whole information), this makes files instead of a database possible and quite frankly I loathe databases when it comes to maintenance and debugging

      Catalyst seems to adhere more strictly to the MVC design, with separation strictness and its reliance on a database, so that CGI::Application may be a better fit for me even though I also spotted some things I don't like there too.

      I really haven't decided yet. For example catalyst seems to depend on database use, only the older of two books about Catalyst mentions how to avoid a database, but it still seems possible to do. Same with object handling. Maybe I have to do a prototype first to help me decide

        Catalyst has no dependence nor restriction on any data or view layer at all. No data layer? Fine. 100 data layers including 10 DBs, 5 caches, file maps, webservice calls, parsers, random generators, also fine. No view, fine (but stupid because it means the controller has to do output). 100 views coexisting -- TT to Mason to JSON to XML to LaTeX to PDF -- also fine. The M doesn't mean RDBMS any more than the V means HTML.