Re: [Catalyst] [announce] Catalyst 5.70 developer release.
Matt S Trout [EMAIL PROTECTED] writes: [..] for example: first 5.6902, then 5.70_1 then 5.70. From debian point of view 5.70 is before 5.6902, 5.70_1 is invalid (so probably should be changed to 5.70.01 but then it's after 5.70 so probably should be changed into 5.69-5.70pre1 etc.). But this is minor problem, it's only make automatic tools blind but always can be changed manualy. 5.70_01 IS A DEV RELEASE. So you don't want to be packaging it anyway. The _ is required for CPAN to understand it's a dev release. If you want a different format, feel free to convince the CPAN admins to change that. I know and I don't want to change it. The next production release will be 5.7000 - what's the problem with that? But will be tar.gz named Catalyst-Runtime-5.70.tar.gz or Catalyst-Runtime-5.7000.tar.gz? It makes difference with automatic upgradind tools. 5.7000 - dists will be Dist-Name-version.tar.gz just like they've always been, just like every dist installer I've ever used (i.e. EUMM, MI, MB) builds them. Relax, don't try to package the dev releases, the production release which actually needs packaging will be fine. I package everything (because I like to have clean system) but I don't upload to debian everything : eloy -- [EMAIL PROTECTED] jak to dobrze, że są oceany - bez nich byłoby jeszcze smutniej ___ 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] (ping textmate bundle maints) filename in svn repos
http://anon:[EMAIL PROTECTED]/svn/Bundles/trunk/Bundles/Template% 20Toolkit.tmbundle/ http://64.233.183.104/search?q=cache:rb_XQo0AE9sJ:sg.validcode.at/ articles/2006/04/29/the-easiest-way-to-install-textmate-bundles +textmate+bundle+installerhl=enct=clnkcd=3client=safari is also cool (the original site seems down with a 500). as to which of the TT bundles are best, I have no idea. andreas On 28. jun. 2006, at 16.24, Matt S Trout wrote: Simon Elliott wrote: Arrgh... Fixed. Unfortunately I think I'm going to have to rename some of my snippets as a result. ah well, maybe you can merge in some useful bits from http://wardley.org/downloads/Textmate-TT.tar.gz while you're there (ABW discovered textmate, decided he liked it an wrote a TT mode :) -- 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/ ___ 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] Program the logic
I dont' agree with the statement that all the application logic should go into the Controller. In my opinion in the Controller you should have only the code that is directly web related - all the rest should go into the Model. This way you can call your business logic from a cron script without the overhead of all the web stuff. --ZbyszekOn 6/28/06, Nilson Santos Figueiredo Junior [EMAIL PROTECTED] wrote: On 6/28/06, Eduardo Oliveros [EMAIL PROTECTED] wrote: I'm planning to program the logic of the application (the Model in MVC) previously to start with web page and the presentation. Actually, the Controller is what is supposed to drive the logic of theapplication. The model is really just that: the model. It's usuallymapped to some kind of storage engine such as a RDBMS. Many strong advocates of MVC specifically try to leave business logic out of thedatabase. What I see is that what Catalyst calls Model is just the Objects that map with the tables in the DDBB. And the logic of the application are developed in the Actions (in fact linked to the web application).You'll see that it's a little more than that (at least when you'reusing DBIx::Class - Class::DBI can't even be compared feature-wise nowadays). I know is difficult in practice to separate both worlds (logic from the presentation) but that is the false promise of the MVC pattern :).Not really. It's something somewhat straight-forward when using something like Catalyst. All you've got to do is resist the temptationof polluting your controllers with things that really should be inyour views. But sometimes it's even worth it.-Nilson Santos F. Jr. ___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] FastCGI is Weak Sauce
A. Pagaltzis wrote: Hi all, this was written about Rails apps, but all the conceptual points are 100% applicable to Catalyst: The Web Is a Pipe http://duncandavidson.com/essay/2006/06/webaspipe I’m not as sure about the practical points. In particular, I have no idea what Mongrel really does, although I heard about it before and wondered if it’s something the CPAN needs and could steal. I’m also unsure about how the existence and deployment of mod_perl affects these issues. But I know he is dead on the money about pipes. So whatever the conclusions where Perl and Catalyst are concerned, this is worth thinking about. Talking a well-defined binary protocol down a pipe is also not hard. I don't really see what the fuss is about. -- 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] Program the logic
This response is probably OFFTOPIC at this point, but maybes it's a good type of discussion for our community to have, if we can all be civil about it. Personally I think there are several points of view with the best way to do MVC. MVC, like quite a few programming paradigms offers a simple idea but translating that into real life can be hard. So there are lots of points of view. I think a lot of applications tend to underplay the role of Model because programmers have an easier time understanding the Controller. I think most of the simple demo style apps for catalyst tend to have a lot in the Controller because it's easier to get someone started who is used to writing monolythic cgi type applications. Personally I put all the logic having to do with manipulating the database into my model class. So things like adding/removing users or very common searches I put there. Anything that more than a single controller might want I put in the Model. IMHO this best thing to do is choose a set of best practices that reflect the way you write code and also match the project and just try to stick with it. I think the best practice style for Catalyst is still something developing. Sometimes it makes sense to create a lot of stored procedures in the database while other times it doesn't. I've actually been involved in huge projects that were totally written in Oracle PL/SQL. Sounds messy and looks messy but it worked. MVC is just a thing we made up, it's not some reality we need to discover the one true path on. At least that's how I see it.-john- Original Message From: Zbigniew Lukasiak [EMAIL PROTECTED]To: The elegant MVC web framework catalyst@lists.rawmode.orgSent: Thursday, June 29, 2006 3:37:58 PMSubject: Re: [Catalyst] Program the logicI dont' agree with the statement that all the application logic should go into the Controller. In my opinion in the Controller you should have only the code that is directly web related - all the rest should go into the Model. This way you can call your business logic from a cron script without the overhead of all the web stuff. --ZbyszekOn 6/28/06, Nilson Santos Figueiredo Junior [EMAIL PROTECTED] wrote: On 6/28/06, Eduardo Oliveros [EMAIL PROTECTED] wrote: I'm planning to program the logic of the application (the Model in MVC) previously to start with web page and the presentation. Actually, the Controller is what is supposed to drive the logic of theapplication. The model is really just that: the model. It's usuallymapped to some kind of storage engine such as a RDBMS. Many strong advocates of MVC specifically try to leave business logic out of thedatabase. What I see is that what Catalyst calls Model is just the Objects that map with the tables in the DDBB. And the logic of the application are developed in the Actions (in fact linked to the web application).You'll see that it's "a little" more than that (at least when you'reusing DBIx::Class - Class::DBI can't even be compared feature-wise nowadays). I know is difficult in practice to separate both worlds (logic from the presentation) but that is the false promise of the MVC pattern :).Not really. It's something somewhat straight-forward when using something like Catalyst. All you've got to do is resist the temptationof polluting your controllers with things that really should be inyour views. But sometimes it's even worth it.-Nilson Santos F. Jr. ___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.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/___ 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] [announce] Catalyst 5.70 developer release.
Hello Matt! 5.70_01 IS A DEV RELEASE. So you don't want to be packaging it anyway. Non really (with Gentoo, at least). I package the DEV releases of Catalyst and DBIx::Class with the ~arch keyword, so that a user doesn't get the automatic upgrade to those versions unless he explicitly configures /etc/package.keywords for that. I think packages for DEV releases are useful, because who wants to test them can do that while keeping his system clean by still using the package manager. Moreover, creating a Gentoo ebuild requires 30 seconds or so. ;-) However, it really depends on how the package system works: with the ~arch thing provided by Gentoo package system this is OK, but I don't know much about how it works with dpkg, rpm, and other package managers. Version numbers are a bit of a problem (not great, though) when packaging development releases. I found out that - with Gentoo Portage - the best versioning system is the one used by DBIx::Class DEV releases (0.x999_nn, which I translate to 0.x999.nn for ebuilds). Michele. -- Michele Beltrame http://www.varlogarthas.net/ ICQ# 76660101 Informativa privacy: http://www.italpro.net/em.html ___ 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] Program the logic
On 6/28/06, Eduardo Oliveros [EMAIL PROTECTED] wrote: I know is difficult in practice to separate both worlds (logic from the presentation) but that is the false promise of the MVC pattern :). Not really, no, the MVC pattern is actually just a specialized Adapter pattern so you can program your Views and Models independently without having to conform the Application and its Presentation to a specific interface. In Web Development that basically means web designers can work without having to know any gory details of the application logic and technology, and vice-versa. This reduces the development effort enormously IMHO. What I see is that what Catalyst calls Model is just the Objects that map with the tables in the DDBB. And the logic of the application are developed in the Actions (in fact linked to the web application). Catalyst is very flexible, you can put your mapped DB classes wherever you want, you could even have a View that's mapped to a database that stores your templates or even your application data if you want. You could program your application logic directly inside Controller Actions if you wish. You'll have trouble maintaining your code later, but that's not Catalyst's fault. Anyway, the question is just what is the best practice to program the logic and test it before link the logic with the web application?. (using the classes generated by the Class::DBI or whatever plugin). I'd stick to the fundamental OO Pattern theory: program to interfaces not implementations. Personally, I have my Controller actions call operations from a Model class interface and my aplication logic stays in the Model, behind the interfaces I defined. That way, I can test the aplication logic independently with unit tests and later on, run integration tests by mocking context objects. ___ 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] Program the logic
I really don't see much ambiguity myself. I'm not really a theorist on this stuff, so what follows is my practical definitions based on working with it: Model(s) - Data source abstraction. You put things like access to RDBMSes, Files (collections of images?), and even remote data sources served via XMLRPC or screen scraping here. The point of this layer is to encapsulate and abstract the access methods for the data sources, and do simple transformations that are directly related (for instance, translating between DB timestamps and DateTime objects, or calculating a user's age based on the stored birthdate in his database entry). The best way to determine if a peice of code belongs in a Model is to ask yourself: If someone were to write a completely different application for a completely different purpose using a completely different architecture (perhaps not even web-based at all) which also needed access to this data source, would this peice of Model code probably be appropriate and/or useful for them? Views(s) - View-windows on your application. In theory, you might have several views: an HTML view, a graphing view (for outputting GD::Graph images), a PDF view, etc. The only knowledge that belongs here are the details involved in constructing the specific flavour of output. If you find yourself putting code in your View templates that isn't directly related to rendering this specific flavour of output, it probably needs to be moved to the Controller. Good code in views: iterating an arrayref to generate a ul list, walking a data structure to generate a table, or walking a data structure to generate a graph image. Controller(s) - This is the glue that binds Models and Views together. It accepts user input, possibly makes modifications to Model data, possibly retreives some Model data, and then displays a View at the user who gave the input. This is where the business logic goes. This is where anything that officially doesn't belong in Views and Models goes, basically. If you find yourself putting any HTML tags in your controllers, that code really belongs in your Views. Similarly, if you find yourself putting raw SQL or raw requests to remote network sources, etc in your controllers, those really belong in proper Models. That's the ideal situation in my mind. Obviously in the real world you sometimes deviate from this, for reasons like I don't have time to design the proper abstraction before this looming deadline, or doing it the right way is just provably too inefficient in this particular case. But its important to keep the ideal in mind and strive for it. -- Brandon ___ 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] tutorial_create.pl - error using SchemaLoader
On 6/29/06, Torsten Krah [EMAIL PROTECTED] wrote: Looking at this file, their is this example: tutorial_create.pl model AnotherDB DBIC::SchemaLoader dbi:Pg:dbname=foo root 4321 But if i try this ( of cause with working parameters testet with deprecated DBIC), i only get: Couldn't load helper Catalyst::Helper::Model::DBIC::SchemaLoader, Can't locate Catalyst/Helper/Model/DBIC/SchemaLoader.pm I only got a Schema.pm there - but it produces no helpful stubs, have i really to write the schema itself or is there a way like deprecated DBIC one to generate it? SchemaLoader package is installed, what is missing? Can you point me which paket i forgot? The Schema Loader has changed since that tutorial was written, and this no long a DBIC::SchemaLoader Helper. perldoc Catalyst::Helper::Model::DBIC::Schema will show you how to use the current Helper to create your Schema and Model for you, either dynamically (the way SchemaLoader Helper did), or statically. -- Brandon ___ 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] C::V::Mason and autohandler's
Hello everyone, I know that very few people use the Mason view, but I'm throwing this out anyway. I have a new Catalyst project. It has a simple form that posts a value to a Controller. The action in the controller just gets the parameter and warns it to the debug screen. Very basic. Works great, 1 Request shows in the debug for the post, another for the rendering of the template and warning the parameter. [EMAIL PROTECTED] authorwatch]$ perl script/authorwatch_server.pl [Thu Jun 29 10:49:22 2006] [catalyst] [debug] Debug messages enabled [Thu Jun 29 10:49:22 2006] [catalyst] [debug] Loaded plugins: .--. | Catalyst::Plugin::ConfigLoader 0.06 | '--' [Thu Jun 29 10:49:22 2006] [catalyst] [debug] Loaded dispatcher Catalyst::Dispatcher [Thu Jun 29 10:49:22 2006] [catalyst] [debug] Loaded engine Catalyst::Engine::HTTP [Thu Jun 29 10:49:22 2006] [catalyst] [debug] Found home /home/kold/projects/authorwatch [Thu Jun 29 10:49:23 2006] [catalyst] [debug] Loaded components: .---+--. | Class | Type | +---+--+ | authorwatch::C::Root | instance | | authorwatch::C::Search| instance | | authorwatch::V::Mason | instance | '---+--' [Thu Jun 29 10:49:23 2006] [catalyst] [debug] Loaded Private actions: .--++--. | Private | Class | Method | +--++--+ | /default | authorwatch::C::Root | default | | /end | authorwatch::C::Root | end | | /search/aws | authorwatch::C::Search | aws | | /search/end | authorwatch::C::Search | end | | /search/query_aws| authorwatch::C::Search | query_aws| '--++--' [Thu Jun 29 10:49:23 2006] [catalyst] [debug] Loaded Path actions: .--+---. | Path | Private | +--+---+ | /search/aws | /search/aws | '--+---' [Thu Jun 29 10:49:23 2006] [catalyst] [info] authorwatch powered by Catalyst 5.6902 You can connect to your server at http://kold:3000 [Thu Jun 29 10:49:42 2006] [catalyst] [debug] ** [Thu Jun 29 10:49:42 2006] [catalyst] [debug] * Request 1 (0.050/s) [26912] [Thu Jun 29 10:49:42 2006] [catalyst] [debug] ** [Thu Jun 29 10:49:42 2006] [catalyst] [debug] Body Parameters are: .---+--. | Key | Value| +---+--+ | svalue| test | '---+--' [Thu Jun 29 10:49:42 2006] [catalyst] [debug] POST request for search/aws from 127.0.0.1 [Thu Jun 29 10:49:42 2006] [catalyst] [debug] Path is search/aws [Thu Jun 29 10:49:42 2006] [catalyst] [debug] Rendering component /results.mhtml [Thu Jun 29 10:49:42 2006] [catalyst] [info] Request took 0.030530s (32.755/s) .--+---. | Action | Time | +--+---+ | /search/aws | 0.09s | | /search/end | 0.09s | | - authorwatch::V::Mason-process | 0.13s | '--+---' Then say I want to wrap a template around it using an autohandler. I add it, and run things again and it works, but looking in my debug screen shows multiple GET's after the POST. The only thing that has changed is adding the autohandler. Here's
Re: [Catalyst] C::V::Mason and autohandler's
On Thu, 29 Jun 2006 10:52:26 -0400, Kevin wrote: Then say I want to wrap a template around it using an autohandler. I add it, and run things again and it works, but looking in my debug screen shows multiple GET's after the POST. The only thing that has changed is adding the autohandler. Here's the debug: What does your autohandler look like? Do you have some img-, style- or script-elements with href-attributes in them, for instance? Do you get multiple requests in your log if you use something besides a browser to request the page (so you get just the page and not the things included in it; like wget, telnet, curl or similar)? Best regards, Adam, who uses Mason and autohandlers with Catalyst all the time. -- Adam Sjøgren [EMAIL PROTECTED] ___ 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] C::V::Mason and autohandler's
Hi Adam, On 6/29/06, Adam Sjøgren [EMAIL PROTECTED] wrote: Do you have some img-, style- or script-elements with href-attributes in them, for instance? Yes, I was using a template from here: http://particletree.com/features/quick-start-your-design-with-xhtml-templates/ I forgot to comment out the stuff with blank href's. Just for testing, I built a plain old template (like I always do) with just a body and it worked like it should (and always has). Guess in the past I had those href's filled out and saw them being handled by Static::Simple. Thanks for your help, although I'm embarrased that it was something so simple (wasted a few hours on it). Kevin -- Kevin Old [EMAIL PROTECTED] ___ 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] C::V::Mason and autohandler's
I'm using Mason with an autohandler and I'm not seeing the problem. Non-debug output from production site: 71.231.65.76 - - [29/Jun/2006:08:36:38 -0700] GET /BirdWeb-Admin/auth/login HTTP/1.1 200 1848 71.231.65.76 - - [29/Jun/2006:08:36:42 -0700] POST /BirdWeb-Admin/auth/do_login HTTP/1.1 302 - 71.231.65.76 - - [29/Jun/2006:08:36:42 -0700] GET /BirdWeb-Admin/birds/edit/440 HTTP/1.1 200 7447 I'm afraid I don't have any ideas as to why you're seeing multiple GETs. - Alan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Old Sent: Thursday, June 29, 2006 7:52 AM To: The elegant MVC web framework Subject: [Catalyst] C::V::Mason and autohandler's Hello everyone, I know that very few people use the Mason view, but I'm throwing this out anyway. I have a new Catalyst project. It has a simple form that posts a value to a Controller. The action in the controller just gets the parameter and warns it to the debug screen. Very basic. Works great, 1 Request shows in the debug for the post, another for the rendering of the template and warning the parameter. [EMAIL PROTECTED] authorwatch]$ perl script/authorwatch_server.pl [Thu Jun 29 10:49:22 2006] [catalyst] [debug] Debug messages enabled [Thu Jun 29 10:49:22 2006] [catalyst] [debug] Loaded plugins: .--- ---. | Catalyst::Plugin::ConfigLoader 0.06 | '--- ---' [Thu Jun 29 10:49:22 2006] [catalyst] [debug] Loaded dispatcher Catalyst::Dispatcher [Thu Jun 29 10:49:22 2006] [catalyst] [debug] Loaded engine Catalyst::Engine::HTTP [Thu Jun 29 10:49:22 2006] [catalyst] [debug] Found home /home/kold/projects/authorwatch [Thu Jun 29 10:49:23 2006] [catalyst] [debug] Loaded components: .---+--- ---. | Class | Type | +---+--- ---+ | authorwatch::C::Root | instance | | authorwatch::C::Search| instance | | authorwatch::V::Mason | instance | '---+--- ---' [Thu Jun 29 10:49:23 2006] [catalyst] [debug] Loaded Private actions: .--++--- ---. | Private | Class | Method | +--++--- ---+ | /default | authorwatch::C::Root | default | | /end | authorwatch::C::Root | end | | /search/aws | authorwatch::C::Search | aws | | /search/end | authorwatch::C::Search | end | | /search/query_aws| authorwatch::C::Search | query_aws | '--++--- ---' [Thu Jun 29 10:49:23 2006] [catalyst] [debug] Loaded Path actions: .--+ ---. | Path | Private | +--+ ---+ | /search/aws | /search/aws | '--+ ---' [Thu Jun 29 10:49:23 2006] [catalyst] [info] authorwatch powered by Catalyst 5.6902 You can connect to your server at http://kold:3000 [Thu Jun 29 10:49:42 2006] [catalyst] [debug] ** [Thu Jun 29 10:49:42 2006] [catalyst] [debug] * Request 1 (0.050/s) [26912] [Thu Jun 29 10:49:42 2006] [catalyst] [debug] ** [Thu Jun 29 10:49:42 2006] [catalyst] [debug] Body Parameters are: .---+--- ---. | Key | Value | +---+--- ---+ | svalue| test | '---+--- ---' [Thu Jun 29 10:49:42 2006] [catalyst] [debug] POST request for search/aws from 127.0.0.1 [Thu Jun 29 10:49:42 2006] [catalyst] [debug] Path is search/aws [Thu Jun 29 10:49:42 2006] [catalyst] [debug] Rendering component /results.mhtml [Thu Jun 29 10:49:42 2006] [catalyst] [info] Request took 0.030530s (32.755/s) .--+ ---. | Action | Time | +--+ ---+ | /search/aws
Re: [Catalyst] Program the logic
Anyway, the question is just what is the best practice to program the logic and test it before link the logic with the web application?. (using the classes generated by the Class::DBI or whatever plugin). I'd stick to the fundamental OO Pattern theory: program to interfaces not implementations. Personally, I have my Controller actions call operations from a Model class interface and my aplication logic stays in the Model, behind the interfaces I defined. That way, I can test the aplication logic independently with unit tests and later on, run integration tests by mocking context objects. That's exactly what I want to do. But what I see is that using the generated classes by the plugins from the application logic (what I call the model, but I see there is some controversy :)) could be a bit tricky. Because Catalyst provides an encapsulate environment where, for instance, you can start using all the classes without need to use use... (I mean: you don't need to declare the classes that you are going to use). I'm realising that you can use the classes from the application logic and that's all... no major problem. :) .. What I understand by MVC: The Model for me is in charge of managing the information, not just be an abstraction of the DDBB or the data in general. The logic of your application. The Controller controls the interaction with the user. It works as a middleman between the web and the model (the core of your application) and the view. And the View I think is clear. the HTML pages, program interface,... Regards, Edu PD: Anyway, Catalyst is a great framework to develop web applications, it's just that the interpretation of the M in MVC is not the same. ___ 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] FastCGI is Weak Sauce
So we should just run the myapp_server.pl script instead of FCGI. It speaks HTTP!! Joking... only joking... On 6/29/06, Matt S Trout [EMAIL PROTECTED] wrote: A. Pagaltzis wrote: Hi all, this was written about Rails apps, but all the conceptual points are 100% applicable to Catalyst: The Web Is a Pipe http://duncandavidson.com/essay/2006/06/webaspipe I'm not as sure about the practical points. In particular, I have no idea what Mongrel really does, although I heard about it before and wondered if it's something the CPAN needs and could steal. I'm also unsure about how the existence and deployment of mod_perl affects these issues. But I know he is dead on the money about pipes. So whatever the conclusions where Perl and Catalyst are concerned, this is worth thinking about. Talking a well-defined binary protocol down a pipe is also not hard. I don't really see what the fuss is about. -- 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/ ___ 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] Program the logic
On 6/29/06, John Napiorkowski [EMAIL PROTECTED] wrote: writing monolythic cgi type applications. Personally I put all the logic having to do with manipulating the database into my model class. So things like adding/removing users or very common searches I put there. Anything that more than a single controller might want I put in the Model. I think this really boils down to what you call application logic. Manipulating the database (i.e. what DBIx::Class does) isn't the kind of logic I was talking about. I meant actual business logic. This means things like validation (not that the other layers shouldn't validate data), access control, bridging your model and your view, triggering model actions, etc. IMO, the controller should be responsible for the higher level logic involved in an application while the logic contained in the model is a lower level (i.e. implementation details), usually data oriented, logic. -Nilson Santos F. Jr. ___ 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] Program the logic
On 6/29/06, Brandon Black [EMAIL PROTECTED] wrote: If you find yourself putting code in your View templates that isn't directly related to rendering this specific flavour of output, it probably needs to be moved to the Controller. Good code in views: iterating an arrayref to generate a ul list, walking a data structure to generate a table, or walking a data structure to generate a graph image. I've found myself building somewhat fat views lately. Mostly, I've done it when trying to build generic widget thingies that might appear in different pages. By fat I mean resultset-manipulating views, but usually the manipulations are restricted only to the view-related aspect of them, though. This means stuff like ordering the resultset by some column (using order_by). I'm usually in doubt if this is indeed a good practice or if it should be done another way, but it sure makes things easier. Overall, I find it somewhat difficult to satisfactorily come up with a nice and clean design for generic widgets. For example, if you've got a login box that displays either login fields when the user is not logged in or some user information whe the user's logged in, you'll usually need some of HTML and some of Perl code. But it's really up to the view to decide whether it wants to display that widget or not, so the general controller actions should be widget agnostic. My main dilemma is: should I have a LoginBox controller that handles it and then forward from the view back to the controller while rendering (maybe issuing a subrequest?) or is it alright to have this sort of widgets with lots of code, possibly calling the model directly themselves? Is there an estabilished best practice for doing this? This is currently my main philosophical issue while developing using Catalyst. If someone could enlighten me regarding this subject, I'd appreciate it. ;-) -Nilson Santos F. Jr. ___ 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] Program the logic
On 6/29/06, Nilson Santos Figueiredo Junior [EMAIL PROTECTED] wrote: On 6/29/06, Brandon Black [EMAIL PROTECTED] wrote: If you find yourself putting code in your View templates that isn't directly related to rendering this specific flavour of output, it probably needs to be moved to the Controller. Good code in views: iterating an arrayref to generate a ul list, walking a data structure to generate a table, or walking a data structure to generate a graph image. I've found myself building somewhat fat views lately. Mostly, I've done it when trying to build generic widget thingies that might appear in different pages. By fat I mean resultset-manipulating views, but usually the manipulations are restricted only to the view-related aspect of them, though. This means stuff like ordering the resultset by some column (using order_by). I'm usually in doubt if this is indeed a good practice or if it should be done another way, but it sure makes things easier. I think its fine to have the controller generate a resultset, and have the view directly apply ordering and/or paging to the resultset before generating HTML from it. But then again, I also find that approach a bit difficult and limiting. The approach I'm attempting lately (and I haven't gotten it all working right yet...) is to make Controller base-classes that implement generic concepts for things like paging and sorting tables of data (complete with handling form args like ?page=3count=50 or ?sortby=foo:desc silently for the controller), which makes it effortless for the controller to apply those sorts of things to the resultset before its sent to the view. These bits of controller functionality are of course View-agnostic. They (the base controllers implementing these features) basically boil down to: Check for some standardized GET form parameters, provide some data to the controller in the form of a paging object or some DBIC sorting hashref stuff, and also directly set stash variables for the views to see, regarding paging and sorting. There are template includes that go along with these meta controller actions (displaying the 1 2 3 paging clickies and whatnot, based on those stash vars...). Ultimately if I can ever get these concepts sufficiently genericized and bulletproof (or if anyone else does before me), it'd be a good idea to throw some out on CPAN as Catalyst::Controller::PageSort or something of the sort. -- Brandon ___ 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] PPM vs CPAN
Nilson Santos Figueiredo Junior wrote: On 6/28/06, Hugh Lampert [EMAIL PROTECTED] wrote: Err, yes... gcc... seems to be a bit of a problem. Hate to impose on the members of the list, but can anyone point me in the direction of a good win32 binary GCC package that doesn't require Cygwin or other environments? the CPAN module was kind enough to download and install NMAKE from Microsoft itself (that was nice), when I upgraded it. Although it's somewhat like killing a mosquito using a shotgun, I usually install the Dev-Cpp open-source IDE for Windows. It already comes with everything you need to self-compile your modules (GCC/MinGW, etc) and works out-of-the-box. It's not a big download (8mb I think) so it's something pretty reasonable. OK, don't mean to sound like a whiner here, and I haven't spent any time investigating the various GCC packages, but it's making me laugh that it's been suggested I download a C++ development package just so I can get my perl modules to install. There's a couple of nice modules for SQLite that include the SQLite executable maybe it's wishful thinking but it sure would be nice if there was a GCC module that included a binary GCC and any required libraries and headers. I know... I'm supposed to do that all myself, and I guess I will, but for now I just don't have time. I mean I only want to finish my small app. My boss is going to split his gut when I tell him first I need to download a C++ dev package so I can install the application framework that actually is written in perl. Looks like I'll be sticking to whatever Catalyst modules are available in PPM form for now. Not because I'm afraid of installing GCC, but because I can't imagine altering the roll-out environment to the point of installing UNIX emulation layers or C++ development packages just to put this app into production. ___ 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] Program the logic
Hi, Regarding the generic controller stuff you might look at the Catalyst::Example::Controller::InstantCRUD - you can use it as a base class for your controllers to get the basic CRUD + paging and sort stuff for free. It's still rather experimental though. -- ZbyszekOn 6/29/06, Brandon Black [EMAIL PROTECTED] wrote: On 6/29/06, Nilson Santos Figueiredo Junior [EMAIL PROTECTED] wrote: On 6/29/06, Brandon Black [EMAIL PROTECTED] wrote: If you find yourself putting code in your View templates that isn't directly related to rendering this specific flavour of output, it probably needs to be moved to the Controller.Good code in views: iterating an arrayref to generate a ul list, walking a data structure to generate a table, or walking a data structure to generate a graph image. I've found myself building somewhat fat views lately. Mostly, I've done it when trying to build generic widget thingies that might appear in different pages. By fat I mean resultset-manipulating views, but usually the manipulations are restricted only to the view-related aspect of them, though. This means stuff like ordering the resultset by some column (using order_by). I'm usually in doubt if this is indeed a good practice or if it should be done another way, but it sure makes things easier.I think its fine to have the controller generate a resultset, and havethe view directly apply ordering and/or paging to the resultset beforegenerating HTML from it.But then again, I also find that approach a bit difficult and limiting.The approach I'm attempting lately (and I haven't gotten it allworking right yet...) is to make Controller base-classes thatimplement generic concepts for things like paging and sorting tables of data (complete with handling form args like ?page=3count=50 or?sortby=foo:desc silently for the controller), which makes iteffortless for the controller to apply those sorts of things to theresultset before its sent to the view.These bits of controller functionality are of course View-agnostic.They (the base controllers implementing these features) basically boildown to: Check for some standardized GET form parameters, provide somedata to the controller in the form of a paging object or some DBIC sorting hashref stuff, and also directly set stash variables for theviews to see, regarding paging and sorting.There are templateincludes that go along with these meta controller actions (displayingthe 1 2 3 paging clickies and whatnot, based on those stash vars...).Ultimately if I can ever get these concepts sufficiently genericizedand bulletproof (or if anyone else does before me), it'd be a goodidea to throw some out on CPAN as Catalyst::Controller::PageSort or something of the sort.-- Brandon___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] Program the logic
On 6/29/06, Brandon Black [EMAIL PROTECTED] wrote: The approach I'm attempting lately (and I haven't gotten it all working right yet...) is to make Controller base-classes that implement generic concepts for things like paging and sorting tables of data (complete with handling form args like ?page=3count=50 or ?sortby=foo:desc silently for the controller), which makes it effortless for the controller to apply those sorts of things to the resultset before its sent to the view. These bits of controller functionality are of course View-agnostic. It's View-agnostic but then the View still isn't Controller-agnostic. Actually, after some thought this might be the real question that'd solve my issues: how to properly decouple Controller from Views? I'll give you a real world example that's actually already in use in an implemented (but evolving) system. I've got a somewhat generic table widget. This table contains items that can be either active or closed. Sometimes the closed items should be displayed along the active, other times they shouldn't, but there's always a button show/hide closed items. It's currently implemented entirely in the View, since the controller IMO shouldn't really need to know if the closed items should or shouldn't be displayed. That involves doing bad things such as using c.param() from the View but it really was the only practical way (i.e. DRY) I could think of. So, any suggestions are welcome. ;-) They (the base controllers implementing these features) basically boil down to: Check for some standardized GET form parameters, provide some data to the controller in the form of a paging object or some DBIC sorting hashref stuff, and also directly set stash variables for the views to see, regarding paging and sorting. There are template includes that go along with these meta controller actions (displaying the 1 2 3 paging clickies and whatnot, based on those stash vars...). But how do you specify which actions are supposed to get the wanted behaviour? How do you handle pages with multiple resultsets being displayed? I think the convention could quickly become ugly. If you threw in some AJAX stuff in the mix it might even get uglier still. But I'd be *very, very* happy if you showed me I was wrong. ;-) -Nilson Santos F. Jr. ___ 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] Program the logic
Nilson Santos Figueiredo Junior wrote: On 6/29/06, Brandon Black [EMAIL PROTECTED] wrote: The approach I'm attempting lately (and I haven't gotten it all working right yet...) is to make Controller base-classes that implement generic concepts for things like paging and sorting tables of data (complete with handling form args like ?page=3count=50 or ?sortby=foo:desc silently for the controller), which makes it effortless for the controller to apply those sorts of things to the resultset before its sent to the view. These bits of controller functionality are of course View-agnostic. It's View-agnostic but then the View still isn't Controller-agnostic. Actually, after some thought this might be the real question that'd solve my issues: how to properly decouple Controller from Views? I'll give you a real world example that's actually already in use in an implemented (but evolving) system. I've got a somewhat generic table widget. This table contains items that can be either active or closed. Sometimes the closed items should be displayed along the active, other times they shouldn't, but there's always a button show/hide closed items. It's currently implemented entirely in the View, since the controller IMO shouldn't really need to know if the closed items should or shouldn't be displayed. That involves doing bad things such as using c.param() from the View but it really was the only practical way (i.e. DRY) I could think of. So, any suggestions are welcome. ;-) No, it's the best separation of concerns, I think. The trick is to make the View smarter, which is a hard problem for webapps because of the degree of flexibility in styling required (ASP.Net has great shiny components, but any ASP.Net app looks like an ASP.Net app). Encapsulating the c.param bits in a TT plugin or three might be a good halfway measure. -- 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] PPM vs CPAN
On 6/29/06, Hugh Lampert [EMAIL PROTECTED] wrote: OK, don't mean to sound like a whiner here, and I haven't spent any time investigating the various GCC packages, but it's making me laugh that it's been suggested I download a C++ development package just so I can get my perl modules to install. Although I'm primarily a Windows user, I can't really deny that the only one to blame in this situation is Windows itself for not having a way to easily build stuff yourself. *Every* other OS has this sort of things. Even those Linux distros that are completely targetted at the end user (such as Ubuntu) and don't come with a bundled compiler can have it easily installed with a mere apt-get install gcc. I find it rather weird that the suggestion of downloading a C/C++ development package in order to compile C/C++ code makes you laugh. It's like saying that downloading Perl in order to run Perl application makes you laugh. Clearly you've got a wicked sense of humor. I know... I'm supposed to do that all myself, and I guess I will, but for now I just don't have time. After downloading the setup file, it takes a double-click plus three aditional clicks in order to get it installed. I really can't imagine someone *this* busy. I mean I only want to finish my small app. My boss is going to split his gut when I tell him first I need to download a C++ dev package so I can install the application framework that actually is written in perl. Catalyst's written in Perl. Most of its dependencies also are. But some of them have parts written in C/C++. How do you expect to compile C/C++ code without a C/C++ compiler? I can't really figure what's the hassle about a 8MB download, some mouse clicks and about 1 or 2 minutes of setup time. I can't really figure out why your boss should even know or care about what you're using to get your job done. Looks like I'll be sticking to whatever Catalyst modules are available in PPM form for now. Not because I'm afraid of installing GCC, but because I can't imagine altering the roll-out environment to the point of installing UNIX emulation layers or C++ development packages just to put this app into production. There's no need of installing UNIX emulation layers. If your worries are deployment related, you could easily use PAR, which would pack the already compiled DLLs in a single package. Production servers shouldn't need this installed. Also, unless it's something absolutely necessary, I'd suggest you against deploying it in a Windows server. It's somewhat of a hassle to get mod_perl or FastCGI working correctly under Windows, the best I've got so far is running Catalyst under Apache::Registry, since mod_perl crashes when using PerlModule directives and I can't manage to even compile FastCGI and it's related Perl module and the built-in server becomes really slow if you need to support IE clients directly connecting thanks to the necessary -k switch. -Nilson Santos F. Jr. ___ 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] PPM vs CPAN
Hugh Lampert wrote: I mean I only want to finish my small app. My boss is going to split his gut when I tell him first I need to download a C++ dev package so I can install the application framework that actually is written in perl. Looks like I'll be sticking to whatever Catalyst modules are available in PPM form for now. Not because I'm afraid of installing GCC, but because I can't imagine altering the roll-out environment to the point of installing UNIX emulation layers or C++ development packages just to put this app into production. Some modules have bits that need to be compiled so they can hook into the interpreter and/or OS at a lower level than perl code. You don't have to deploy the development tools. Would your boss be surprised that you wanted a copy of the Visual Studio compiler and toolchain in order to write .Net code? Why is that any different from needing a C compiler to compile loadable modules for a language whose runtime is written in C? -- 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] Program the logic
On 6/29/06, Matt S Trout [EMAIL PROTECTED] wrote: Nilson Santos Figueiredo Junior wrote: That involves doing bad things such as using c.param() from the View but it really was the only practical way (i.e. DRY) I could think of. So, any suggestions are welcome. ;-) No, it's the best separation of concerns, I think. The trick is to make the View smarter, which is a hard problem for webapps because of the degree of flexibility in styling required (ASP.Net has great shiny components, but any ASP.Net app looks like an ASP.Net app). Encapsulating the c.param bits in a TT plugin or three might be a good halfway measure. I couldn't really get the point of your ASP.Net analogy nor could I imagine how to encapsulate c.param() bits in some TT plugins (well, actually, I could think of aliasing c.param() to param() but this probably wasn't what you meant). So, could you please elaborate on this? -Nilson Santos F. Jr. ___ 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] Announce: DBIx::Class v0.06999_04 - RC for 0.07
This has just gone to CPAN, with the following momentous changes: - disable cdbi-t/02-Film.t warning tests under AS perl - fixups to MySQL tests (aka work round mysql being retarded) - compat tweaks for Storage debug logging This is a release candidate for 0.07 of DBIx::Class, so please test thoroughly! -=- Your friendly neighbourhood DBIC dev team -=- ___ 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] PPM vs CPAN
You may want to look into Vanilla / Strawberry perl as an alternative to ActivePerl. It includes the mingw (gcc) compiler and nmake, and the perl included is compiled from scratch with mingw, rather than ms compilers. http://win32.perl.org/wiki/index.php?title=Vanilla_Perl The files are here (get the .exe) : http://sourceforge.net/project/showfiles.php?group_id=158775package_id=178164release_id=393299 Vanilla Perl is officially experimental because until a few months ago some of the core modules were a bit flakey on windows, but I use it full time for development and running catalyst under fastcgi / apache and have no problems. The quite recent site http://win32.perl.org has a news item added today by Adam Kennedy, saying he's hoping to get a new release of Vanilla Perl and also an initial alpha of Strawberry Perl both out today. Strawberry perl in just Vanilla Perl, but with an up-to-date Bundle::CPAN, and IO / LWP modules - so it's considered a more realistic 'basic' version, rather than vanilla, which is really targeted at people wanting to do CPAN testing. http://win32.perl.org/wiki/index.php?title=Strawberry_Perl Anyway, as I said, I use Vanilla Perl, and have had very little trouble getting everything installed using CPAN.pm - no more trouble than occasionally crops up with other platforms - and the problems that exist have been getting fixed with-a-vengence these last few months. It doesn't come with PPM.pm, but I've written a script that will download PPM's from Kobes' repository and install them for me - I think the only modules I need to do that for are DBD::mysql and Image::Magick. PPM's are just archive files though, so it's easy enough to extract the files from. The next distribution will be Chocolate Perl, which will include a lot more useful modules, including everything that comes with ActivePerl (including PPM.pm) - hopefully we'll get an alpha of this out this year. On 29/06/06, Nilson Santos Figueiredo Junior [EMAIL PROTECTED] wrote: Also, unless it's something absolutely necessary, I'd suggest you against deploying it in a Windows server. It's somewhat of a hassle to get mod_perl or FastCGI working correctly under Windows, the best I've got so far is running Catalyst under Apache::Registry, since mod_perl crashes when using PerlModule directives and I can't manage to even compile FastCGI and it's related Perl module and the built-in server becomes really slow if you need to support IE clients directly connecting thanks to the necessary -k switch. I use a binary fastcgi apache module which I downloaded from the fastcgi website. I can't remember whether I had problems compiling FCGI.pm - maybe that's one of the few I had to get a PPM for. If you use PPM.pm, make sure you add Randy Kobes' cpan mirror repository. If anyone has problems with compiling/installing modules on windows, it'd be really appreciated if you could report the problem on rt.perl.org, and post a note on the Compatibility List of Perl Modules wiki page, so people know to chase it up. http://win32.perl.org/wiki/index.php?title=Compatibility_List_of_Perl_Modules Cheers, Carl ___ 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] Program the logic
Nilson Santos Figueiredo Junior wrote: On 6/29/06, Matt S Trout [EMAIL PROTECTED] wrote: Nilson Santos Figueiredo Junior wrote: That involves doing bad things such as using c.param() from the View but it really was the only practical way (i.e. DRY) I could think of. So, any suggestions are welcome. ;-) No, it's the best separation of concerns, I think. The trick is to make the View smarter, which is a hard problem for webapps because of the degree of flexibility in styling required (ASP.Net has great shiny components, but any ASP.Net app looks like an ASP.Net app). Encapsulating the c.param bits in a TT plugin or three might be a good halfway measure. I couldn't really get the point of your ASP.Net analogy nor could I imagine how to encapsulate c.param() bits in some TT plugins (well, actually, I could think of aliasing c.param() to param() but this probably wasn't what you meant). So, could you please elaborate on this? Template::Plugin::Class will load an arbitrary class. Why not have a plugin that grabs $c from the context and hides logic for the view code? Or a set of subrefs put into the stash, or whatever ... -- 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] Program the logic
Brandon Black a écrit : [...] Controller(s) - This is the glue that binds Models and Views together. It accepts user input, possibly makes modifications to Model data, possibly retreives some Model data, and then displays a View at the user who gave the input. This is where the business logic goes. This is where anything that officially doesn't belong in Views and Models goes, basically. That's the ideal situation in my mind. Obviously in the real world you sometimes deviate from this, for reasons like I don't have time to design the proper abstraction before this looming deadline, or doing it the right way is just provably too inefficient in this particular case. But its important to keep the ideal in mind and strive for it. Except that if business logic is in the controller then you are mixing it with web-related stuff (parameter retrieval, sanity checks, ... ). This does not matter much in most cases except big projects where business logic elements are reused in various situations around the application. In J2EE projects, the layer model is more like MSCV-I, for Model -- Service -- Controller -- View, the I standing for Integration layer (Spring for example, or Catalyst in Perl) What is missing in Catalyst is that Service layer. But it's not a big deal in most cases, IMHO. -- Matthieu ___ 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] Program the logic
On 6/29/06, Matthieu Codron [EMAIL PROTECTED] wrote: This does not matter much in most cases except big projects where business logic elements are reused in various situations around the application. Then you put that logic in external regular Perl modules and make your controllers just use them. Pretty simple. -Nilson Santos F. Jr. ___ 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] Program the logic
Matthieu Codron wrote: Brandon Black a écrit : In J2EE projects, the layer model is more like MSCV-I, for Model -- Service -- Controller -- View, the I standing for Integration layer (Spring for example, or Catalyst in Perl) What is missing in Catalyst is that Service layer. But it's not a big deal in most cases, IMHO. Nah, you just stick that layer in your model directory and the domain implementation itself somewhere else. It's not really missing, it's more that the tutorials, convenience components etc. all focus on small apps which don't need that extra layer of abstraction so much. By the time you really need the split to be explicit, you've probably got enough architecture for that not to be a problem (or if you haven't you've got bigger problems than any related to Catalyst :) -- 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] FastCGI is Weak Sauce
* Perrin Harkins [EMAIL PROTECTED] [2006-06-29 23:20]: If I'm reading it correctly, he's upset that the protocol between web servers and FastCGI isn't HTTP. He doesn't make a very good case for why, but that seems to be the gist. Yes. I take his argument as being that FastCGI has the application running in a separate process that can’t be communicated with in absence of a webserver because there aren’t any utilities that speak FastCGI directly, and if the connection between the webserver and the app process isn’t working, you’re basically S.O.L. because the app and webserver FCGI components don’t give you much information and diagnosing the problem without any tools is difficult at best. I think that much is just fact. He wants to run Rails directly in a web server instead. His solution is to write an HTTP server in Ruby to stick onto the front of Rails (that's what Mongrel is), which also doesn't make much sense, given how hard it is to write a truly bug-free HTTP server. (Probably a lot harder than it was to write Rails.) Sure, but it isn’t blue-sky musing. Mongrel already exists and is purportedly extremely solid code. So that’s not an open concern. Silly complaint or not, people running mod_perl already have this covered, since the normal mode of deployment is to run a static web server and proxy via HTTP over to a mod_perl server for all dynamic stuff, i.e. exactly what he's trying to build for Ruby. Yes, that’s what I was wondering about – and I say “wondering” because even though Apache plus mod_perl plus custom app works the same, deployment is not exactly easy. (It might be easy for you – I know who you are –, but I don’t have your experience and I know it’s not easy for me.) Meanwhile Catalyst doesn’t really take advantage of mod_perl anyway. Basically, what JDD writes makes me think of SQLite. Embedding the database engine right into the app makes it tremendously easier to deploy and manage. Embedding the HTTP engine right into the app should likewise make it a whole lot easier to deploy and manage. Sure, writing a solid embedded HTTP engine is no mean feat, but writing a solid embedded database engine isn’t either, and both have been done. It all seems awfully obvious to me; am I wrong? Regards, -- Aristotle Pagaltzis // http://plasmasturm.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] FastCGI is Weak Sauce
A. Pagaltzis wrote: * Perrin Harkins [EMAIL PROTECTED] [2006-06-29 23:20]: If I'm reading it correctly, he's upset that the protocol between web servers and FastCGI isn't HTTP. He doesn't make a very good case for why, but that seems to be the gist. Yes. I take his argument as being that FastCGI has the application running in a separate process that can’t be communicated with in absence of a webserver because there aren’t any utilities that speak FastCGI directly, and if the connection between the webserver and the app process isn’t working, you’re basically S.O.L. because the app and webserver FCGI components don’t give you much information and diagnosing the problem without any tools is difficult at best. I think that much is just fact. Sure, but my immediate thought is so write the tools. Shouldn't be that hard to pull apart something like FCGI.pm and build a diagnostics tool from it. Basically, what JDD writes makes me think of SQLite. Embedding the database engine right into the app makes it tremendously easier to deploy and manage. Embedding the HTTP engine right into the app should likewise make it a whole lot easier to deploy and manage. Sure, writing a solid embedded HTTP engine is no mean feat, but writing a solid embedded database engine isn’t either, and both have been done. It all seems awfully obvious to me; am I wrong? On my would be nice to have list is a POE webserver/static file server/fcgi handler that we could bundle to do moderately scalable pure-perl deployment. And I've happily used the standalone server in forking mode to handle lightweight deployment; just because it's usually referred to as the development server doesn't mean that's all it's good for. So, Catalyst has both options available, although if you know what you're doing a real webserver plus fastcgi will perform better than the standalone server ever could. Other than we need to write better tools for fastcgi debugging, but I'd rather re-invent the wheel instead I can't see what of this article isn't merely stating the obvious - and suggesting things Catalyst already happily supports ... -- 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] Program the logic
You can use some of the available plugins to help with this. There are plugins
to serve controller actions as xmlrpc or json for example. I've also been
doing some lightweight services with RSS and ATOM. I don't specifically see
something for SOAP, but I doubt it would be hard to make.
I think Catalyst currently collapses a couple of things into each part of the
MVC model. For example what we call a View could be a couple of different
things. Usually it is some sort of serialize for the Stash, right? But if you
chain together several views you might have the first view serializer the stash
into something (like RSS) and then pass that to an XSLT transformer to generate
HTML. That second transformer would probably act on what it finds inside of
$c-response-body instead of on the stash, although this is a bad example
since the current xslt view for catalyst looks for something in
$c-stash-{xml}.
I think if you are reallying looking avoid stuff like c.param in your view
you can use this method, just serialize everything your need to a common xml
type format (the stash, params, etc) and then use XSLT or the XSLT stuff in TT
to transform to html. I started out going this way but didn't honestly find an
advantage. Since all my view templates are only going to be used for catalyst
I didn't have any trouble with putting some catalyst stuff in the template. In
my situation the designers only really get to play with the CSS, not the html
so I don't need to worry about designers messing up the TT code. --john
- Original Message
From: Matt S Trout [EMAIL PROTECTED]
To: The elegant MVC web framework catalyst@lists.rawmode.org
Sent: Friday, June 30, 2006 7:29:13 AM
Subject: Re: [Catalyst] Program the logic
Matthieu Codron wrote:
Brandon Black a écrit :
In J2EE projects, the layer model is more like MSCV-I, for Model --
Service -- Controller -- View, the I standing for Integration layer
(Spring for example, or Catalyst in Perl)
What is missing in Catalyst is that Service layer. But it's not a big
deal in most cases, IMHO.
Nah, you just stick that layer in your model directory and the domain
implementation itself somewhere else. It's not really missing, it's more that
the tutorials, convenience components etc. all focus on small apps which don't
need that extra layer of abstraction so much. By the time you really need the
split to be explicit, you've probably got enough architecture for that not to
be a problem (or if you haven't you've got bigger problems than any related to
Catalyst :)
--
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/
___
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] FastCGI is Weak Sauce
A. Pagaltzis wrote: Yes. I take his argument as being that FastCGI has the application running in a separate process that can’t be communicated with in absence of a webserver because there aren’t any utilities that speak FastCGI directly, and if the connection between the webserver and the app process isn’t working, you’re basically S.O.L. Sure, but you could make this argument about databases, or SSL, or anything else that isn't plain text. There's no reason to abandon a tool that is working for you just because it uses a binary protocol. It's not like zombie processes and socket problems suddenly disappear when you start using a plain text protocol. Yes, that’s what I was wondering about – and I say “wondering” because even though Apache plus mod_perl plus custom app works the same, deployment is not exactly easy. We try pretty hard to make mod_perl easy to compile. There are good binaries for Windows. If you have a specific issue, you're welcome to bring it to the mod_perl list. Basically, what JDD writes makes me think of SQLite. SQLite is neat, but it's kind of slow and has poor concurrency, so it doesn't scale. It's actually a useful analogy here, since it illustrates how hard it is to write an efficient, scalable system. Embedding the HTTP engine right into the app should likewise make it a whole lot easier to deploy and manage. But if that's what you want, why write your own when you can take an incredibly solid HTTP server and embed Catalyst directly in it via mod_perl? - Perrin ___ 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/
