--- On Fri, 8/1/08, Jonathan Rockway <[EMAIL PROTECTED]> wrote:

> From: Jonathan Rockway <[EMAIL PROTECTED]>
> Subject: Re: [Catalyst] Squatting::On::Catalyst
> To: "The elegant MVC web framework" <catalyst@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

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

## Application implementation

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

MyApp::Storage::Schema::Result::User;
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?

MyApp::Role::User;
use Moose::Role;
requires qw(my domain specific stuff);
__PACKAGE__->meta->metadescription->apply_role(
  'CatalystX::Description::Trait::User',
);

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?

--jjnapiorkowski



      

_______________________________________________
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/

Reply via email to