Mailing List Archive: Catalyst: Users

Polymorphism?

Index | Next | Previous | View Threaded

info at rapidsynergy

Jul 6, 2009, 3:33 PM

Post #1 of 7 (1109 views)
Permalink

Polymorphism?

I'm just wondering if any Catalyst programmers have used polymorphism in the
construction of their controller classes. Coming from a Java background I'd
like to be a little more OOP about how I implement my controllers. i.e. I'd
like to be able have a parent controller with common behavior and override
that behavior as necessary in my child classes but still work with the
generic parent class.

However, I've gotten in the habit of using actions for my application flow.
I know it's possible to use chained actions to carry behavior down and I've
used that in certain situations but it's not truly polymorphic for generic
coding. I'm not sure if I could be utilizing the NEXT library to more
advantage. Any thoughts, comments, best practices, tips you've discovered,
etc?

-Eric

jshirley at gmail

Jul 6, 2009, 3:58 PM

Post #2 of 7 (1041 views)
Permalink

Re: Polymorphism? [In reply to]

On Mon, Jul 6, 2009 at 3:33 PM, Eric Wright <info [at] rapidsynergy> wrote:

> I'm just wondering if any Catalyst programmers have used polymorphism in
> the construction of their controller classes. Coming from a Java background
> I'd like to be a little more OOP about how I implement my controllers. i.e.
> I'd like to be able have a parent controller with common behavior and
> override that behavior as necessary in my child classes but still work with
> the generic parent class.
>
> However, I've gotten in the habit of using actions for my application flow.
> I know it's possible to use chained actions to carry behavior down and I've
> used that in certain situations but it's not truly polymorphic for generic
> coding. I'm not sure if I could be utilizing the NEXT library to more
> advantage. Any thoughts, comments, best practices, tips you've discovered,
> etc?
>
> -Eric
>
>
>
Moose method modifiers work just fine on Catalyst code, which I find to
really help with using inheritance upstream. You'll probably want to

A typical method that I use is to combine Catalyst::Controller::DBIC::API
with a Moose control that has before/after methods.

Works like a charm. You may also want to play with using Roles, rather than
an inheritance mess... I find it a little bit easier to have deterministic
code paths to follow after I forgot the code in question.

Please give this a read: http://bobtfish.livejournal.com/264605.html

Our wonderful t0m (Thomas Doran) wrote that up, and I think it should be
required reading for anybody pondering questions like this.

-J

autarch at urth

Jul 6, 2009, 7:36 PM

Post #3 of 7 (1043 views)
Permalink

Re: Polymorphism? [In reply to]

On Mon, 6 Jul 2009, J. Shirley wrote:

> Moose method modifiers work just fine on Catalyst code, which I find to
> really help with using inheritance upstream. You'll probably want to

As do Moose roles. I've found using roles in controllers incredibly
helpful, since I often have similar/same "process this data and invoke a
->search method", where the only thing that varies is what is being
searched and/or the way the results are being displayed.

-dave

/*============================================================
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
============================================================*/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

bobtfish at bobtfish

Jul 7, 2009, 2:48 AM

Post #4 of 7 (1029 views)
Permalink

Re: Polymorphism? [In reply to]

Dave Rolsky wrote:
> As do Moose roles. I've found using roles in controllers incredibly
> helpful, since I often have similar/same "process this data and invoke a
> ->search method", where the only thing that varies is what is being
> searched and/or the way the results are being displayed.

Unfortunately, combining multiple roles with method attributes onto the
same class totally fails right now.

So:

with $_ for qw/ControllerRole1 ControllerRole2/; # Works

with qw/ControllerRole1 ControllerRole2/; # Attributes fail to show up.

This means that conflict resolution (one of the nicest features of
roles) fails to work :/

I have fixes for this in the pipeline; as always, volunteers welcome to
take them off my hands and finish them off if you want this before I get
time... ;)

Cheers
t0m

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

info at rapidsynergy

Jul 7, 2009, 6:11 AM

Post #5 of 7 (1025 views)
Permalink

Re: Polymorphism? [In reply to]

Thanks all for the thoughts and the link. I'll be sure to take some time and
digest that.

Re: method modifiers, that sounds like a really interesting solution. Roles
seem very similar to me to Java interfaces. I really need to get more on
board with understanding how Moose can best be utilized. I'm still very
green. Plus the proliferation of object frameworks in Perl can leave you
with analysis paralysis but things seem to be moving more that way in the
Perl community especially with Perl 6 (somewhere?) on the horizon.

I've got the new Apress Catalyst book on pre-order. Any other recommended
reading resources?

Cheers,
Eric

On Tue, Jul 7, 2009 at 5:48 AM, Tomas Doran <bobtfish [at] bobtfish> wrote:

> Dave Rolsky wrote:
>
>> As do Moose roles. I've found using roles in controllers incredibly
>> helpful, since I often have similar/same "process this data and invoke a
>> ->search method", where the only thing that varies is what is being searched
>> and/or the way the results are being displayed.
>>
>
> Unfortunately, combining multiple roles with method attributes onto the
> same class totally fails right now.
>
> So:
>
> with $_ for qw/ControllerRole1 ControllerRole2/; # Works
>
> with qw/ControllerRole1 ControllerRole2/; # Attributes fail to show up.
>
> This means that conflict resolution (one of the nicest features of roles)
> fails to work :/
>
> I have fixes for this in the pipeline; as always, volunteers welcome to
> take them off my hands and finish them off if you want this before I get
> time... ;)
>
> Cheers
> t0m
>
>
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>

jshirley at gmail

Jul 7, 2009, 6:41 AM

Post #6 of 7 (1025 views)
Permalink

Re: Polymorphism? [In reply to]

On Tue, Jul 7, 2009 at 6:11 AM, Eric Wright <info [at] rapidsynergy> wrote:

> Thanks all for the thoughts and the link. I'll be sure to take some time
> and digest that.
>
> Re: method modifiers, that sounds like a really interesting solution. Roles
> seem very similar to me to Java interfaces. I really need to get more on
> board with understanding how Moose can best be utilized. I'm still very
> green. Plus the proliferation of object frameworks in Perl can leave you
> with analysis paralysis but things seem to be moving more that way in the
> Perl community especially with Perl 6 (somewhere?) on the horizon.
>
> I've got the new Apress Catalyst book on pre-order. Any other recommended
> reading resources?
>
> Cheers,
> Eric
>

I'm going to be very opinionated for a moment, so the TIMTOWDI crowd can
skip this message.

Don't bother with other object frameworks. They really lack what makes
Moose special. Moose is built on top of Class::MOP. That's the meta-object
protocol which enables you to have a meta-layer and change the entire API
that Moose itself builds on.

This lets you do a tremendous amount of things with usually very little
code. The learning curve is also not quite as steep as you would expect.

Here's an anecdote to prove my case ;)

The other day I wanted to update the behavior of an attribute. Someone
pointed out "attribute trait". I looked it up in the cookbook, and I was
able to get exactly what I wanted by changing the definition of what that
attribute was. By changing the definition of things, you can change what
the instances of those things are very easily. Unfortunately my case was
thwarted by some other things, so it didn't work exactly as intended... but
it will :)

Unless you have experience with Lisp or the like, you're not going to
initially appreciate what Moose is. You'll think of it as a heavy-weight
object API, but trust a random guy on the internet when he says it is worth
it.

The manual is an easy read and worth following, and here is a good
presentation on Moose as well (lacks a little oompf without hearing Dieter's
voice): http://weftsoar.net/~hdp/moose/

Regarding books, I'd say venture out to your local Perl Monger meetings and
talk to them and borrow some of their books. That way you can sample it,
and find out the books that speak to you and then you can purchase those.

Thanks,
-J

info at rapidsynergy

Jul 14, 2009, 9:52 AM

Post #7 of 7 (964 views)
Permalink

Re: Polymorphism? [In reply to]

Thanks again for the info. I was trying to see if there was a Perl Mongers
group in our area. Seems like there used to be one in Hartford CT but now is
defunct? Web site not operational.

In the meantime, I just received the new Catalyst book and started poring
over it. I was happy to see its inclusion of coverage on Moose. It's an easy
sell to me.

Anyhow, good stuff on these links. Got me some book lernin' to do I think...

On Tue, Jul 7, 2009 at 9:41 AM, J. Shirley <jshirley [at] gmail> wrote:

> On Tue, Jul 7, 2009 at 6:11 AM, Eric Wright <info [at] rapidsynergy> wrote:
>
>> Thanks all for the thoughts and the link. I'll be sure to take some time
>> and digest that.
>>
>> Re: method modifiers, that sounds like a really interesting solution.
>> Roles seem very similar to me to Java interfaces. I really need to get more
>> on board with understanding how Moose can best be utilized. I'm still very
>> green. Plus the proliferation of object frameworks in Perl can leave you
>> with analysis paralysis but things seem to be moving more that way in the
>> Perl community especially with Perl 6 (somewhere?) on the horizon.
>>
>> I've got the new Apress Catalyst book on pre-order. Any other recommended
>> reading resources?
>>
>> Cheers,
>> Eric
>>
>
> I'm going to be very opinionated for a moment, so the TIMTOWDI crowd can
> skip this message.
>
> Don't bother with other object frameworks. They really lack what makes
> Moose special. Moose is built on top of Class::MOP. That's the meta-object
> protocol which enables you to have a meta-layer and change the entire API
> that Moose itself builds on.
>
> This lets you do a tremendous amount of things with usually very little
> code. The learning curve is also not quite as steep as you would expect.
>
> Here's an anecdote to prove my case ;)
>
> The other day I wanted to update the behavior of an attribute. Someone
> pointed out "attribute trait". I looked it up in the cookbook, and I was
> able to get exactly what I wanted by changing the definition of what that
> attribute was. By changing the definition of things, you can change what
> the instances of those things are very easily. Unfortunately my case was
> thwarted by some other things, so it didn't work exactly as intended... but
> it will :)
>
> Unless you have experience with Lisp or the like, you're not going to
> initially appreciate what Moose is. You'll think of it as a heavy-weight
> object API, but trust a random guy on the internet when he says it is worth
> it.
>
> The manual is an easy read and worth following, and here is a good
> presentation on Moose as well (lacks a little oompf without hearing Dieter's
> voice): http://weftsoar.net/~hdp/moose/<http://weftsoar.net/%7Ehdp/moose/>
>
> Regarding books, I'd say venture out to your local Perl Monger meetings and
> talk to them and borrow some of their books. That way you can sample it,
> and find out the books that speak to you and then you can purchase those.
>
> Thanks,
> -J
>
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>
>

--
-----------------------------------------------------------
Eric Wright
Rapid Synergy LLC
Web Development, Software & Consulting
V: 203.758.9270 F: 203.725.0853
http://www.rapidsynergy.com
-----------------------------------------------------------

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads