[Catalyst] Squatting::On::Catalyst

[John Napiorkowski]

--- On Wed, 7/30/08, Bruce Keeler <bruce at drangle.com> wrote:

> From: Bruce Keeler <bruce at drangle.com>
> Subject: Re: [Catalyst] Squatting::On::Catalyst
> To: "The elegant MVC web framework" <catalyst at lists.scsys.co.uk>
> Date: Wednesday, July 30, 2008, 3:38 PM
> Daniel McBrearty wrote:
> > The usual way to make things like this work is by
> having a
> > standardised api. In the case of membership for a
> website, it might
> > look something like:
> >
> > get_unique_user_id # of logged in user
> > get_username_for_id( id )
> >
> > Then if a forum has tables such as:
> >
> > thread -> references username
> > post -> ditto
> >
> > and maybe methods like
> >
> > send_pm( user )
> > find_posts( user )
> >
> > if you are prepared to sacrifice the actual foreign
> key relationship,
> > not that big a thing IMHO, you can do it all through
> the API. The
> > person that writes the forum code/schema can actually
> have two install
> > options - with and without the user table.
> >
> > Cat almost has this in place at present.
> >
> >   
> Seems to me the easiest way would be to have the forum
> module have it's 
> own user table, keyed by the same user id as the core user
> table.  Then 
> it can store whatever it wants in there, like signatures,
> posting 
> preferences or whatever.  The core user table/object could
> have a few 
> well-known attributes like real name, email address and so
> on, but not 
> much else.

If we could identify the core entities and attributes, we could write the generic interface and then write a default implementation in one or two of the popular or viable storage systems (DBIC comes to mind because that would be easy for me, as well as MooseX::Storage since that looks like it could be fun :) )

Then when someone creates a their Catalyst application, we say it's best practice that their User model either follow the interface (if they have to write their own, or have very custom needs) or extend one of the popular existing sample implementations.  If they do that, what they get is the ability to just plug and run with any extended framework that needs that standard User object interface.

Then we don't have to worry at all about how the implementation achieves it's ends, or if the developer has very custom needs.  As long as the model implements the interface all will work as desired.

After we had some common domain models we could move on and have similar for some basic things we all implement over and over, like a Login Controller, etc.

We could stick all this under CatalystX namespace.  How about 'CatalystX::DNA' or similar?  Besides a User entity, what others do you all think we need?

--jjnapiorkowski

> 
> _______________________________________________
> List: Catalyst at 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/