On Mon, Feb 16, 2009 at 2:01 PM, Octavian Râsnita <orasn...@gmail.com>wrote:
> Good idea. > > I think that many beginners find hard to learn Catalyst if they are coming > from another framework, or even worse, from CGI.pm, because right after they > begin, they need to learn DBIx::Class, Template-Toolkit, YAML or > Config::General, and they might not understand very fast if a certain piece > of text is a Catalyst code, or a DBIC one or something else. > > So I think a good tutorial should start without using DBIC or a > configuration file, and without using a view and a model. > > It should be that kind of example that "You shouldn't do this, but it is > ment for understanding Catalyst easier". > > So the first MyApp.pm should use only the Root.pm controller, and print a > very short of html text using $c->response->body(). > > The next sample should upgrade that example and show how Catalyst gets the > parameters from a form, almost like CGI.pm does, and print the body in the > same way, using the same warning that this code is not one that should be > used. > > The next example should upgrade that sample app and tell why a view is > needed, and how Catalyst can be used to forward to a certain view, tell how > to configure a default view in MyApp.pm, and print the body using a view, > but without using TT. > > The next example should show the advantage of using templates, introduce > the TT view, the TT helper that creates the view automaticly, and print the > page using a single .tt file, or a very small number of templates that > create the page. > > There could be another sample that shows what kind of "another view" can be > used to print the same content in a different way by just forwarding to it. > > Then maybe there would be good to introduce the configuration file, show > how to use Config::General and why it is useful to use a config file. > > After the beginner started to understand how Catalyst works, how the > actions work... the basic ones like Local, Index, Default, Private, Auto, > introduce the model, and show a simple model that puts and gets the data in > a more simple way, not by using DBI or DBIC. > For example, it could open() a file and store the information to it. > > Then the model that should be teached should be the one that uses DBI, and > show the user that he can have a $dbh object in any action, without needing > to connect to the database by specifying each time the database name, > username, password and other options. > > And only after the user will understand how Catalyst works, what means a > model, teach them DBIx::Class which is pretty hard to understand if it is > taught together with Catalyst without knowing any of them. > > Maybe here would be good a suggestion to stop and read a DBIx::Class > tutorial, for understanding that module outside Catalyst, and understand > even better which are the features offered by Catalyst and which are the > ones offered by DBIC. > > Then... it could be much easier to understand how the > authentication/authorization that uses DBIC works and other Catalyst > features. > > It might sound too stupid, but for a beginner it should sound very stupid, > and he should find it very easy to understand, with very little things to > learn on each step, and finally he will see that he knows how to use > Catalyst with its most important features. > > I also think that the explanation should be simple to understand even for > those who don't know Perl at all. > > Octavian > > ----- Original Message ----- From: "Jay Kuri" <j...@ion0.com> > To: <catalyst@lists.scsys.co.uk> > Sent: Monday, February 16, 2009 10:32 PM > Subject: [Catalyst] RFC: New to Catalyst questions > > > > Hello, >> >> So all this 'too many choices' talk has got me thinking. I'd like to >> put together some more web-available information for those >> transitioning to catalyst from other methods. >> >> To that end I'm soliciting your thoughts on things that you found >> particularly hard to get a grip on when you started using catalyst. >> (or that you are currently having trouble with) >> >> My intent is to pick the ones that are needed most and write them up >> (or sponsor). >> >> My working list is as follows (in no particular order.) >> >> 1) 'Getting' DBIx::Class (starting from a straight SQL-users point of >> view) >> >> 2) Basic Cat toolkit - the basic pieces you will want to produce your >> average web app. >> >> 3) Walkthrough of creation of a simple app end to end. >> >> Any others? >> >> Jay >> >> >> >> _______________________________________________ >> List: Catalyst@lists.scsys.co.uk >> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst >> Searchable archive: >> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ >> Dev site: http://dev.catalyst.perl.org/ >> > > > _______________________________________________ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: > http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > I think we should also consider branching on whether someone is experienced with perl or absolutely new. Catalyst certainly isn't for the new perl programmer, so there are some basics at the very bare minimum that need to be covered in perl first. -- Devin Austin http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost!
_______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
