[Catalyst] Why scaffolding? Validation and Learning
thomashartman1 at googlemail.com
Fri Aug 18 18:42:39 CEST 2006
The fact that InstantCrud "just worked" was an important factor for me, in
choosing to push forward with Catalyst rather than ROR, or one of the other
emerging web frameworks.
"Catalyst is Backed By The Power of CPAN" wasn't enough of a reason for me.
Yes, there are probably better reasons than InstantCrud created scaffolding
code that I could play with quickly. But for me, having something on the
home page that seemed to offer something comparable to what ROR and the
other shiny new frameworks have was definitely important.
I noted on the wiki homepage http://dev.catalyst.perl.org/wiki :
"InstantCrud: for getting your feet wet by installing a sample application,
I recommend this. On a relatively virgin catalyst install, with a non-root
account at a web hoster, I wasn't able to install any of the other "samples"
mentioned below. InstantCRUD, by contrast, seemed to Just Work."
It's a marketing thing. InstantCrud makes catalyst seem "shiny", at least it
had that effect for me.
2006/8/18, Matt S Trout <dbix-class at trout.me.uk>:
> Zbigniew Lukasiak wrote:
> > Some more technical details.
> > The main idea of how the scaffolding should work is that we generate
> > only a skeleton of directories, nearly empty controllers and some config
> > stuff. The generated controllers only contain their package
> > declaration and a 'use base Catalyst::Example::Controller::InstantCRUD'
> > line. So there is not that much of generated code here. After the
> > controllers are generated users are expected to copy the methods that
> > they want to modify from the Catalyst::Example::Controller::InstantCRUD
> > superclass - doing that they are taking responsibility for the copied
> > code. This way the main Instant controller, which is just a standard
> > library and can be updated with standard means, is also an integral part
> > of the example. The copying perhaps is not such a trivial step - but in
> > fact should be pretty natural for people working with Object Oriented
> > code - it's just overwriting of SUPER class methods. I am also planning
> > to make it more intuitive by the way of documentation.
> > This is the theory - in practice the config stuff required to have a
> > working application is a bit big, but we are working on it.
> > A separate thing are the templates for the views, in the current CPAN
> > version they are treated in a similar way that the controllers - the
> > users are expected to just copy the generic templates from the
> > InstantCRUD directory and modify them to their liking. There were
> > people on this list complaining about this and in the svn version now we
> > create the basic templates in the generated application. This means
> > problems with the templates when upgrading the library, but perhaps we
> > need to treat the templates separately from the code and expect them to
> > be really quickly rewritten by the programmers.
> We have an approach that allows standard templates to effectively be
> subclassed; once it goes to public announce I'd love to have your opinion
> them since templates are the hardest issue for scaffolding and it's clear
> you've done a fair bit of thinking about it.
> None of what I'm saying denigrates InstantCRUD - it's a very
> Scaffold and I recommend it to people regularly. I just think it's
> possible to
> achieve the same things a better way.
> Matt S Trout Offering custom development, consultancy and
> Technical Director contracts for Catalyst, DBIx::Class and BAST.
> Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more
> + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/
> List: Catalyst at lists.rawmode.org
> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive:
> Dev site: http://dev.catalyst.perl.org/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Catalyst