There's that, and there's also the ease of prototyping an application really, really fast when scaffolding is available. Without such scaffolding, you may end up taking a month to build a prototype. It certainly depends on the complexity of the project, however, speed may be more important in some cases. I am mostly referring to being able to say "I can show you something right now" to your manager/client/etc. Stuff like this really raises your level of credibility.
Another thought: is catalyst.pl not a form of scaffolding already? We don't create our application skeletons from scratch with our bare hands. Even the wisest samurai would never resort to such activity. Not meaning to start a holy war, -- Max Afonov Perl developer MLB Advanced Media Zbigniew Lukasiak wrote: > Dear all, > > First I hope Matt shall excuse me for restarting the discussion here - > but I'd like to reach more Catalyst users then the limited number of > IRC dwellers. > > I would like you to imagine you in the position of a developer that > has some idea for a web project, thinking about trying a new web > programming framework. There are many to choose from, or he can also > go the simple way and use CGI.pm or develop something for his own - > how would you decide? Every framework is lots of code, lots of > documentation so it's not an easy task. After reading those mountains > of manuals you can discover that some limitations make the framework > not really fitting to your project (some related thoughts in > http://www.artima.com/weblogs/viewpost.jsp?thread=8826). This is that > risk that scaffolding mitigates - you generate your application with > minimal effort and you have a working example tailored to your > database schema. You don't need to think if a example from the manual > can be adopted to your data structures - you have it adopted > automatically. This is the first advantage of scaffolding - easy > evaluation. > > The other important advantage is that it helps in the learning > process. You get a non trivial working example. And again this > example is based on your database schema - from the starting point you > at once know much about the program. You don't need to internalize > some the business rules of some unfamiliar application - the business > rules are yours - so at once you can start and play with it. And a > good scaffolding will give you much space for simple but meaningful > modifications to tweak and play with. > > Of course there are also disadvantages to code generation. It is > impossible to come with a good schema to update the generated code > when you release a new version of the generator and we don't want the > programmers who use the scaffolding to be stuck forever to the version > that they used the first time. One solution can be to limit the code > generator to really most trivial part and move all other logic into > traditional libraries that just happen to cooperate with the generated > code - and this is what I try to do with InstantCRUD. > > -- > Zbigniew Lukasiak > http://brudnopis.blogspot.com/ > ------------------------------------------------------------------------ > > _______________________________________________ > List: Catalyst@lists.rawmode.org > Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ > Dev site: http://dev.catalyst.perl.org/ > ************************ MLB.com: Where Baseball is Always On _______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/