--- On Wed, 7/30/08, Bruce Keeler <[EMAIL PROTECTED]> wrote:

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


      

_______________________________________________
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