Re: [Catalyst] Why scaffolding? Validation and Learning
The subclassing of templates sounds really interesting, but actually I don't have many strong convitions on this front - I think we need some more experimentation. Or perhaps I have one idea about the templates. I found it really simpler to code some more complicated parts as perl functions, put them on the stash and then use them as kind of macros in the templates, than coding it in the templating language. --ZbyszekOn 8/18/06, Matt S Trout [EMAIL PROTECTED] wrote: Zbigniew Lukasiak wrote: Some more technical details. The main idea of how the scaffolding should work is that we generate only a skeleton of directories, nearly empty controllers and some config stuff.The generated controllersonly contain their package declaration and a 'use base Catalyst::Example::Controller::InstantCRUD' line. So there is not that much of generated code here.After the controllers are generated users are expected to copy the methods that they want to modify from the Catalyst::Example::Controller::InstantCRUD superclass - doing that they are taking responsibility for the copied code.This way the main Instant controller, which is just a standard library and can be updated with standard means, is also an integral part of the example.The copying perhaps is not such a trivial step - but in fact should be pretty natural for people working with Object Oriented code - it's just overwriting of SUPER class methods. I am also planning to make it more intuitive by the way of documentation. This is the theory - in practice the config stuff required to have a working application is a bit big, but we are working on it. A separate thing are the templates for the views, in the current CPAN version they are treated in a similar way that the controllers - the users are expected to just copy the generic templates from the InstantCRUD directory and modify them to their liking.There were people on this list complaining about this and in the svn version now we create the basic templates in the generated application.This means problems with the templates when upgrading the library, but perhaps we need to treat the templates separately from the code and expect them to be really quickly rewritten by the programmers.We have an approach that allows standard templates to effectively besubclassed; once it goes to public announce I'd love to have your opinion on them since templates are the hardest issue for scaffolding and it's clearyou've done a fair bit of thinking about it.None of what I'm saying denigrates InstantCRUD - it's a very well-implementedScaffold and I recommend it to people regularly. I just think it's possible to achieve the same things a better way.--Matt S Trout Offering custom development, consultancy and support Technical Directorcontracts for Catalyst, DBIx::Class and BAST. ContactShadowcat Systems Ltd.mst (at) shadowcatsystems.co.uk for more information+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +___List: Catalyst@lists.rawmode.orgListinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/Dev site: http://dev.catalyst.perl.org/ -- Zbigniew Lukasiakhttp://brudnopis.blogspot.com/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] ways to do stuff and why
I am glad to see that the 'business logic in the model' side seem now to prevail in the Catalyst world. It was not so in the past - as this thread documents: http://lists.rawmode.org/pipermail/catalyst/2005-August/thread.html#1148 There is also a wiki page on this subjecthttp://dev.catalyst.perl.org/wiki/NecessaryBackgroundKnowledge --ZbyszekOn 8/18/06, Brian Kirkbride [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Brian Kirkbride [EMAIL PROTECTED] @ 08/18/2006 01:57 PM: At this point, if I want code reuse I have two reasonable choices: A) Create business logic modules, ie. MyApp::Logic::CreateTrial, etc B) Write my own business logic methods in MyApp::Schema::Trial-create(...) Either is valid and from what I gather Java developers like the Logic route.I chose (B) because I already have the classes and the logic is *usually* just operating on that class's data model. [Insert snarky Java comment here] B couples my business logic too tightly with the ORM. ORMs fall out of fancy. The whole point of MVC is loose coupling. Method A does not have that tight coupling. This is a bit of good advice I've picked up along the way: Loose coupling of objects.Code to the abstract class (API) not the implementation. Sometimes it helps to forget about ORM's for a minute.The hash or array of data returned by DBI is still your Model.It you want objects, you have to roll your own, around the DBI data. Roll your own around the DBIC data, use object composition, rather than inheritance.The coupling is looser, and that makes your code less brittle.I'm leaning toward this as well, you might have convinced me with thecomposition argument.I had been thinking of it in terms of inheriting from the model.I've moved from a home-grown ORM to Class::DBI to DBIx::Class in this project'shistory.The business logic methods in the model classes had to change eachmigration.Not a big deal, because it usually changing -find to -retrieve or something that simple.But not having to ever change a controller, script or CRON job by way of a setof Logic:: proxy classes would be nice.Generally these bits don't have to knowmuch of anything about the model implementation so it hasn't been much to change.But when iterating over result sets it's hard to avoid the modelimplementation specifics.Maybe I'll spend the weekend whipping up some proxy classes to sit between mymodel and the rest.I that the business logic methods in the model would be moved into these classes as well.Thanks!- Brian___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] Catalyst FormBuilder plugin on CPAN
Nate Wiger wrote:
Matt S Trout wrote:
Nate Wiger wrote:
If you can send me a pointer to writing a controller base class, I'll
certainly check it out. I didn't consider this an option, to be honest.
I was trying to model it after XMLRPC, which is nice and easy to load
with its :XMLRPC attribute. But I'm open to other possibilities.
Poke at Catalyst::Base - each attr causes the _parse_Name_attr method to
be
invoked during which you can do as you will.
Catalyst::Plugin::XMLRPC is a complete disaster of a design cockup and
considered *strongly* disrecommended. Catalyst::Plugin::Server obsoletes it
so
far as I'm concerned.
Actually, I was talking about Server::XMLRPC - great module, again
implemented as a Plugin. It could be argued that it belongs as a
controller base class too, since it does alter the request cycle and add
an $c-xmlrpc (as well as even forward requests to different urls).
Server::XMLRPC is a plugin because it hooks into the dispatch cycle (and the
authors and I only finally made it a plugin after lots of going round the
houses and not finding an easier way to do it currently; going back and
figuring one out is on the todo list)
Form handling doesn't need to do so, really, so it can go in as a base class
just fine.
Just to throw an idea out, the plugin architecture could be formalized
somewhat. Add a register_plugin() method, for example, that doesn't
allow more than one module to load into $c-{whatever}. A Plugin module
writer would use this to register their plugin.
It could do some simple housekeeping and throw an exception like so:
Attempt to load Cat conflicts with already loaded plugin Dog
Just a thought.
Yeah, except that there's also a lot of plugins that wrap methods rather than
declaring them. We'd love to do this. How to do it Right is a different matter
:)
--
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] ways to do stuff and why
Brian Kirkbride wrote: At this point, if I want code reuse I have two reasonable choices: A) Create business logic modules, ie. MyApp::Logic::CreateTrial, etc B) Write my own business logic methods in MyApp::Schema::Trial-create(...) Either is valid and from what I gather Java developers like the Logic route. I chose (B) because I already have the classes and the logic is *usually* just operating on that class's data model. Actually, I tend to have a DBIC::Schema model called something like 'DataStore' and then write logic modules under Model::* that the controllers call - so mostly (a), with a bit of (b) I think the main bone of contention here is that Len is referring to his persistence layer as the model, whereas I consider it to just be a persistence layer - stuff like Model::DBIC::Schema is really only there for simple apps where what you're modeling *is* the database. If you're modeling a domain, then your Model::* stuff should be the model of the domain, and whether or not said model happens to use DBIC stuff as its persistence store should be merely an implementation detail that the Controller never sees. -- 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] ways to do stuff and why
On 8/19/06, Matt S Trout [EMAIL PROTECTED] wrote: I think the main bone of contention here is that Len is referring to hispersistence layer as the model, whereas I consider it to just be a persistencelayer - stuff like Model::DBIC::Schema is really only there for simple apps where what you're modeling *is* the database. If you're modeling a domain,then your Model::* stuff should be the model of the domain, and whether or notsaid model happens to use DBIC stuff as its persistence store should be merely an implementation detail that the Controller never sees.Right. My Model is just the data structure holding the raw data. Adding business domain logic is the bailiwick (love that word) of my Controllers. I also think that a contention point is whether you, I or anybody else align ourMVC strictly with Catalyst Ms, Vs, and Cs. Obviously, we've not reached a consensus, but I think everybody's method has merit, and the key is to work in your comfort zone, and change when you feel pain. Whether the Shopping Cart is in the Model, or in the Controller, is an execise in semantics. It stiil needs to get it's data from someplace eventually. Which is why I like to use go_get_data() methods in the business object. The implementation of go_get_em() is data store specific, but the shopping cart allocates its items abstractly. Same model as session/authn/authz. Its the same principle of DBI/DBD. I propose a poker tounament, at Catalyst Expo 2007 (held in Las Vegas Nevada, USA, or on the French Riviera). Winner gets to define what MVC really means, and what goes where.Len. ___ 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] ways to do stuff and why
A. Pagaltzis wrote: * Matt S Trout [EMAIL PROTECTED] [2006-08-19 16:55]: If you're modeling a domain, then your Model::* stuff should be the model of the domain, and whether or not said model happens to use DBIC stuff as its persistence store should be merely an implementation detail that the Controller never sees. +1 This is going to be baked into our new layer-atop-Catalyst that we're working on, along with something akin to the Jifty Action stuff for mutations of the model (although without the form handling attached directly, see next para). So is abstracting out the view-ish logic into a separate layer (think HTML::Widget on steroids but generalised and with the rendering separate - we'll be supplying a standard set of TT templates as the default way of rendering 'em). The controllers are looking pretty bare - all they really do is grab bits from the model and instantiate viewport objects with the model objects, so you end up with the display logic, skinning, model and navigation all separate. Seems to work pretty nicely. -- 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/
