[Catalyst] Squatting::On::Catalyst

John Napiorkowski jjn1056 at yahoo.com
Fri Aug 1 17:12:22 BST 2008

--- On Fri, 8/1/08, Jonathan Rockway <jon at jrock.us> wrote:

> From: Jonathan Rockway <jon at jrock.us>
> Subject: Re: [Catalyst] Squatting::On::Catalyst
> To: "The elegant MVC web framework" <catalyst at lists.scsys.co.uk>
> Date: Friday, August 1, 2008, 2:57 AM
> * On Tue, Jul 29 2008, John Beppu wrote:
> > Now that composition and embedding of web apps is
> becoming a reality, we have
> > to start anticipating needs like this.  For example,
> the documentation for an
> > app that's built to be embedded could state that:
> Expectations suck.  Use Ernst, tag your attributes and
> classes with the
> necessary metadescription, and introspect.  The user should
> tell the
> computer what to do, not the other way around.
> >   * It expects a user object to be in its
> session's "u" key.
> The Session should be a class of course, and the class
> should have an
> attribute with a metadescription that "does"
> Squatting::Description::User, or whatever.
> >   * The app will expect to be able to call the
> ->name method on this user
> >     object.  (Some apps may want more...  others
> less...  this is just a
> >     hypothetical example.)
> The User class should have a class metadescription that
> describes what
> methods return what data.
> >   * If that key is undef, the app will assume the
> current session is not in a
> >     "logged in" state.
> Why not force the class to implement a role that provides a
> "user_is_logged_in" method?  Then there is no
> need to guess.  Just call
> the method and see.  (Actually, it would be better to be
> able to
> meta-describe methods... but I haven't implemented this
> yet.)
> -
> Someone else mentioned in another post how this sort of
> thing is
> impossible with forms, but it's actually not.  Ernst
> and Reaction have
> solved this problem.  We generate the DBIC files from the
> "row" class's
> metadescription, and we generate the form handling code
> from the same
> metadescription.  Unfortunately all of my examples are
> locked up in
> internal code right now (very experimental), and I think
> mst's code is
> mostly in the same state :)
> Anyway, here is an old Ernst demo:
> http://git.jrock.us/?p=Ernst.git;a=tree;f=prototype/catalyst/TestApp;hb=HEAD
> The important part:
> http://git.jrock.us/?p=Ernst.git;a=blob;f=prototype/catalyst/TestApp/lib/TestApp/Backend/Record.pm;hb=HEAD
> Anyway, it turns out that this is a simple problem, but
> just needs some
> tweaking for maximum enjoyment and ease of use.  (We've
> gotten rid of TT
> in the "production" version, for example, because
> the fragments are too
> hard for designers to work with.  Instead, we are using
> Template::Refine.)
> Regards,
> Jonathan Rockway
> --
> print just => another => perl => hacker => if
> $,=$"

So, you're suggesting that the shared interfaces, such as User, ect., be defined via MetaDescription Roles and then having some sort of interpreter?  I think I can see how this buys flexibility.  If you could help me understand I bit I'd be grateful.  I was thinking at first we could do this like (Entities and fields purely for example)

## Common Interface

use Moose:Role;
requires qw(name dob ...);

## Application implementation

use Moose::Role;
with 'CatalystX::Common::Role::User';
requires qw(my domain specific stuff);

use Moose;
with 'MyApp::Role::User';
extends 'DBIx::Class';

<all the rest of your storage implementation>

But if this was MetaDescription the implementation would be more like?

use Moose::Role;
requires qw(my domain specific stuff);

I guess then you'd need something to interpret the MetaDescription at the Storage level.  To be honest, I can see how this is very useful for declaring UI behaviors, but not completely seeing how it can play the role of a business logic interface.  Am I on a totally wrong track here?



More information about the Catalyst mailing list