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 controllersonly 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
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
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/
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
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
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/
