[Catalyst] Squatting::On::Catalyst

[John Napiorkowski]

--- On Wed, 7/30/08, Ash Berlin <ash_cpan at firemirror.com> wrote:

> From: Ash Berlin <ash_cpan at firemirror.com>
> Subject: Re: [Catalyst] Squatting::On::Catalyst
> To: "The elegant MVC web framework" <catalyst at lists.scsys.co.uk>
> Date: Wednesday, July 30, 2008, 7:02 AM
> On 30 Jul 2008, at 02:27, John Beppu wrote:
> 
> >
> >
> > On Tue, Jul 29, 2008 at 5:21 AM, Daniel McBrearty
> <danielmcbrearty at gmail.com 
> > > wrote:
> > my 0.05 (possibly a bit OT) :
> >
> > Off-topic or not, I think these are interesting and
> valid questions.
> >
> > I looked previously at a few ways of adding forums etc
> to the site
> > using 3rd party code, indeed there are many
> possibilites (some perl,
> > some not)
> >
> > The thing that was always a sticker for me was getting
> some kind of
> > logical integration, ie:
> >
> > 1. letting users keep existing member and login creds
> >
> > 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:
> > It expects a user object to be in its session's
> "u" key.
> > 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.)
> > If that key is undef, the app will assume the current
> session is not  
> > in a "logged in" state.
> >  I think being up-front about login policy would be
> enough to share  
> > users across multiple web apps joined together as one
> cohesive unit.
> 
> 
> I dont. Lets take the example of embedding a forum. It will
> most  
> likely store its data in a DB of its own design. It will
> also quite  
> likely have its own user table, and have FKs referencing
> that  
> table.... see the problem? There's more to sharing
> users than just  
> logging.
> 
> I can't really see any way around that other than on a
> case-by-case  
> basis sadly. Someone please feel free to correct me.
> 
> -ash




--- On Wed, 7/30/08, Ash Berlin <ash_cpan at firemirror.com> wrote:

> From: Ash Berlin <ash_cpan at firemirror.com>
> Subject: Re: [Catalyst] Squatting::On::Catalyst
> To: "The elegant MVC web framework" <catalyst at lists.scsys.co.uk>
> Date: Wednesday, July 30, 2008, 7:02 AM
> On 30 Jul 2008, at 02:27, John Beppu wrote:
> 
> >
> >
> > On Tue, Jul 29, 2008 at 5:21 AM, Daniel McBrearty
> <danielmcbrearty at gmail.com 
> > > wrote:
> > my 0.05 (possibly a bit OT) :
> >
> > Off-topic or not, I think these are interesting and
> valid questions.
> >
> > I looked previously at a few ways of adding forums etc
> to the site
> > using 3rd party code, indeed there are many
> possibilites (some perl,
> > some not)
> >
> > The thing that was always a sticker for me was getting
> some kind of
> > logical integration, ie:
> >
> > 1. letting users keep existing member and login creds
> >
> > 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:
> > It expects a user object to be in its session's
> "u" key.
> > 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.)
> > If that key is undef, the app will assume the current
> session is not  
> > in a "logged in" state.
> >  I think being up-front about login policy would be
> enough to share  
> > users across multiple web apps joined together as one
> cohesive unit.
> 
> 
> I dont. Lets take the example of embedding a forum. It will
> most  
> likely store its data in a DB of its own design. It will
> also quite  
> likely have its own user table, and have FKs referencing
> that  
> table.... see the problem? There's more to sharing
> users than just  
> logging.
> 
> I can't really see any way around that other than on a
> case-by-case  
> basis sadly. Someone please feel free to correct me.
> 
> -ash

I'm not sure we can have a fully sharable system for the reasons you mentioned.  Everyone has particular needs and desires in the way they will name things, normalize/denormalise a database, etc.  However I think it might be possible to define common functionality using Moose Roles and then letting people write their custom code against that.  Then we could actually build shared bits that require models that do those roles.  Something like:

CatalystX-CommonModels
  /lib
    /CatalystX
      /CommonModels
        /Role
          User.pm
          /Provider
            Users.pm

..and so on for defining Controllers and commone View types, even Action objects.  The common Role stuff would be defined by the community to have the minimal requirements.  So then I could write a custom application, like say an addressbook app that expects a model that does the User Role.  That User role could be defined by some existing other set of components, from maybe a Forum Application or just a roll your own application.

This would enable interoperability without forcing a particular implementation.  Your local implementation just needs to consume the Role and then anyone expecting that Role would just get what they want.

I realize this would mean all these classes would need to be Moose based, but I don't see that as a huge hurdle to ask the community when it will buy us so much.

--JohnN