Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Catalyst: Users

Squatting::On::Catalyst

 

 

Catalyst users RSS feed   Index | Next | Previous | View Threaded


john.beppu at gmail

Jul 28, 2008, 8:27 AM

Post #1 of 18 (7238 views)
Permalink
Squatting::On::Catalyst

*Squatting::On::Catalyst*

Squatting is a web microframework for Perl that's based on Camping from the
Ruby world. During the transition from Ruby to Perl, Squatting gained some
mutant powers which is why I'm writing to you today.

One of Squatting's mutant powers is its ability to embed itself into other
frameworks (like Catalyst). You can take whole Squatting apps, and embed
them into your existing web application with just a few lines of glue code.
Allow me to demonstrate.


STEP 1: Install Pod::Server from CPAN.

$ sudo cpan Pod::Server



STEP 2: Run Pod::Server so you can see what it looks like.

$ squatting Pod::Server -p 8088

or

$ pod_server

Then, visit http://localhost:8088/ and pay attention to the URLs as you
click around. (This will be interesting when you see how the URLs of the
whole site will be "relocated" later on in the demonstration.)



STEP 3: Create a Catalyst application.

$ catalyst.pl Propaganda



STEP 4: Embed Pod::Server into the Catalyst application.

$ cd Propaganda
$ $EDITOR lib/Propaganda/Controller/Root.pm

Then, add the following lines of code to an appropriate place in the
controller.

use Pod::Server 'On::Catalyst';
Pod::Server->init;
Pod::Server->relocate('/pod');
$Pod::Simple::HTML::Perldoc_URL_Prefix = '/pod/';
sub pod : Local { Pod::Server->catalyze($_[1]) }



STEP 5: Start up the Catalyst application.

$ script/propaganda_server.pl

Finally, visit http://localhost:3000/pod/ . If everything worked, you
should see that Pod::Server has just been embedded into a Catalyst
application.



*What Are The Implications of This?*

Right now, anyone who is developing a web app with Catalyst can install
Pod::Server from CPAN and embed it directly into their web app. However,
this is just the beginning.

Imagine if you could install a blog, a wiki, a forum, or a store just as
easily.

Imagine adding major functionality to any Perl-based site with ~5 lines of
code.

Squatting makes modular web applications both possible and probable.

http://search.cpan.org/dist/Squatting/

http://github.com/beppu/squatting/tree/master


dbix-class at trout

Jul 28, 2008, 2:40 PM

Post #2 of 18 (7095 views)
Permalink
Re: Squatting::On::Catalyst [In reply to]

On Mon, Jul 28, 2008 at 08:27:27AM -0700, John Beppu wrote:
> *Squatting::On::Catalyst*
>
> Squatting is a web microframework for Perl that's based on Camping from the
> Ruby world. During the transition from Ruby to Perl, Squatting gained some
> mutant powers which is why I'm writing to you today.
>
> One of Squatting's mutant powers is its ability to embed itself into other
> frameworks (like Catalyst). You can take whole Squatting apps, and embed
> them into your existing web application with just a few lines of glue code.
> Allow me to demonstrate.

Assuming Squatting supports CGI, Catalyst::Controlle::WrapCGI enabled this
already. Your code is almost certainly more efficient though.

> *What Are The Implications of This?*
>
> Right now, anyone who is developing a web app with Catalyst can install
> Pod::Server from CPAN and embed it directly into their web app. However,
> this is just the beginning.
>
> Imagine if you could install a blog, a wiki, a forum, or a store just as
> easily.

Yeah, we'll be doing that for arbitrary Catalyst components for 5.80,
I hope. This is still really cool, mind.

In the meantime, please have a look at the HTTP::Engine project so that
you can share HTTP code with other frameworks, and consider joining the
catalyst-dev list since we're planning to kick off a project to see about
sharing dispatchers with other projects as well.

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


devin.austin at gmail

Jul 28, 2008, 3:36 PM

Post #3 of 18 (7113 views)
Permalink
Re: Squatting::On::Catalyst [In reply to]

I'd like to express my interest in this project as well, kick ass!

-Devin

On Mon, Jul 28, 2008 at 9:27 AM, John Beppu <john.beppu [at] gmail> wrote:

> *Squatting::On::Catalyst*
>
> Squatting is a web microframework for Perl that's based on Camping from the
> Ruby world. During the transition from Ruby to Perl, Squatting gained some
> mutant powers which is why I'm writing to you today.
>
> One of Squatting's mutant powers is its ability to embed itself into other
> frameworks (like Catalyst). You can take whole Squatting apps, and embed
> them into your existing web application with just a few lines of glue code.
> Allow me to demonstrate.
>
>
> STEP 1: Install Pod::Server from CPAN.
>
> $ sudo cpan Pod::Server
>
>
>
> STEP 2: Run Pod::Server so you can see what it looks like.
>
> $ squatting Pod::Server -p 8088
>
> or
>
> $ pod_server
>
> Then, visit http://localhost:8088/ and pay attention to the URLs as you
> click around. (This will be interesting when you see how the URLs of the
> whole site will be "relocated" later on in the demonstration.)
>
>
>
> STEP 3: Create a Catalyst application.
>
> $ catalyst.pl Propaganda
>
>
>
> STEP 4: Embed Pod::Server into the Catalyst application.
>
> $ cd Propaganda
> $ $EDITOR lib/Propaganda/Controller/Root.pm
>
> Then, add the following lines of code to an appropriate place in the
> controller.
>
> use Pod::Server 'On::Catalyst';
> Pod::Server->init;
> Pod::Server->relocate('/pod');
> $Pod::Simple::HTML::Perldoc_URL_Prefix = '/pod/';
> sub pod : Local { Pod::Server->catalyze($_[1]) }
>
>
>
> STEP 5: Start up the Catalyst application.
>
> $ script/propaganda_server.pl
>
> Finally, visit http://localhost:3000/pod/ . If everything worked, you
> should see that Pod::Server has just been embedded into a Catalyst
> application.
>
>
>
> *What Are The Implications of This?*
>
> Right now, anyone who is developing a web app with Catalyst can install
> Pod::Server from CPAN and embed it directly into their web app. However,
> this is just the beginning.
>
> Imagine if you could install a blog, a wiki, a forum, or a store just as
> easily.
>
> Imagine adding major functionality to any Perl-based site with ~5 lines of
> code.
>
> Squatting makes modular web applications both possible and probable.
>
> http://search.cpan.org/dist/Squatting/
>
> http://github.com/beppu/squatting/tree/master
>
>
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>
>


--
Devin Austin
http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost!


john.beppu at gmail

Jul 28, 2008, 9:36 PM

Post #4 of 18 (7100 views)
Permalink
Re: Squatting::On::Catalyst [In reply to]

On Mon, Jul 28, 2008 at 2:40 PM, Matt S Trout <dbix-class [at] trout>wrote:

> On Mon, Jul 28, 2008 at 08:27:27AM -0700, John Beppu wrote:
>
>
> > Imagine if you could install a blog, a wiki, a forum, or a store just as
> > easily.
>
> Yeah, we'll be doing that for arbitrary Catalyst components for 5.80,
> I hope. This is still really cool, mind.
>

Good luck w/ that. I don't know the guts of Catalyst too well, but I have a
feeling it could be tricky.



In the meantime, please have a look at the HTTP::Engine project so that
> you can share HTTP code with other frameworks, and consider joining the
> catalyst-dev list since we're planning to kick off a project to see about
> sharing dispatchers with other projects as well.
>

HTTP::Engine was exactly what I needed when I started the project. I'm glad
I know about it, now.



>
> --
> Matt S Trout Need help with your Catalyst or DBIx::Class
> project?
> Technical Director
> http://www.shadowcat.co.uk/catalyst/
> Shadowcat Systems Ltd. Want a managed development or deployment platform?
> http://chainsawblues.vox.com/
> http://www.shadowcat.co.uk/servers/
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>


dbix-class at trout

Jul 29, 2008, 2:08 AM

Post #5 of 18 (7091 views)
Permalink
Re: Squatting::On::Catalyst [In reply to]

On Mon, Jul 28, 2008 at 09:36:44PM -0700, John Beppu wrote:
> On Mon, Jul 28, 2008 at 2:40 PM, Matt S Trout <dbix-class [at] trout>wrote:
>
> > On Mon, Jul 28, 2008 at 08:27:27AM -0700, John Beppu wrote:
> >
> >
> > > Imagine if you could install a blog, a wiki, a forum, or a store just as
> > > easily.
> >
> > Yeah, we'll be doing that for arbitrary Catalyst components for 5.80,
> > I hope. This is still really cool, mind.
> >
>
> Good luck w/ that. I don't know the guts of Catalyst too well, but I have a
> feeling it could be tricky.

Most interesting features are at least somewhat tricky.

Anyway, non-tricky code is boring to write :)

> In the meantime, please have a look at the HTTP::Engine project so that
> > you can share HTTP code with other frameworks, and consider joining the
> > catalyst-dev list since we're planning to kick off a project to see about
> > sharing dispatchers with other projects as well.
> >
>
> HTTP::Engine was exactly what I needed when I started the project. I'm glad
> I know about it, now.

Please do pop onto irc.perl.org#http-engine if you need to suggest anything
to the devs - they're very happy to hear wishlist stuff from potential users.

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


danielmcbrearty at gmail

Jul 29, 2008, 5:21 AM

Post #6 of 18 (7095 views)
Permalink
Re: Squatting::On::Catalyst [In reply to]

my 0.05 (possibly a bit OT) :

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
2. being able to cross ref to other parts of the site eg. for a
certain node, easily have a "discussion" link, and the reverse link
from the forum

I haven't yet seen a way to do this that looks easier than doing it
from scratch (well, lets say some heavy porting of existing db
structures and code from existing stuff ...)

IMO getting these kind of features right are where the real meat is.
Looking at the summary, I guess that's not what the focus of this
project is, so if this is post is basically just noise, please forgive
that.

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


chisel at herlpacker

Jul 29, 2008, 6:08 AM

Post #7 of 18 (7087 views)
Permalink
Re: Squatting::On::Catalyst [In reply to]

On Tue, Jul 29, 2008 at 02:21:10PM +0200, Daniel McBrearty wrote:
> 1. letting users keep existing member and login creds
> 2. being able to cross ref to other parts of the site eg. for a
> certain node, easily have a "discussion" link, and the reverse link
> from the forum

If you ever think of a good way of doing this, please let me know!

--
Chisel Wright
e: chisel [at] herlpacker
w: http://www.herlpacker.co.uk/

What do you call a chav in a box?
Innit.

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


danielmcbrearty at gmail

Jul 29, 2008, 6:28 AM

Post #8 of 18 (7083 views)
Permalink
Re: Squatting::On::Catalyst [In reply to]

I've been meaning to dig into the everything2 code (which powers
perlmonks I think, amongst other things ..) and see how they do the
cross ref stuff. They seem to have a pretty nice "node" abstraction
which is the core of the problem, I think.

the membership stuff relies on a common API, I guess. Doesn't claco
have a project that addresses that?

On Tue, Jul 29, 2008 at 3:08 PM, Chisel Wright <chisel [at] herlpacker> wrote:
> On Tue, Jul 29, 2008 at 02:21:10PM +0200, Daniel McBrearty wrote:
>> 1. letting users keep existing member and login creds
>> 2. being able to cross ref to other parts of the site eg. for a
>> certain node, easily have a "discussion" link, and the reverse link
>> from the forum
>
> If you ever think of a good way of doing this, please let me know!
>
> --
> Chisel Wright
> e: chisel [at] herlpacker
> w: http://www.herlpacker.co.uk/
>
> What do you call a chav in a box?
> Innit.
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>



--
There's an infinite supply of time, we just don't have it all yet.

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


john.beppu at gmail

Jul 29, 2008, 6:27 PM

Post #9 of 18 (7059 views)
Permalink
Re: Squatting::On::Catalyst [In reply to]

On Tue, Jul 29, 2008 at 5:21 AM, Daniel McBrearty <danielmcbrearty [at] gmail
> 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.

2. being able to cross ref to other parts of the site eg. for a
> certain node, easily have a "discussion" link, and the reverse link
> from the forum


I haven't thought about this problem much at all. My initial thought is
that (again) the app that's going to be embedded would have to be written to
anticipate this kind of need. Perhaps the app-to-be-embedded could provide
a configuration option for the embedder to fill in with an appropriate
value. This option would control how links would be generated in key
portions of the app.

I haven't yet seen a way to do this that looks easier than doing it
> from scratch (well, lets say some heavy porting of existing db
> structures and code from existing stuff ...)
>
> IMO getting these kind of features right are where the real meat is.
> Looking at the summary, I guess that's not what the focus of this
> project is, so if this is post is basically just noise, please forgive
> that.


No need for apologies.

The questions that you bring up have definitely crossed my mind. It's true
that my work so far does not address these questions at all, but at the same
time, this kind of work is a sort of prerequisite for these questions. (You
couldn't even ask questions about mixing sites together "cohesively" if you
couldn't mix them together at all, right?)


--beppu


dbix-class at trout

Jul 30, 2008, 3:34 AM

Post #10 of 18 (7083 views)
Permalink
Re: Squatting::On::Catalyst [In reply to]

On Tue, Jul 29, 2008 at 02:08:21PM +0100, Chisel Wright wrote:
> On Tue, Jul 29, 2008 at 02:21:10PM +0200, Daniel McBrearty wrote:
> > 1. letting users keep existing member and login creds
> > 2. being able to cross ref to other parts of the site eg. for a
> > certain node, easily have a "discussion" link, and the reverse link
> > from the forum
>
> If you ever think of a good way of doing this, please let me know!

Starter for 10.

<Controller Page>
discussion_controller MyForum::Thread
discussion_action view
discussion_field thread_id
</Controller>

$c->uri_for(
$c->controller($self->discussion_controller)
->action_for($self->discussion_action),
[ $current_page->id ]
);

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


ash_cpan at firemirror

Jul 30, 2008, 4:02 AM

Post #11 of 18 (7078 views)
Permalink
Re: Squatting::On::Catalyst [In reply to]

On 30 Jul 2008, at 02:27, John Beppu wrote:

>
>
> On Tue, Jul 29, 2008 at 5:21 AM, Daniel McBrearty <danielmcbrearty [at] gmail
> > 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


jjn1056 at yahoo

Jul 30, 2008, 8:26 AM

Post #12 of 18 (7072 views)
Permalink
Re: Squatting::On::Catalyst [In reply to]

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

> From: Ash Berlin <ash_cpan [at] firemirror>
> Subject: Re: [Catalyst] Squatting::On::Catalyst
> To: "The elegant MVC web framework" <catalyst [at] lists>
> 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
> > > 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> wrote:

> From: Ash Berlin <ash_cpan [at] firemirror>
> Subject: Re: [Catalyst] Squatting::On::Catalyst
> To: "The elegant MVC web framework" <catalyst [at] lists>
> 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
> > > 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




_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


danielmcbrearty at gmail

Jul 30, 2008, 12:15 PM

Post #13 of 18 (7065 views)
Permalink
Re: Squatting::On::Catalyst [In reply to]

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.

--
There's an infinite supply of time, we just don't have it all yet.

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


bruce at drangle

Jul 30, 2008, 12:38 PM

Post #14 of 18 (7066 views)
Permalink
Re: Squatting::On::Catalyst [In reply to]

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.

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


jjn1056 at yahoo

Jul 30, 2008, 5:18 PM

Post #15 of 18 (7077 views)
Permalink
Re: Squatting::On::Catalyst [In reply to]

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

> From: Bruce Keeler <bruce [at] drangle>
> Subject: Re: [Catalyst] Squatting::On::Catalyst
> To: "The elegant MVC web framework" <catalyst [at] lists>
> 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
> Listinfo:
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/




_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


dbix-class at trout

Jul 31, 2008, 3:52 PM

Post #16 of 18 (7047 views)
Permalink
Re: Squatting::On::Catalyst [In reply to]

On Wed, Jul 30, 2008 at 12:02:08PM +0100, Ash Berlin wrote:
>
> On 30 Jul 2008, at 02:27, John Beppu wrote:
>
> >
> >
> >On Tue, Jul 29, 2008 at 5:21 AM, Daniel McBrearty
> ><danielmcbrearty [at] gmail > 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.

Assume all apps use (uid, username, password).

Then if they're all also using DBIC, it's fairly easy. Each "sub-app" uses
the same credential and a store that maps to -its- user class.

We need to have attribute names and column names truly separated though,
which means DBIC 09 most likely.

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


jon at jrock

Jul 31, 2008, 11:57 PM

Post #17 of 18 (7039 views)
Permalink
Re: Squatting::On::Catalyst [In reply to]

* 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 $,=$"

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


jjn1056 at yahoo

Aug 1, 2008, 9:12 AM

Post #18 of 18 (7022 views)
Permalink
Re: Squatting::On::Catalyst [In reply to]

--- On Fri, 8/1/08, Jonathan Rockway <jon [at] jrock> wrote:

> From: Jonathan Rockway <jon [at] jrock>
> Subject: Re: [Catalyst] Squatting::On::Catalyst
> To: "The elegant MVC web framework" <catalyst [at] lists>
> 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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

Catalyst users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.