[Catalyst-dev] Catalyst plugin

[Tomas Doran]

On 2 Oct 2008, at 07:53, Octavian Rasnita wrote:

> From: "Matt S Trout" <dbix-class at trout.me.uk>
>> As I said in another email, what I'd say is that you should - 
>> subclass-
>> C::V::Email or C::V::Email::Template, and if you can't do what you  
>> need via
>> subclassing, sort out patches to the existing stuff so you can  
>> subclass it.
>>
>> Then the stuff you want is in your own module, but all the stuff  
>> the already
>> existing modules already do isn't duplicated.
>>
>> Ain't OO awesome :)
>
> Oh yes it is if you know to use it well enough. :-)

Well, if you'd listened - people have already told you the  
appropriate design for what we think you're trying to do, and I'm  
sure that getting SVN space so that the project is public, and  
someone to help review and help you with design problems in your code  
is very possible. The author of Catalyst::View::Email has already  
stated that he'll help support your goals..

> Maybe those 2 modules could be sub-classed and use the external  
> module I've made, but I think that sub-classing will mean just a  
> bigger effort without any benefit.

I think you've got what Matt is talking about totally backwards here..

The idea is that you make Catalyst::View::Email able to do all the  
features you want, and enable it to process something which isn't the  
stash (in the same way you can call $c->View('TT')->process yourself  
manually - I'd recommend the same interface as it's familiar to people).

You then sub-class it, and change:
>
> Why? Because I want to change:
> - the interface used by the users ($c->stash->...)
> - the structure of the configuration hash (that might allow  
> defining more servers)

Problem solved...

> - the module that will create the message elements

Why were you doing this again?

> - The way it will handle the templates (They will be also handled  
> by the external program)

So this was a feature addition / abstraction to the current  
Catalyst::View::Email?

> And this will mean changing everything.

I totally disagree..

You're correct, however, when you say that it's more work to build  
flexible re-useable code which is actually useful to a wide user  
community. It _is_ more work, quite a _lot_ more work than just  
writing something to do what you need right now. Documenting it well  
enough for people to use it without having to resort to reading the  
code is even harder.

But the end solution is vastly superior than a 'one shot wonder', and  
as you're writing less, better thought out code (as you're sharing as  
much code as possible, and having to arrange code so that it _can_ be  
shared) - and guess what, the less lines of code you have, and the  
more carefully planned/designed for reuse your code is, the less bugs  
you have, and the more people can reuse it to solve _their_ problems  
(which won't be quite the same as yours)..

If you want to build your own little email solution which works  
exactly how you like, then please go ahead. Just please don't put it  
on CPAN as a catalyst component, as it won't have been built to be  
useful to anyone but you...

I'm sorry if this sounds harsh, and I'm not trying to criticse - but  
there is no point contributing  to CPAN unless you are actually  
building something someone else could use, and there is so much  
confusion about what problem you're actually trying to solve here (as  
you don't seem to have decided that yourself) that the current end  
result is unlikely to solve any problem in a reasonable fashion.

Cheers
t0m