On 22/03/2011 9:38 AM, John M. Dlugosz wrote:
On 3/22/2011 7:44 AM, Octavian Rasnita
octavian.rasnita-at-ssifbroker.ro |Catalyst/Allow to home| wrote:
Another advantage of using a model versus creating the object and
using a mailer directly is that maybe after a certain time will
appear a much better mailer than Mail::Builder::Simple, and you may
want to switch to the new mailer. In that case you will need to make
some changes in a single model, and not in every controller.
That is an argument for abstracting and encapsulating, not for using a
Model per se.
The module I'm using already wraps a module with abstracts different
kinds of mailers, so there comes a point where I have to say enough is
enough.
Is the limitation just in the Catalyst detection of components, and its
use of set search packages. I guess you could write a plugin to modify
the $c->locate_components handling to search in ::Component as well as
::Model, ::View, etc. Then you could incorporate any additional
component, without being bound to call it a model or a view or a
controller. Personally, I think that could be a good thing, as there is
a definite need for components which may not be best shoehorned into a
model. I have a write-only logging component which I have called a model
as it is backed by a database, but it probably isn't really a model, and
I'd happily update in this way.
All the best
Stuart
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
