Thanks. I agree to everything you say but I'm still not 100% sure about the benefits of Catalyst::Model::Adaptor. Let's assume a very simplistic scenario where I have the following model class that I want to use in my web app:
So I instantiate with a directory and now I can get the contents of text files with the cat method on a file. Not very useful and realistic but it's just an example. Now I want my web app to display the contents of a file the user selects in a form. My instinct would be to do it like this in my controller:package NonCatalyst::FileCat; sub new{ my ($class, $directory) = @_; bless { _directory = $directory }, $class; } sub cat{ my ($self, $file) = @_; my $cmd = 'cat '.$self->{_directory}.'/'.$file; return `$cmd`; } 1;
use NonCatalyst::FileCat; sub show :Local { my ( $self, $c ) = @_; my $fc = NonCatalyst::FileCat->new( $c->config->{file_directory}); my $file_name = $c->request->params->{file}; $c->stash->{result} = $fc->cat( $file_name ) ; }
So I just use the external model class directly. If I need to make a change to FileCat I still only have one file to edit, so no difference to the Model::Adaptor approach there. All the configuration I need for FileCat is passd explicitly when creating the object, so I can use the same module from any script or UI implementation as long as it can pass a directory path. To me, that still seems a lot more natural and I would avoid the drawback you mention, i.e. tying my class too closely to the Catalyst configuration. Maybe this example is too simple but would you agree that this would be a case against using Catalyst::Model::Adaptor?
In reply to Re^6: Trying to understand Catalyst::Model::Adaptor
by tospo
in thread Trying to understand Catalyst::Model::Adaptor
by tospo
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |