Re: [Catalyst] Shoot out -- Catalyst / RoR / Other MVC apps --
On Tuesday 08 May 2007 03:20:32 pm Matt S Trout wrote:
Does anybody know of a place where creating your own model is documented
in more detail? I'd like to read it.
Not yet. I suspect there'll be a chainsawblues series on it at some point
if nobody else gets a good explanation together first.
I've written a chapter about this for the book. That probably won't help you
for a few months though :)
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
pgpIwbQFaktXu.pgp
Description: PGP signature
___
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] Shoot out -- Catalyst / RoR / Other MVC apps --
A few pages on best-practices would be great. For someone learning new concepts there's lots of new terminology/methods, lots of people have their slant on the meaning of things and sometimes the penny never drops and then you give up and go back to old/bad practices because they're warm and comforting (haha). I'm currently doing a lot of reading about Patterns, learning new approaches like Catalyst, RoR, ORM and all with a view to redesigning an existing application at work. It's a lot to take on, I wnat to get it it 'right' but it's confusing and I find I spend a lot of time reading books/ reading mailing lists/ reading anything I can get my hands on .. it's a steep curve. Just a thought ;) -Ants Chris [EMAIL PROTECTED] wrote: Does anybody know of a place where creating your own model is documented in more detail? I'd like to read it. Not yet. I suspect there'll be a chainsawblues series on it at some point if nobody else gets a good explanation together first. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Please, yes! It would be very useful to see more examples of current best-practice. - Chris ___ 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/ - The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider.___ 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] Shoot out -- Catalyst / RoR / Other MVC apps --
Matija Grabnar ha scritto: On Tue, 8 May 2007, Perrin Harkins wrote: The way most people use Rails and Catalyst is somewhat different from the MVC concept. The traditional role of the controller is just to map user input to a method, and nothing more. All of the business logic is supposed to be in the model. But, thinking back to Catalyst docs, when they talk about constructing a model, they mostly just give you the line that will pull in an existing DBIC set of classes, not how to make your own model that just calls DBIC (or even, doesn't call DBIC at all). I agree. I've read mst and others talk about how the core of the app should be independent of Catalyst, and how Cat's Model:: classes should be used as a way to expose that core to Catalyst. Unless I missed some new stuff, I haven't seen any code example of this best practice in the docs, the trac site or elsewere. I think this organizazion of the codebase could be useful in many projects, so I think it's worth writing a tutorial and/or one or two (possibly) realistic examples. The reason I'm asking this is that the docs don't promote this style, and moving from the build the cat app and make it grow style to the build the *app* and expose it through cat is not obvious. Does anybody know of a place where creating your own model is documented in more detail? I'd like to read it. I'd like to read it too. ___ 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/ -- Marcello Romani Responsabile IT Ottotecnica s.r.l. http://www.ottotecnica.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] Shoot out -- Catalyst / RoR / Other MVC apps --
Anthony Gardner wrote: A few pages on best-practices would be great. For someone learning new concepts there's lots of new terminology/methods, lots of people have their slant on the meaning of things and sometimes the penny never drops and then you give up and go back to old/bad practices because they're warm and comforting (haha). I'm currently doing a lot of reading about Patterns, learning new approaches like Catalyst, RoR, ORM and all with a view to redesigning an existing application at work. It's a lot to take on, I wnat to get it it 'right' but it's confusing and I find I spend a lot of time reading books/ reading mailing lists/ reading anything I can get my hands on .. it's a steep curve. Just a thought ;) -Ants Absolutely - I'm in exactly the same position, and am following almost exactly the same process, except that I abandoned RoR early on and decided to stick with Perl for the re-write. Catalyst was an entirely new concept to me, having progressed from a long-list-of-if-elsif-else type scripting - CGI::Application - Catalyst/DBIC and found, and am still finding, it hard going. The Tutorial was a massive help, without which I'm pretty sure I could not have even got off the ground, and so is the Catalyst DBIC mailing lists, but would also find an article on next-step development and best practices extremely useful. Count this as a vote in favour. -- Richard Jones Leeds, UK ** This message may contain confidential and privileged information. If you are not the intended recipient please accept our apologies. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. NHSmail is used daily by over 100,000 staff in the NHS. Over a million messages are sent every day by the system. To find out why more and more NHS personnel are switching to this NHS Connecting for Health system please visit www.connectingforhealth.nhs.uk/nhsmail ** ___ 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] Shoot out -- Catalyst / RoR / Other MVC apps --
RA Jones wrote: Absolutely - I'm in exactly the same position, and am following almost exactly the same process, except that I abandoned RoR early on and decided to stick with Perl for the re-write. Catalyst was an entirely new concept to me, having progressed from a long-list-of-if-elsif-else type scripting - CGI::Application - Catalyst/DBIC and found, and am still finding, it hard going. The Tutorial was a massive help, without which I'm pretty sure I could not have even got off the ground, and so is the Catalyst DBIC mailing lists, but would also find an article on next-step development and best practices extremely useful. Count this as a vote in favour. What he said :) I've spent the last week or so trying to distill out the essence of how other people have done it (Handel and C::M::DBIC::Schema mostly), but the amount of unfamiliar modules and coding techniques is making my brain hurt. -- Jamie Neil | [EMAIL PROTECTED] | 0870 454 Versado I.T. Services Ltd. | http://versado.net/ | 0845 450 1254 ___ 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] Shoot out -- Catalyst / RoR / Other MVC apps --
Jamie Neil wrote: RA Jones wrote: Absolutely - I'm in exactly the same position, and am following almost exactly the same process, except that I abandoned RoR early on and decided to stick with Perl for the re-write. Catalyst was an entirely new concept to me, having progressed from a long-list-of-if-elsif-else type scripting - CGI::Application - Catalyst/DBIC and found, and am still finding, it hard going. The Tutorial was a massive help, without which I'm pretty sure I could not have even got off the ground, and so is the Catalyst DBIC mailing lists, but would also find an article on next-step development and best practices extremely useful. Count this as a vote in favour. What he said :) I've spent the last week or so trying to distill out the essence of how other people have done it (Handel and C::M::DBIC::Schema mostly), but the amount of unfamiliar modules and coding techniques is making my brain hurt. Handel? Well there's your problem... :-) I'd love to write about how I've done things in Mango...if I only could make myself have the time to do it. To be honest, the outside-core-as-model didn't really become really clear to me until I stuffed Handel::Cart into Mango as a Catalyst Model. The best approach for me has been what mst has said before. Make your core stuff usable outside of the work of Catalyst. Seems like a no brainer, but when you're just learning Cat and following examples, it's easy to forget. For a quick example of how it's done in Mango: Handel::Cart - seperate app that does cart magic Mango::Provider::Carts - responsible for cart CRUD API in Mango Mango::Catalyst::Model::Carts - wraps above in Model instance MyApp::Model::Carts (isa Mango::Catalyst::Model::Carts) For non-Handel things in Mango...it's just the last ones: Mango::Provider::Users - responsible for user CRUD API in Mango Mango::Catalyst::Model::Users - wraps above in Model instance MyApp::Model::Users (isa Mango::Catalyst::Model::Users) The main theme being...the models are just DB thingies...they're completely usable outside core classes (domains/business logic, etc)... -=Chris signature.asc Description: OpenPGP digital signature ___ 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] Shoot out -- Catalyst / RoR / Other MVC apps --
Christopher H. Laco scribbled on 5/9/07 7:56 AM: The best approach for me has been what mst has said before. Make your core stuff usable outside of the work of Catalyst. Seems like a no brainer, but when you're just learning Cat and following examples, it's easy to forget. yes, it took me a year of fulltime Catalyst to arrive at this same place. I there was probably decent documentation and mailing list advice out there that could have pointed me in that direction from the start, although my experience with Perl in general is that I (can) do things my own way for awhile until I figure out on my own what more experienced folks already know: * search CPAN thoroughly before rolling your own * subclass subclass subclass * a couple levels of indirection can increase re-usability immensely * etc. [snip] The main theme being...the models are just DB thingies...they're completely usable outside core classes (domains/business logic, etc)... The Catalyst::Model:RDBO model uses this approach. It's just a thin layer around a single RDBO class (which represents one table). Just a shim to get your extra-Catalyst classes available within the Catalyst Model feature. -- Peter Karman . http://peknet.com/ . [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] Shoot out -- Catalyst / RoR / Other MVC apps --
On Wed, 9 May 2007, Peter Karman wrote: * subclass subclass subclass My experience tells me that lots of subclassing is a bad smell. Delegation is often simpler and less fraught with possibility for name conflicts. Perl's inheritance mechanism is particularly egregious, of course. SUPER is broken, and without private methods or attributes of any sort, it's really easy to step on your parent's internals and break things. * a couple levels of indirection can increase re-usability immensely All problems in computer science can be solved by another level of indirection (Butler Lampson) ... except the problem of having too many levels of indirection. Which no doubt you've all heard before, but it's worth remembering. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/ ___ 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] Shoot out -- Catalyst / RoR / Other MVC apps --
On Wed, 9 May 2007, Peter Karman wrote: My experience tells me that lots of subclassing is a bad smell. Delegation is often simpler and less fraught with possibility for name conflicts. What do you mean by delegation? Delegation is has-a relationships, as opposed to is-a. Here's a practical Catalyst example of both subclassing and delegation in action together. In the big Catalyst project I'm working on now, I wanted to have some custom accessors in my response object. These are things which are specific to my app, like breadcrumbs. I have a very minimal Response subclass that simply adds some accessors: package VegGuide::Response; use base 'Catalyst::Response'; __PACKAGE__-mk_accessors( 'alternate_links', 'breadcrumbs', 'keywords' ); That's the subclassing piece. The delegation is that rather than implement the functionality of breadcrumbs in the response object, the breadcrumbs accessor simply returns a VegGuide::Breadcrumbs object. On a side note, Catalyst plugins as a rule seem to jam _way_ too many methods into the things they extend (the session plugin is truly egregious). Some day I'd like to write a version of the session plugin that adds one method to the core Catalyst object, session(), and all the rest of the methods would be available via the object returned from session(). -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/ ___ 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] Shoot out -- Catalyst / RoR / Other MVC apps --
On Wed, May 09, 2007 at 10:45:43AM +0100, Jamie Neil wrote: RA Jones wrote: Absolutely - I'm in exactly the same position, and am following almost exactly the same process, except that I abandoned RoR early on and decided to stick with Perl for the re-write. Catalyst was an entirely new concept to me, having progressed from a long-list-of-if-elsif-else type scripting - CGI::Application - Catalyst/DBIC and found, and am still finding, it hard going. The Tutorial was a massive help, without which I'm pretty sure I could not have even got off the ground, and so is the Catalyst DBIC mailing lists, but would also find an article on next-step development and best practices extremely useful. Count this as a vote in favour. What he said :) I've spent the last week or so trying to distill out the essence of how other people have done it (Handel and C::M::DBIC::Schema mostly), but the amount of unfamiliar modules and coding techniques is making my brain hurt. I had that problem when I first came to Catalyst, to be honest (much though people may forget I only joined the development team properly for the 5.50 branch) - I did a -lot- of reading up on MVC and other patterns - the portland pattern repository (the original c2.com wiki) did me a lot of good as did reading the Catalyst sources to get a feel for how they hung together, but it was still hard work. This is why I'm considering trying to write it up - I don't think it'll ever be an -easy- leap to take but at least I can try and make your brain hurt intensely for a brief period rather than moderately over a long time :) -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical DirectorWant a managed development or deployment platform? Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote http://chainsawblues.vox.com/ http://www.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] Shoot out -- Catalyst / RoR / Other MVC apps --
On Wed, May 09, 2007 at 10:02:19AM -0500, Dave Rolsky wrote:
On a side note, Catalyst plugins as a rule seem to jam _way_ too many
methods into the things they extend (the session plugin is truly
egregious). Some day I'd like to write a version of the session plugin
that adds one method to the core Catalyst object, session(), and all the
rest of the methods would be available via the object returned from
session().
What I'd really like to try sometime is having
sub session { shift-model('CurrentSession'); }
and then make the Model::CurrentSession class with a bit of ACCEPT_CONTEXT
magic handle it all itself.
Most things that are currently plugins should, really, be either Controller
base classes, models or helper objects that are handed to the template.
We'll get there eventually, I hope.
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical DirectorWant a managed development or deployment platform?
Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/ http://www.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] Shoot out -- Catalyst / RoR / Other MVC apps --
Dave Rolsky scribbled on 5/9/07 10:02 AM: [snip] That's the subclassing piece. The delegation is that rather than implement the functionality of breadcrumbs in the response object, the breadcrumbs accessor simply returns a VegGuide::Breadcrumbs object. ah. that makes sense. Now I have a name for something I already do. :) On a side note, Catalyst plugins as a rule seem to jam _way_ too many methods into the things they extend (the session plugin is truly egregious). Some day I'd like to write a version of the session plugin that adds one method to the core Catalyst object, session(), and all the rest of the methods would be available via the object returned from session(). Yes, the Catalyst::Plugin::Cache system could work much the same way. There seem to be a lot of syntatically sweet methods in some plugins that just wrap around the core method. -- Peter Karman . http://peknet.com/ . [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] Shoot out -- Catalyst / RoR / Other MVC apps --
In the case of the example above: See svn.mangoframework.com/CPAN/Mango/trunk/ Mango::Provider::Users is really a subclass of Mango::Provider::DBIC that uses a schema to do its bidding. The users provider exposes Mango::User objects...which are quite literally...stupid. They know nothing of their maker...only the column data they've been given. So, to start from the bottom, in the case of Mango, I have: 1. Mango::Schema/Mango::Schema::Users The DBIC you know and love. 2. Mango::Provider::DBIC-isa Mango::Provider Generic provider that knows how to ask DBIC schemas to CRUD in a Mango way 3. Mango::Provider::Users-isa Mango::Provider::DBIC Specialized provider that knows how to CRUD users... Is using the DBIC provider by default, but could use other providers instead..like LDAP/OpenID 4. Mango::Catalyst::Model::Users-isa Mango::Catalyst::Model::Provider Thin wrapper that knows how to turn Mango providers into Catalyst Models... 5. MyApp::Model::Users - isa Mango::Catalyst::Model::Users Thin wrapper to reuse generic users model in current Cat app It seems like a lot...but most of it is very very thin =46rom the apps perspective... I can use a totally different Users model to get user data (assuming it conforms to the same API)... I can use a different Mango Provider to get user data (LDAP/OpenID, etc).= =2E. I can use a different schema, as long as the provider exposes the same fields.. (Well, really, the Mango::User object API) =46rom the core perspective... I can use Mango::Provider::Users in any code...console apps.. Tk Apps...cron jobs...etc For some people, that's entirely too much magic...just use a Model and be done with it... for apps where the core bits needs to be reusable in non-web apps, or inside of other peoples apps...abastract... -=3DChris signature.asc Description: OpenPGP digital signature ___ 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] Shoot out -- Catalyst / RoR / Other MVC apps --
Matt S Trout wrote:
On Wed, May 09, 2007 at 10:02:19AM -0500, Dave Rolsky wrote:
On a side note, Catalyst plugins as a rule seem to jam _way_ too many
methods into the things they extend (the session plugin is truly
egregious). Some day I'd like to write a version of the session plugin
that adds one method to the core Catalyst object, session(), and all the
rest of the methods would be available via the object returned from
session().
What I'd really like to try sometime is having
sub session { shift-model('CurrentSession'); }
and then make the Model::CurrentSession class with a bit of ACCEPT_CONTEXT
magic handle it all itself.
Most things that are currently plugins should, really, be either Controller
base classes, models or helper objects that are handed to the template.
We'll get there eventually, I hope.
Moose Roles! :-)
I would love to see the Auth stuff become role based...or pluggable in
it's own respect...
After doing the Mango magic for $c-user-cart, $c-user-profile for
anonymous vs. authed users, etc...it's clear that being able to attach
functionality to existing plugins is better than rewriting plugins to do
your own bidding every time...
Of course, I could be off my rocker...
-=Chris
signature.asc
Description: OpenPGP digital signature
___
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] Shoot out -- Catalyst / RoR / Other MVC apps --
On Wed, May 09, 2007 at 04:21:19PM +0100, Matt S Trout wrote:
Most things that are currently plugins should, really, be either Controller
base classes, models or helper objects that are handed to the template.
I guilty of this. Plugins have been an emphasized part of Catalyst
and, well, Cat makes them really easy to use.
I had some auth code I setup as a Controller base class and had my
Login controller inherit from it -- then it wasn't log before I wanted to
use that elsewhere. Stuffing common code in plugins sure makes it handy.
Often it's hard to figure out what's best until it's all built.
Speaking of plugins, I tend to use the common leading underscore for
private methods in plugins. Not very private. Not really a Cat
question, but do many people use lexical vars to store their private
methods in plugins?
my $private_method = sub { ... }
later:
$self-$private_method( $foo );
--
Bill Moseley
[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] Shoot out -- Catalyst / RoR / Other MVC apps --
I seem to remember hearing sth a few months ago about a comp between various MVC apps comprising of various teams / tasks / time limits etc. Does anyone know what I'm talking about here?! If s.o does, what became of it and are there any links to be had to read up on what happened? You probably mean the plat_forms contest held in Nuernberg, Germany: http://www.plat-forms.org/2007 No results yet, but I'm looking forward to seeing them, too :) --Tobias ___ 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] Shoot out -- Catalyst / RoR / Other MVC apps --
Hmmm, no, I don't think that is what I was talking about (though it might be) I thought the competition was made up of teams that were part of communities rather than companies. Plus, I'm sure RoR had a representation in the comp I was thinking of. This comp is just PHP/Perl/Java. Tobias Kremer [EMAIL PROTECTED] wrote: I seem to remember hearing sth a few months ago about a comp between various MVC apps comprising of various teams / tasks / time limits etc. Does anyone know what I'm talking about here?! If s.o does, what became of it and are there any links to be had to read up on what happened? You probably mean the plat_forms contest held in Nuernberg, Germany: http://www.plat-forms.org/2007 No results yet, but I'm looking forward to seeing them, too :) --Tobias ___ 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/ - Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your freeaccount today.___ 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] Shoot out -- Catalyst / RoR / Other MVC apps --
Hmmm, no, I don't think that is what I was talking about (though it might be) I thought the competition was made up of teams that were part of communities rather than companies. Oh, okay, nevermind then. Sounds interesting, though. Tell us if you find something out about it. Plus, I'm sure RoR had a representation in the comp I was thinking of. This comp is just PHP/Perl/Java. Ruby and Python didn't make it because there were too few teams. The interesting thing is that Perl was first left out of the competition and got included later on due to the Perl community's protest :) --Tobias ___ 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] Shoot out -- Catalyst / RoR / Other MVC apps --
Yeah, have just read the site more carefully and I think it is the one. But, what a poor turn out! Rails couldn't couldn't even raise a smile ;) Shame there weren;t more teams from the communities involved as I would've thought they'd thrive in an environment like that. Maybe next year if I'm up to speed with it all, I might give it a go ;) (don;t hold me to it, though) Tobias Kremer [EMAIL PROTECTED] wrote: Hmmm, no, I don't think that is what I was talking about (though it might be) I thought the competition was made up of teams that were part of communities rather than companies. Oh, okay, nevermind then. Sounds interesting, though. Tell us if you find something out about it. Plus, I'm sure RoR had a representation in the comp I was thinking of. This comp is just PHP/Perl/Java. Ruby and Python didn't make it because there were too few teams. The interesting thing is that Perl was first left out of the competition and got included later on due to the Perl community's protest :) --Tobias ___ 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/ - Yahoo! Answers - Got a question? Someone out there knows the answer. Tryit now.___ 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] Shoot out -- Catalyst / RoR / Other MVC apps --
On Tue, May 08, 2007 at 09:28:35AM +0100, Anthony Gardner wrote: I seem to remember hearing sth a few months ago about a comp between various MVC apps comprising of various teams / tasks / time limits etc. Does anyone know what I'm talking about here?! If it was MVC, why would rails be included? -- Matt S TroutNeed help with your Catalyst or DBIx::Class project? Technical Director Want a managed development or deployment platform? Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote http://chainsawblues.vox.com/ http://www.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] Shoot out -- Catalyst / RoR / Other MVC apps --
On Tue, May 08, 2007 at 09:28:35AM +0100, Anthony Gardner wrote: I seem to remember hearing sth a few months ago about a comp between various MVC apps comprising of various teams / tasks / time limits etc. Does anyone know what I'm talking about here?! If it was MVC, why would rails be included? -- Matt S TroutNeed help with your Catalyst or DBIx::Class what distinction are you making here to exclude rails from MVC? ___ 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] Shoot out -- Catalyst / RoR / Other MVC apps --
On Tuesday 08 May 2007, [EMAIL PROTECTED] wrote: On Tue, May 08, 2007 at 09:28:35AM +0100, Anthony Gardner wrote: I seem to remember hearing sth a few months ago about a comp between various MVC apps comprising of various teams / tasks / time limits etc. Does anyone know what I'm talking about here?! If it was MVC, why would rails be included? -- Matt S TroutNeed help with your Catalyst or DBIx::Class what distinction are you making here to exclude rails from MVC? ___ 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/ Somehow, Matt looks like to have some love/hate relationship with rails :P. What I still not understand is why he says RoR isn't MVC O:). -- Luís Azevedo (Braceta) ___ 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] Shoot out -- Catalyst / RoR / Other MVC apps --
On Tue, May 08, 2007 at 03:24:15PM +0100, Luis Azevedo wrote: On Tuesday 08 May 2007, [EMAIL PROTECTED] wrote: On Tue, May 08, 2007 at 09:28:35AM +0100, Anthony Gardner wrote: I seem to remember hearing sth a few months ago about a comp between various MVC apps comprising of various teams / tasks / time limits etc. Does anyone know what I'm talking about here?! If it was MVC, why would rails be included? what distinction are you making here to exclude rails from MVC? Somehow, Matt looks like to have some love/hate relationship with rails :P. I agree with them on some things and find other design decisions laughable. What I still not understand is why he says RoR isn't MVC O:). Because their models are dumb data objects and they shove all the business logic into what they call the controller. From the article that originally defined MVC - Models -- The model of an application is the domain-specific software simulation or implementation of the application's central structure. Views -- In this metaphor, views deal with everything graphical: they request data from their model and display the data. Controllers -- Controllers contain the interface between their associated models and views and the input devices (e.g., keyboard, pointing device, time). i.e. the controller should handle receiving user input and processing it appropriately - the domain logic should reside in the model. This is bloody important for building good application architecture - a cron script or e-mail gateway should be able to invoke e.g. a create user function in the model without ever having to load the web-related code. If your create user logic is in the controller, you're stuck with either talking to the app over HTTP or simulating a request. The controller's there for event dispatch and flow handling. Domain logic should be encapsulated - if anything, you want to make your domain model a completely separate piece of code with an interface model (or Facade Model) that your application interacts with. All rails really does is separate out the logic and the presentation - which you could do just as easily with a PHP page or CGI that invokes a templating engine to render the HTML. It's better than having everything in one file, but it damn well isn't MVC. -- Matt S TroutNeed help with your Catalyst or DBIx::Class project? Technical Director Want a managed development or deployment platform? Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote http://chainsawblues.vox.com/ http://www.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] Shoot out -- Catalyst / RoR / Other MVC apps --
On 5/8/07, Luis Azevedo [EMAIL PROTECTED] wrote: What I still not understand is why he says RoR isn't MVC O:). The way most people use Rails and Catalyst is somewhat different from the MVC concept. The traditional role of the controller is just to map user input to a method, and nothing more. All of the business logic is supposed to be in the model. Most users of RoR and Catalyst put a bunch of code in what gets referred to as the controller and call auto-generated ORM classes the model. Most of the code they put in the controller is really the model too. If you just change your naming and refer to RoR/Catalyst controllers as models and your web server + the RoR/Catalyst code as the controller, it would fit the MVC concept better. It won't solve the issue of wanting to reuse your model code in a non-web environment though. For that, you'd need to keep that code in some kind of separate model classes, or fold it into your ORM classes. All that said, the typical approach works fine for most people. It just doesn't fit MVC very well. Maybe it needs its own name, like HDT (Handlers, Database objects, Templates). - 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/
Re: [Catalyst] Shoot out -- Catalyst / RoR / Other MVC apps --
On Tue, 8 May 2007, Matt S Trout wrote: The controller's there for event dispatch and flow handling. Domain logic should be encapsulated - if anything, you want to make your domain model a completely separate piece of code with an interface model (or Facade Model) that your application interacts with. Another way to state this is that the Controller is a bridge between the core of the app (the model) and a view _for a specific environment_. For web apps, that environment is usually CGI/HTTP requests. But a controller could also be something for bridging CLI commands to the model (with no view per se) or maybe a GUI app, where the controller would probably the event loop and dispatching to various widgets. One criterion for proper use of MVC would be to ask yourself can I replace the controller with a command-line args parser/dispatcher and still use my model to do everything my web app can do. If you can say yes, you've at least made a good separation between model and controller. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/ ___ 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] Shoot out -- Catalyst / RoR / Other MVC apps --
On 5/8/07, Dave Rolsky [EMAIL PROTECTED] wrote: There's a little more than just mapping input to a method. I think of it as a translation layer between how the web server presents data and how my model API wants it. And then there's reverse mapping, for example translating exceptions thrown by the model into error messages we can show to the user. Both good points. My post was over-generalized and glossed over some things. Your point about separating the model from the environment is the real heart of the issue. One consequence of doing MVC the right way, though, is that you tend to up with rather large and complex sets of model classes. I think it's fine for people to shortcut this and shove model stuff into their RoR/Catalyst controller classes, as long as they understand the trade-off they are making, i.e. it will be difficult to separate this code and reuse it elsewhere. - 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/
Re: [Catalyst] Shoot out -- Catalyst / RoR / Other MVC apps --
On Tue, 8 May 2007, Perrin Harkins wrote: The way most people use Rails and Catalyst is somewhat different from the MVC concept. The traditional role of the controller is just to map user input to a method, and nothing more. All of the business logic is supposed to be in the model. But, thinking back to Catalyst docs, when they talk about constructing a model, they mostly just give you the line that will pull in an existing DBIC set of classes, not how to make your own model that just calls DBIC (or even, doesn't call DBIC at all). Does anybody know of a place where creating your own model is documented in more detail? I'd like to read it. ___ 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] Shoot out -- Catalyst / RoR / Other MVC apps --
On Tue, May 08, 2007 at 09:09:55PM +0200, Matija Grabnar wrote: On Tue, 8 May 2007, Perrin Harkins wrote: The way most people use Rails and Catalyst is somewhat different from the MVC concept. The traditional role of the controller is just to map user input to a method, and nothing more. All of the business logic is supposed to be in the model. But, thinking back to Catalyst docs, when they talk about constructing a model, they mostly just give you the line that will pull in an existing DBIC set of classes, not how to make your own model that just calls DBIC (or even, doesn't call DBIC at all). Does anybody know of a place where creating your own model is documented in more detail? I'd like to read it. Not yet. I suspect there'll be a chainsawblues series on it at some point if nobody else gets a good explanation together first. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical DirectorWant a managed development or deployment platform? Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote http://chainsawblues.vox.com/ http://www.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] Shoot out -- Catalyst / RoR / Other MVC apps --
On Tue, May 08, 2007 at 09:20:32PM +0100, Matt S Trout wrote: On Tue, May 08, 2007 at 09:09:55PM +0200, Matija Grabnar wrote: Does anybody know of a place where creating your own model is documented in more detail? I'd like to read it. Not yet. I suspect there'll be a chainsawblues series on it at some point if nobody else gets a good explanation together first. For now the easiest thing seems to be to use the DBIC/CDBI as much as possible. Beyond that and you're basically dealing with Perl OOP which is well documented these days and Catalyst internals which are much better documented than they once were. -- /chris The problem with troubleshooting is that trouble shoots back! ___ 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] Shoot out -- Catalyst / RoR / Other MVC apps --
Does anybody know of a place where creating your own model is documented in more detail? I'd like to read it. Not yet. I suspect there'll be a chainsawblues series on it at some point if nobody else gets a good explanation together first. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Please, yes! It would be very useful to see more examples of current best-practice. - Chris ___ 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/
