[Catalyst] best practices - model or controller ?

2008-10-04 Thread Yves Räber 
Hello, 

I want to implement something really simple : log some events into a
database. And I already can think of three way to do it, but because
this will be used very frequently I'd like to know what's the best
solution. For me the best solution would be to have little overhead, and
a really short command (like $c-logdb()).

1/ In the DBIC Model

package MyApp::Model::AppDB

sub add() {
  my $self = shift;
  my $message = shift;

  my $log  = $self-resultset('Log');
  $log-create( { 
message = $message 
  });
}

And then call $c-model('AppDB')-add('Hello World');

This seems ok, but $c-model('AppDB')-add('Hello World') ... too much
characters.

2/ In the controller

(in Root.pm)
sub log : Private {
  my ($self, $c, $message) = @_;
  $c-model('AppDB::Log')-create({
message = $message;
  });
}

And then call $c-forward('/log', [ 'Hello World' ]);

This doesn't seem really elegant to me.

3/ As a plugin

This seems really overkill, but I like the idea of having a really short
command like $c-logdb(...);

So could someone tell be what is best practice is ? 

Thanks.

Yves.


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

Re: [Catalyst] best practices - model or controller ?

2008-10-04 Thread Tobias Kremer 

On 04.10.2008, at 08:16, Yves Räber wrote:

I want to implement something really simple : log some events into a
database. And I already can think of three way to do it, but because
this will be used very frequently I'd like to know what's the best
solution. For me the best solution would be to have little overhead,  
and

a really short command (like $c-logdb()).


When deciding where to put things (model vs. controller) I always  
imagine what would happen if I took the Catalyst part away. In most  
cases the model should be able to fulfill everything without Catalyst  
being involved (for instance, if you'd like to use your model from a  
cronjob script). Thus, in this case, I'd definitely put the logging  
into the model to have it log everything even when Catalyst is not  
involved. I assume that every logging action goes together with a  
create/update/delete of model objects and is rarely triggered alone.  
If that's the case, have you thought about overriding the create,  
update, delete methods DBIC provides to add the logging there? That  
way you'd have to do it only once and every (write) action on your  
model is automatically logged.


--Tobias


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

Re: [Catalyst] best practices - model or controller ?

2008-10-04 Thread Peter Karman 
Yves Räber wrote on 10/4/08 1:16 AM:
 Hello, 
 
 I want to implement something really simple : log some events into a
 database. And I already can think of three way to do it, but because
 this will be used very frequently I'd like to know what's the best
 solution. For me the best solution would be to have little overhead, and
 a really short command (like $c-logdb()).
 
 1/ In the DBIC Model
 
 package MyApp::Model::AppDB
 
 sub add() {
   my $self = shift;
   my $message = shift;
 
   my $log  = $self-resultset('Log');
   $log-create( { 
 message = $message 
   });
 }
 
 And then call $c-model('AppDB')-add('Hello World');
 
 This seems ok, but $c-model('AppDB')-add('Hello World') ... too much
 characters.
 
 2/ In the controller
 
 (in Root.pm)
 sub log : Private {
   my ($self, $c, $message) = @_;
   $c-model('AppDB::Log')-create({
 message = $message;
   });
 }
 
 And then call $c-forward('/log', [ 'Hello World' ]);
 
 This doesn't seem really elegant to me.
 
 3/ As a plugin
 
 This seems really overkill, but I like the idea of having a really short
 command like $c-logdb(...);
 
 So could someone tell be what is best practice is ? 
 

You don't need a real plugin unless you need to override the dispatch process.
But I often put convenience methods in my MyApp.pm base class. So implement your
idea #1 and then add:

package MyApp;

sub logdb {
my $c = shift;
my $msg = shift or croak msg required;
$c-model('AppDB')-add($msg);
}



-- 
Peter Karman  .  http://peknet.com/  .  [EMAIL PROTECTED]

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

Re: [Catalyst] best practices - model or controller ?

2008-10-04 Thread Eden Cardim 
On Sat, Oct 4, 2008 at 9:31 AM, Peter Karman [EMAIL PROTECTED] wrote:
 You don't need a real plugin unless you need to override the dispatch process.
 But I often put convenience methods in my MyApp.pm base class. So implement 
 your
 idea #1 and then add:

 package MyApp;

 sub logdb {
my $c = shift;
my $msg = shift or croak msg required;
$c-model('AppDB')-add($msg);
 }

I would set up a config key for the model to make things flexible:

sub log_model {
  my($c) = @_;
  return $c-model($c-config-{log_model});
};

sub logdb {
   my $c = shift;
   my $msg = shift or croak msg required;
   $c-log_model-add($msg);
}

you can do this with controllers too, if you decide you need different
models per controller

-- 
edenc.vox.com

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