PSGI ENV keys for Application and Context

[jjn1056]

Allow one to get at a containing Catalyst application and context from the PSGI env, so that when you are using catalyst to delegate to other web frameworks, that child application can access stuff like the parent's models.

[jjn1056]

Basically I'd like to rethink the relationship between PSGI $env and $ctx

[ryan-lang]

@jjn1056 In the meantime, is there an alternate way to accomplish this? And would you mind pointing me in the right direction? I would very much like to have two Catalyst apps running in a single psgi environment to have access to one another.

[perl-catalyst-sync]

When you say, "two Catalyst apps running in a single psgi environment" that
can be a few things. Do you have two applications that are mounted to
different route points (like with Plack::Builder) or do you have a Catalyst
application that is calling another Catalyst application?

In the first case it might be better to have a common model that both
applications proxy via something like Catalyst::Model::Adaptor. In the
second case you have to pass information to the second application by
setting the PSGI env with a key manually.

On Wed, Nov 16, 2016 at 4:44 PM, ryan-lang notifications@github.com wrote:

@jjn1056 https://github.com/jjn1056 In the meantime, is there an
alternate way to accomplish this? And would you mind pointing me in the
right direction? I would very much like to have two Catalyst apps running
in a single psgi environment to have access to one another.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#52 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACPUZfqZ_eadkxldN5inOYaJWCGz5XGqks5q-4dIgaJpZM4CiJWJ
.

[ryan-lang]

It sounds like maybe I'm barking up the wrong tree...

My goal is to break up a single large application into several smaller ones that can be run either independently or embedded in a wrapper/parent app. Sharing models between parent & child is not a huge priority, because I want my child apps to be pretty independent, but allowing the parent to access the child's dispatcher (so I can do stuff like uri_for) is pretty important.

My plan was to find a way to store a reference to the child(ren) in the parent somehow. But given the two options you outlined (up until now I've been using Plack::Builder in the way you described), I'm starting to think this is not something that can be reasonably accomplished?

[perl-catalyst-sync]

You can use a catalyst application to dispatch to another catalyst
application. That was one reason I did the stash to middleware thing, the
idea was to be able to share the share across applications. However I
never had enough backing or conversation about that (or people telling me
it was a desired feature) so its probably a little manual effort.

Basic example http://www.catalystframework.org/calendar/2014/3 (that
doesn't mount a catalyst app, but the approach would be the same). I
though I did a test case but not spotting it

http://www.catalystframework.org/calendar/2014/4 as welll (for sharing the
stash between applications)

Not sure if that helps. -jnap

On Wed, Nov 16, 2016 at 5:35 PM, ryan-lang notifications@github.com wrote:

It sounds like maybe I'm barking up the wrong tree...

My goal is to break up a single large application into several smaller
ones that can be run either independently or embedded in a wrapper/parent
app. Sharing models between parent & child is not a huge priority, because
I want my child apps to be pretty independent, but allowing the parent to
access the child's dispatcher (so I can do stuff like uri_for) is pretty
important.

My plan was to find a way to store a reference to the child(ren) in the
parent somehow. But given the two options you outlined (up until now I've
been using Plack::Builder in the way you described), I'm starting to think
this is not something that can be reasonably accomplished?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#52 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACPUZeVA7DXQkeWTzZLynncRZS767H5yks5q-5NHgaJpZM4CiJWJ
.

[ryan-lang]

Thanks for the guidance - much appreciated!