Plug stacks about plug HOT 20 CLOSED

This approach looks great. I started prototyping it out to get a feel for it, but I'm running into an issue with the plug macro:

Since plugs can be either Call plugs or Wrapper plugs, we'll need to know which type they are. I'm trying to aggregate this information as tagged tuples at compile time, but I'm having to reach for things like function_exported? to know if a Module plug exports wrap/3 or call/2. This then requires tricky Code.ensure_compiled invocations.

The easiest fix for this would be to provide use Plug.Call use Plug.Wrap that inject a function that returns the Plug type, at the cost of Plugs no longer being just plain modules. I'm in favor of the light use since it will allow later extension if we need extra metadata, default funcs, etc. Thoughts?

from plug.

Maybe call .init/1 on it first? After that point it will be loaded and
function_exported? should work fine.

José Valimwww.plataformatec.com.br
http://www.plataformatec.com.br/Founder and Lead Developer

from plug.

Hello everyone, I have pushed this implementation to master, as well as a Plug.Builder. I ask everyone to give it a go.

Keep in mind a backwards incompatible change was done to plug since the return result should now be a connection and no longer a tuple. For this reason, I have bumped plug to 0.3.0-dev. It also depends on Elixir master 0.12.4-dev, which will likely be released tomorrow.

from plug.

I was able to update the router for sugar to use 0.3.0-dev without a hitch. I'm going to write a couple of basic plugs to test out plug stacks tonight. I'll report back.

Edit: Wrote a simple static file plug. Process was straightforward and problemless.

from plug.

@josevalim Are wrappers meant to address the need to write e.g. exception handling plugs?

from plug.

@devinus yes, exactly.

from plug.

@josevalim This question is rather about code maintenance of possibly-dependant projects.

This design looks cool. Are you going at some moment to promote Plug stacks within Dynamo? Would you like to have some parts of Dynamo replaces by Plugs (various session storages, incl. new ones, come to mind at first)? Considering you don''t have infinite amounts of time, would you welcome dirty patches to Dynamo with this?

cheers,
hnc

from plug.

I no longer maintain Dynamo, so you will have to talk to its maintainers. In any case, I do want to start moving some plugs to this repo.

from plug.

@herenowcoder Dynamo's future is tied to Plug, but we're currently waiting for some big changes in Plug exactly like this.

from plug.

@josevalim How do you see wrapper plugs storing state in the connection between before and after the callback function e.g. for session stores? I see using Plug.Conn.assigns as an options, but I could also see that possibly getting unwieldy with multiple wrapper plugs and/or a web application that uses Plug.Conn.assigns to pass data to a template or view.

from plug.

Dynamo had a private field for that. We should probably add the same here.

José Valimwww.plataformatec.com.br
http://www.plataformatec.com.br/Founder and Lead Developer

from plug.

Cool. That sounds like a plan. I'm working on a couple of plugs for session and cache data, and that had come up.

from plug.

Gentlemen, can I release v0.3.0?

from plug.

👍

from plug.

👍

from plug.

Pushed and tagged!

from plug.

@josevalim can you push docs?

http://elixir-lang.org/docs/plug/ still showing v0.2.0

from plug.

Done! I am very happy with this release because we can finally start adding the remaining wrappers, like the one that shows exceptions and the static one!

from plug.

@josevalim Are you accepting pull requests for those? I have a few, including one for static files, over at https://github.com/sugar-framework/plugs that I could submit after some cleaning up and tests.

from plug.

@slogsdon definitely. I have the static one locally already but we should definitely start adding the remaining ones like session. Please open issues to start a discussion to be sure before implementing it. :)

from plug.