[Catalyst] plugins; was Re: debug mode

[Matt S Trout]

On Thu, Jun 07, 2007 at 03:12:10PM -0700, mla wrote:
> Matt S Trout wrote:
> >On Thu, Jun 07, 2007 at 01:04:02PM -0700, mla wrote:
> >>Other than the fact you don't like the style, why is it bad?
> >>You don't like singletons?
> >
> >I'm not fond of any magic global if I can possibly avoid it - I find it
> >tends to encourage tight coupling of code and action at a distance and
> >makes testing and debugging messy.
> 
> But if you are going to use ACCEPT_CONTEXT then you are tightly
> coupling the model to the application.
>
> I agree that should be avoided... but they are equivalent if not
> more tightly coupled by adding the context to the actual model instance.

I -don't- tend to hang onto the entire $c in ACCEPT_CONTEXT, I might set
something like a current user (or in the case of the Paypal-IPN model I
wrote it hangs onto $c->req to pass as a CGI-object-equivalent when it
builds the IPN object).

The point is the singleton approach only makes the "I want the whole context"
case easier, which is very rarely the case that comes up with a correct
design.
 
> In terms of testing, seems like the singleton is a bit better since you
> have no ACCEPT_CONTEXT method to test.

Separating out the interrogation of the context and retrieval of data into
the ACCEPT_CONTEXT is how you avoid loose coupling - and it also then means
you know you have -one- method that requires a mocked $c to test rather
than potentially any in your entire codebase needing that.

> I don't see how debugging would be any harder.
> 
> >I prefer anything a method call needs to have been either (a) passed to the
> >object when it was constructed or (b) passed to the method as it's called.
> >
> >It can be a bit more work up-front but it makes you think about your
> >architecture, which I find pays off down the road.
> 
> A method call could also need to have access to other modules/packages
> it will delegate to. The singleton seems equivalent.

I don't do that either. I generally create associated objects via factory
methods and have an attribute for the related class with a default.

An example of this would be the _action_class member of Catalyst::Controller,
which is what defaults you to Catalyst::Action as your action class - related
classes should -always- be overridable.

-- 
      Matt S Trout       Need 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/