Re: [Catalyst] Squatting::On::Catalyst

[John Napiorkowski]

--- 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" 
> 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';



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/

Re: [Catalyst] Squatting::On::Catalyst

[Jonathan Rockway]

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

Re: [Catalyst] Squatting::On::Catalyst

[Matt S Trout]

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 
> ><[EMAIL PROTECTED] > 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 Directorhttp://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@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/

Re: [Catalyst] Squatting::On::Catalyst

[John Napiorkowski]

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

Re: [Catalyst] Squatting::On::Catalyst

[Bruce Keeler]

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

Re: [Catalyst] Squatting::On::Catalyst

[Daniel McBrearty]

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

Re: [Catalyst] Squatting::On::Catalyst

[John Napiorkowski]

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

> From: Ash Berlin <[EMAIL PROTECTED]>
> Subject: Re: [Catalyst] Squatting::On::Catalyst
> To: "The elegant MVC web framework" 
> 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
> <[EMAIL PROTECTED] 
> > > 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 <[EMAIL PROTECTED]> wrote:

> From: Ash Berlin <[EMAIL PROTECTED]>
> Subject: Re: [Catalyst] Squatting::On::Catalyst
> To: "The elegant MVC web framework" 
> 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
> <[EMAIL PROTECTED] 
> > > 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 fu

Re: [Catalyst] Squatting::On::Catalyst

[Ash Berlin]

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




On Tue, Jul 29, 2008 at 5:21 AM, Daniel McBrearty <[EMAIL PROTECTED] 
> 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___
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/

Re: [Catalyst] Squatting::On::Catalyst

[Matt S Trout]

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.


  discussion_controller MyForum::Thread
  discussion_action view
  discussion_field  thread_id


$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 Directorhttp://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@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/

Re: [Catalyst] Squatting::On::Catalyst

[John Beppu]

On Tue, Jul 29, 2008 at 5:21 AM, Daniel McBrearty <[EMAIL PROTECTED]
> 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
___
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/

Re: [Catalyst] Squatting::On::Catalyst

[Daniel McBrearty]

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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> w: http://www.herlpacker.co.uk/
>
>  What do you call a chav in a box?
>  Innit.
>
> ___
> 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/
>



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

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

Re: [Catalyst] Squatting::On::Catalyst

[Chisel Wright]

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: [EMAIL PROTECTED]
w: http://www.herlpacker.co.uk/

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

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

Re: [Catalyst] Squatting::On::Catalyst

[Daniel McBrearty]

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

Re: [Catalyst] Squatting::On::Catalyst

[Matt S Trout]

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 <[EMAIL PROTECTED]>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 Directorhttp://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@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/

Re: [Catalyst] Squatting::On::Catalyst

[John Beppu]

On Mon, Jul 28, 2008 at 2:40 PM, Matt S Trout <[EMAIL PROTECTED]>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@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/

Re: [Catalyst] Squatting::On::Catalyst

[Devin Austin]

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 <[EMAIL PROTECTED]> 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@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/
>
>


-- 
Devin Austin
http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost!
___
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/

Re: [Catalyst] Squatting::On::Catalyst

[Matt S Trout]

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 Directorhttp://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@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/