Passing application data in PSGI env

roman has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,

there are couple of middleware modules passing some application data via $env.

They may set logger ($env->{'psgix.logger'}), parsed content ($env->{'parsecontent.data'}), information whether page is fetched by robot ( $env->{robot_content} ), they may pass router or route match ($env->{'ox.router'}), ...

Is there any general convention for naming of such keys? Prefix them with the application ($env->{'myapp.router'}) and keep them flat? Keep them in one nested structure ($env->{myapp})? This way resemble stash (Catalyst or other) to me.

Do you think it is a good practice?

There is even a middleware (Plack::Middleware::FormatOutput) which use a kind of application data in body. Plack::Middleware::FormatOutput formats data returned by the wrapped application in body (third argument of psgi triplet).

While the idea of formatter implementation via middleware seems tempting, is it still middleware (the body part of triplet is neither arrayref, nor filehandle)? What do you think about such idea?

Comment on Passing application data in PSGI env

Replies are listed 'Best First'.
Re: Passing application data in PSGI env by Anonymous Monk on Apr 28, 2015 at 10:22 UTC
:) Is there any general convention for naming of such keys? Prefix them with the application ($env->{'myapp.router'}) and keep them flat? Keep them in one nested structure ($env->{myapp})? This way resemble stash (Catalyst or other) to me. Do you think it is a good practice? In general, no. Also yes. If you see PSGI, PSGI::FAQ and PSGI::Extensions you should note a naming convention is hinted at ((psgi./psgix.) but there are no recommendations for middlewares etc <update> actually says The server or the application can store its own data in the environment as well. These keys MUST contain at least one dot, and SHOULD be prefixed uniquely. </update> It makes sense to me to use plack.middleware.whatever for Plack::Middleware::Whatever, or plack.app.rest for Plack::App::REST but its obviously not in actual use <update> psgix.session.options: A hash reference to tell Middleware components how to manipulate session data after the request. Acceptable keys and values are implementation specific.</update> So there you have it, there is stuff you can do :) an update to the FAQ and some modules could be useful ... :) While the idea of formatter implementation via middleware seems tempting, is it still middleware (the body part of triplet is neither arrayref, nor filehandle)? What do you think about such idea? Doesn't matter :) try it out, warn in the docs that its an experiment , if its a good idea or a bad idea you'll learn in time :)	[reply]

Replies are listed 'Best First'.

Re: Passing application data in PSGI env
by Anonymous Monk on Apr 28, 2015 at 10:22 UTC

Is there any general convention for naming of such keys? Prefix them with the application ($env->{'myapp.router'}) and keep them flat? Keep them in one nested structure ($env->{myapp})? This way resemble stash (Catalyst or other) to me. Do you think it is a good practice?

In general, no. Also yes.

If you see PSGI, PSGI::FAQ and PSGI::Extensions you should note a naming convention is hinted at ((psgi./psgix.) but there are no recommendations for middlewares etc

<update> actually says The server or the application can store its own data in the environment as well. These keys MUST contain at least one dot, and SHOULD be prefixed uniquely. </update>

It makes sense to me to use plack.middleware.whatever for Plack::Middleware::Whatever, or plack.app.rest for Plack::App::REST but its obviously not in actual use

<update> psgix.session.options: A hash reference to tell Middleware components how to manipulate session data after the request. Acceptable keys and values are implementation specific.</update>

So there you have it, there is stuff you can do :) an update to the FAQ and some modules could be useful ... :)

While the idea of formatter implementation via middleware seems tempting, is it still middleware (the body part of triplet is neither arrayref, nor filehandle)? What do you think about such idea?

Doesn't matter :) try it out, warn in the docs that its an experiment , if its a good idea or a bad idea you'll learn in time :)

[reply]