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