Modelling the right way

[Matthias Dietrich-3]

Hi,

the models in my past applications were quite small and if they need  
interaction with other models (like DBIC and stuff), I used  
ACCEPT_CONTEXT to either get the complete context object or part of  
it.  But all the models were related only to website parts and I  
didn't use them outside of catalyst.  But, one goal of models should  
be to be able to use them without catalyst, e.g. in cron jobs or other  
scripts.

In a "proof of concept" app I'm building right now, I need the models  
to be usable outside, so I cannot rely on the context object to  
interact with other models and the database.  My idea is to build the  
modules with business logic completly independent from catalyst and  
use the models as thin wrappers around them.  With  
Catalyst::Component::InstancePerContext I'm able to construct these  
modules per request and pass the schema as parameter to new(), so the  
module could use the database for retrieving the required data.  As  
the other models are only wrappers, too, I could just 'use' the other  
modules inside one module and pass along the schema, too.

I'm interested if this way of "modelling" is acceptable, how you  
achieved this and what is considered best practice.

Thanks,
   matt

--
rainboxx Matthias Dietrich
Freier Software Engineer

rainboxx                  |  Tel.: +49 (0) 151 / 50 60 78 64
Tölzer Str. 19            |  Mail: matt@...
70372 Stuttgart           |  WWW : http://www.rainboxx.de

XING: https://www.xing.com/profile/Matthias_Dietrich18
GULP: http://www.gulp.de/profil/rainboxx.html





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

[Eden Cardim]

On Thu, Sep 3, 2009 at 7:20 AM, Matthias Dietrich<mdietrich@...> wrote:

> Hi,
>
> the models in my past applications were quite small and if they need
> interaction with other models (like DBIC and stuff), I used ACCEPT_CONTEXT
> to either get the complete context object or part of it.  But all the models
> were related only to website parts and I didn't use them outside of
> catalyst.  But, one goal of models should be to be able to use them without
> catalyst, e.g. in cron jobs or other scripts.
>
> In a "proof of concept" app I'm building right now, I need the models to be
> usable outside, so I cannot rely on the context object to interact with
> other models and the database.  My idea is to build the modules with
> business logic completly independent from catalyst and use the models as
> thin wrappers around them.  With Catalyst::Component::InstancePerContext I'm
> able to construct these modules per request and pass the schema as parameter
> to new(), so the module could use the database for retrieving the required
> data.  As the other models are only wrappers, too, I could just 'use' the
> other modules inside one module and pass along the schema, too.
>
> I'm interested if this way of "modelling" is acceptable, how you achieved
> this and what is considered best practice.

Yes, you should be building your models as standalone modules and
using the catalyst component infrastructure merely for glueing those
into your web application. This also has the benefit of easing the
process of unit testing. Have a look at how Model::DBIC::Schema and
View::TT do it, and have a look at
http://www.catalystframework.org/calendar/2007/24

--
   Eden Cardim       Need help with your Catalyst or DBIx::Class project?
  Code Monkey                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://edenc.vox.com/            http://www.shadowcat.co.uk/servers/

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

[Alejandro Imass-3]

Hi,

Maybe this is not exactly what you are looking for but working in the
p2ee project (http://www.p2ee.org), an ERP Framework based on
Catalyst, we decided to model everything as resources and use plain
REST to expose different types of resources such as:

Business Element Resources: which map to DBIx::Class records
Business Process Resource: which map to Workflow.pm records
Application Resources: which map to complete Applications

Anyway, the BER, or Business Element Resources is a thin wrapper
around DBIx::Class records and uses Catalyst::Controller::REST to
serialize the entities. They can be single elements (a DBIC record) or
collections (many DBIC records).

To add the relevant meta-data, we get it from the DBIC column_info like so:

sub mk_element_meta {
  my $self = shift;
  my $element = shift;
  my $c = $self->{c};
  my $ad = { };
  foreach(@{$c->stash->{element_atts}}){
    my $an = $_->{att};
    my $ai = $element->column_info($an);
    # only useful meta for ui
    foreach my $k (qw(data_type default_value is_nullable size)){
      $ad->{$an}->{$k} = $_->{$k}?$_->{$k}:$ai->{$k};
    }
  }
  return $ad;
}

It then adds this metadata to the entity before serializing.

Feel free to use these ideas and implement a simple REST interface to
your model, or to use the libraries from subversion on SourceForge.
The p2ee base controller will eventually be released to CPAN so if you
want to use it right now please let me know and I will package it and
release it ASAP.

Best,
Alejandro Imass

On Thu, Sep 3, 2009 at 6:20 AM, Matthias Dietrich<mdietrich@...> wrote:

> Hi,
>
> the models in my past applications were quite small and if they need
> interaction with other models (like DBIC and stuff), I used ACCEPT_CONTEXT
> to either get the complete context object or part of it.  But all the models
> were related only to website parts and I didn't use them outside of
> catalyst.  But, one goal of models should be to be able to use them without
> catalyst, e.g. in cron jobs or other scripts.
>
> In a "proof of concept" app I'm building right now, I need the models to be
> usable outside, so I cannot rely on the context object to interact with
> other models and the database.  My idea is to build the modules with
> business logic completly independent from catalyst and use the models as
> thin wrappers around them.  With Catalyst::Component::InstancePerContext I'm
> able to construct these modules per request and pass the schema as parameter
> to new(), so the module could use the database for retrieving the required
> data.  As the other models are only wrappers, too, I could just 'use' the
> other modules inside one module and pass along the schema, too.
>
> I'm interested if this way of "modelling" is acceptable, how you achieved
> this and what is considered best practice.
>
> Thanks,
>  matt
>
> --
> rainboxx Matthias Dietrich
> Freier Software Engineer
>
> rainboxx                  |  Tel.: +49 (0) 151 / 50 60 78 64
> Tölzer Str. 19            |  Mail: matt@...
> 70372 Stuttgart           |  WWW : http://www.rainboxx.de
>
> XING: https://www.xing.com/profile/Matthias_Dietrich18
> GULP: http://www.gulp.de/profil/rainboxx.html
>
>
>
>
> _______________________________________________
> List: Catalyst@...
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@.../
> Dev site: http://dev.catalyst.perl.org/
>
>

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