Squatting on Catalyst, what about the others?

0 views
Skip to first unread message

ido50

unread,
Jun 24, 2009, 3:34:51 AM6/24/09
to squatting-framework
Let's say I write a Squatting application and mount it on Catalyst. Do
I have access to the Catalyst context? Can I access Catalyst models
from within the Squatting app and the current user object ($c->user)?

And if I can, does that make my Squatting app a Catalyst-only app? How
can I avoid that? If possible, I'd like my Squatting app to get a user
object from whatever backend it is mounted on and use its own model.

Any direction will be appreciated. Thanks.

beppu

unread,
Jun 25, 2009, 4:47:52 PM6/25/09
to squatting-framework
On Jun 24, 12:34 am, ido50 <idope...@gmail.com> wrote:
> Let's say I write a Squatting application and mount it on Catalyst. Do
> I have access to the Catalyst context? Can I access Catalyst models
> from within the Squatting app and the current user object ($c->user)?

You will not have access to Catalyst's context unless you put it
inside Catalyst's $c->stash or $c->session *BEFORE* handing control
over to the mounted Squatting app. I wouldn't recommend passing in
the whole context, though. I would just pass in what you need.

For example:

# In a Catalyst app's controller...
use App 'On::Catalyst'
App->init;
App->relocate('/somewhere')
sub somewhere : Local {
my ($self, $c) = @_;
$c->stash->{user} = $c->user; # Catalyst <=> Squatting
communication via stash
App->catalyze($c)
}

And then inside Squatting controllers, $self->v->{user} will contain
the user object you previously stashed.

If you look at the POD for Squatting::On::Catalyst, you'll see that:

$c->session == $self->state
$c->stash == $self->v
$c->log == $self->log

Thus, Catalyst <=> Squatting communication can be done through $c-
>session and $c->stash.



> And if I can, does that make my Squatting app a Catalyst-only app? How
> can I avoid that?

This is what I wanted to avoid. Hypothetically speaking, if I were to
let Squatting apps have knowledge of what they're squatting on, they
can easily become non-portable just as you've deduced. The only
backend that I give special treatment to is Squatting::On::Continuity,
because it has capabilities that no one else has. That's why you have
access to a Continuity::Request object via $self->cr when you're
Squatting::On::Continuity. Any app that uses $self->cr is non-
portable to other backends, but that's OK, because you're probably
doing some crazy stuff that isn't possible with the other backends
anyway.

However, I'd like to see people develop generally-useful, portable
Squatting apps.

The thing is, I don't ever intend to go head on with Catalyst or Jifty
or whatever. I'd much rather prefer that Squatting play a supporting
role for *ALL* other perl-based web frameworks. (Cooperation is way
less stressful than competition.) If someone needs a guest book or a
forum or a store, it'd be nice if someday, they could just embed a
Squatting app into their pre-existing site, customize (or even
replace) the view object to suit their needs, and be good to go.

Squatting makes modular web applications possible, but it's still
somewhat uncharted territory. (I know it can be done, but the best
practices for this are not clear, yet.)

--beppu

ido50

unread,
Jun 26, 2009, 8:33:33 AM6/26/09
to squatting-framework
Thanks a lot, I now know what to do.
Reply all
Reply to author
Forward
0 new messages