Re: [Catalyst] Why scaffolding? Validation and Learning
Hi Peter,I've reread the email you linked to. You write there about your own inventions on the subject of visual building of application. This is very interesting to me. Very ambitious also. If you need some help from the InstantCRUD side (common data structure, API whatever) - then email me. Nice to hear about people building something around Instant.--ZbyszekOn 8/17/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Dear Zby,First off thank you for writing InstandCRUD, it made it much easier for meto understand the Catalyst way of doing things.I posted some comments about frameworks here: http://lists.rawmode.org/pipermail/catalyst-dev/2006-July/000194.htmlThe problem with generated frameworks is shown in Visual C++ where yougenerate a screen then are stuck with manual changes after because if you go back to the meta-model and regenerate you lose code. So in that respectI agree with what Matt is saying.However, the problem facing most IT managers is that they have a majorityof average programmers who cannot handle more abstract design but can handle point and click interface building based on a data source.This competes somewhat with Catalyst's ideals to be lean, mean and nottied to a particular One True Way. The way I see it is that you need the core Catalyst, which is a pretty cool set of code, and a sample OTWapproach to get people started but which they can go beyond.We're using Catalyst in a project I'm managing and I hope very much thatone of the outcomes from that will be to make it easier for other people to use Catalyst. That is because I have tried (and failed) to pitchCatalyst to IT customers because it's too complicated as it is now fortheir staff.Best wishes,Peter Edwards http://www.dragonstaff.com - Business IT Consultancy___List: Catalyst@lists.rawmode.orgListinfo: http://lists.rawmode.org/mailman/listinfo/catalystSearchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/Dev site: http://dev.catalyst.perl.org/-- Zbigniew Lukasiakhttp://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/
Re: [Catalyst] Why scaffolding? Validation and Learning
The subclassing of templates sounds really interesting, but actually I don't have many strong convitions on this front - I think we need some more experimentation. Or perhaps I have one idea about the templates. I found it really simpler to code some more complicated parts as perl functions, put them on the stash and then use them as kind of macros in the templates, than coding it in the templating language. --ZbyszekOn 8/18/06, Matt S Trout <[EMAIL PROTECTED]> wrote: 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 besubclassed; once it goes to public announce I'd love to have your opinion on them since templates are the hardest issue for scaffolding and it's clearyou've done a fair bit of thinking about it.None of what I'm saying denigrates InstantCRUD - it's a very well-implementedScaffold 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 support Technical Directorcontracts for Catalyst, DBIx::Class and BAST. ContactShadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +___List: Catalyst@lists.rawmode.orgListinfo: 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/ -- Zbigniew Lukasiakhttp://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/
Re: [Catalyst] Why scaffolding? Validation and Learning
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.Thomas.2006/8/18, Matt S Trout < [EMAIL PROTECTED]>: 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 besubclassed; once it goes to public announce I'd love to have your opinion on them since templates are the hardest issue for scaffolding and it's clearyou've done a fair bit of thinking about it.None of what I'm saying denigrates InstantCRUD - it's a very well-implementedScaffold 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 support Technical Directorcontracts for Catalyst, DBIx::Class and BAST. ContactShadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +___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/ ___ 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/
Re: [Catalyst] Why scaffolding? Validation and Learning
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 on 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 well-implemented 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 support Technical Directorcontracts for Catalyst, DBIx::Class and BAST. Contact Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ + ___ 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/
Re: [Catalyst] Why scaffolding? Validation and Learning
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. -- Zbigniew Lukasiakhttp://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/
Re: [Catalyst] Why scaffolding? Validation and Learning
Max Afonov wrote: > 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. However this doesn't require scaffolding; the reflection approach I'm proposing instead (soon with code to back it up :) has all the same advantages here. Code-generation of any form where the generated code is then edited is almost invariably a code smell. > 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. I often use catalyst.pl in an empty dir, copy across a couple bits and then nuke the rest. I'm pretty sure we've got quite a few users now who don't bother with it at all. -- Matt S Trout Offering custom development, consultancy and support Technical Directorcontracts for Catalyst, DBIx::Class and BAST. Contact Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ + ___ 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/
Re: [Catalyst] Why scaffolding? Validation and Learning
I wanted to add something cogent to this discussion, but what I wrote sounded more like ranting, so it's been deleted. I do want to say this though - I don't remember whether it was rails scaffolding or InstantCrud, but I dislike horizontal crud forms. One line per db column please. Len. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. ___ 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/
Re: [Catalyst] Why scaffolding? Validation and Learning
Totally agree, and I guess this is why they call it 'scaffolding'. The word brings with itself the notion of the stuff being temporary. The need for scaffolding only goes away in an ideal world where management gets excited about ideas. However, these days, it's hard to pitch an idea unless you have a cool proof of concept to show off along with it. There's been so much vaporware that people no longer believe that something is cool unless it can be poked with a stick and taken for a swing. On the other hand, prototyping isn't the only area where scaffolding may be useful. In large projects, especially ones that are well managed, different parts of the application are assigned different priorities. Scaffolding may enable developers to defer thorough implementation of functionality that is less important or plays a purely supporting role, and focus on stuff that's higher on the list. In the case of Catalyst-based applications, most projects are so modular that scaffolding can be easily swapped in and out at any time. [EMAIL PROTECTED] wrote: > Yes, this is important. As you say, there's a commercial aspect to > pitching for work and showing prototypes. If you're using an Agile project > management methodology like DSDM, then doing several iterations of > modelling and delivery is essential in order to migrate closer to what a > customer needs rather than what they initially want. This only works for > small-medium projects, with larger ones in the long run you need a well > designed system or it will croak as the complexity increases and the code > base degenerates. > 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/
Re: [Catalyst] Why scaffolding? Validation and Learning
Hi Max, > 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. Yes, this is important. As you say, there's a commercial aspect to pitching for work and showing prototypes. If you're using an Agile project management methodology like DSDM, then doing several iterations of modelling and delivery is essential in order to migrate closer to what a customer needs rather than what they initially want. This only works for small-medium projects, with larger ones in the long run you need a well designed system or it will croak as the complexity increases and the code base degenerates. Regards, Peter ___ 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/
Re: [Catalyst] Why scaffolding? Validation and Learning
Dear Zby, First off thank you for writing InstandCRUD, it made it much easier for me to understand the Catalyst way of doing things. I posted some comments about frameworks here: http://lists.rawmode.org/pipermail/catalyst-dev/2006-July/000194.html The problem with generated frameworks is shown in Visual C++ where you generate a screen then are stuck with manual changes after because if you go back to the meta-model and regenerate you lose code. So in that respect I agree with what Matt is saying. However, the problem facing most IT managers is that they have a majority of average programmers who cannot handle more abstract design but can handle point and click interface building based on a data source. This competes somewhat with Catalyst's ideals to be lean, mean and not tied to a particular One True Way. The way I see it is that you need the core Catalyst, which is a pretty cool set of code, and a sample OTW approach to get people started but which they can go beyond. We're using Catalyst in a project I'm managing and I hope very much that one of the outcomes from that will be to make it easier for other people to use Catalyst. That is because I have tried (and failed) to pitch Catalyst to IT customers because it's too complicated as it is now for their staff. Best wishes, Peter Edwards http://www.dragonstaff.com - Business IT Consultancy ___ 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/
Re: [Catalyst] Why scaffolding? Validation and Learning
Simon Wilcox wrote: > I nearly threw Catalyst out of the window whilst fighting with one of the > earlier tools (I forget which, call it traumatic amnesia :) as I just > couldn't get it to do what I wanted it to do. Not understanding enough > about what was going on under the hood meant that it was virtually > impossible to figure out what was going on. > > In the end I went back to first principles and did things by hand. I think > of it as a bit like learning to drive, you need to understand the basic > principles before you can take shortcuts. This is the opposite of having > training wheels on your bike of course, when you start simple and get more > complicated. The problem with the latter approach is that you need to have > a progression from simple to complicated and the scaffolding helpers just > didn't give me that, it was all or nothing. I'm glad someone brought this up. I have always found it is important to know what is going on under the hood. Even with languages, like Perl, when you start to get an understanding of how things work internally, suddenly you are much more productive. The "magic" Ruby on Rails videos show some impressive stuff. I guarantee that the person in the videos is an expert. I also guarantee that despite my decades of programming experience, having not used RoR before, there is no way I can pick up RoR and make a blog in 5 minutes. 5 days, maybe. Second time around would be much shorter, of course. The next level would be to describe what you want in human language and have the software generate the app. Obviously we are not there yet. The software is still dumb. It takes the form of helpers. "Magic" helpers without sufficient intelligence inside are more of a hindrance than a help. There are two types of busy work: work that is pretty much common for any development task and work that is based on the style of a particular developer and thus not as much use to other developers. The crux in developing a scaffolding is to include helpers for the first type of work and the ability to "plug-in" the second type. Paul Wallingford ___ 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/
Re: [Catalyst] Why scaffolding? Validation and Learning
Zbigniew Lukasiak wrote: > This is the first advantage of scaffolding - easy evaluation. > I would agree with this. It's not the first thing that occurs to me when I think of scaffolding, but perhaps it should be. > 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. > Very true, as long as the generated code is well-documented and becomes a "custom tutorial" sort of thing. That would be good, whereas the more Rails-like mode of CRUD being based entirely on defaults that are hidden to the new user is bad IMHO. > Of course there are also disadvantages to code generation. I think that these disadvantages are certainly what framework devs and experienced users think of when they think of scaffolding. And the Rails mindset has made that even more likely. I *really* like your idea about separating the scaffolding from any additional code the new user might add. Perhaps the CRUD generator creates a base class for each controller that can be updated to sync with model changes, while an (initially empty) controller subclass holds their new code? For me the thing that absolutely sunk Rails was that too much happened automatically, behind the scenes. A split controller/subclass might allow the developer to see how things work (visible magic as opposed to invisible magic), but not mix their code up in that. - Brian ___ 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/
Re: [Catalyst] Why scaffolding? Validation and Learning
On Thu, 17 Aug 2006, Zbigniew Lukasiak wrote: [Lots of good stuff about scaffolding] Too Much Magic is my problem with the current crop of scaffolding "helpers". I nearly threw Catalyst out of the window whilst fighting with one of the earlier tools (I forget which, call it traumatic amnesia :) as I just couldn't get it to do what I wanted it to do. Not understanding enough about what was going on under the hood meant that it was virtually impossible to figure out what was going on. In the end I went back to first principles and did things by hand. I think of it as a bit like learning to drive, you need to understand the basic principles before you can take shortcuts. This is the opposite of having training wheels on your bike of course, when you start simple and get more complicated. The problem with the latter approach is that you need to have a progression from simple to complicated and the scaffolding helpers just didn't give me that, it was all or nothing. I have no idea if InstantCRUD is now better in this respect, I've been to afraid to try again :-) I may have another look at this in a while when we upgrade the site. Simon. ___ 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/
Re: [Catalyst] Why scaffolding? Validation and Learning
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/
[Catalyst] Why scaffolding? Validation and Learning
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/
