From e1d7782f712ce489857e9ca0206df19c5590ac87 Mon Sep 17 00:00:00 2001 From: Sean Corfield Date: Wed, 16 Nov 2016 22:36:26 -0800 Subject: [PATCH 1/2] Thoughts on FW/1 as middleware --- RING.md | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 RING.md diff --git a/RING.md b/RING.md new file mode 100644 index 0000000..6ca885b --- /dev/null +++ b/RING.md @@ -0,0 +1,10 @@ +# FW/1 and Ring + +FW/1 repackages a Ring request to pass it to controllers. Specifically, the Ring `:params` keys is used as the core, with the original Ring request embedded, and then optionally adding `::abort`, `::event`, `::redirect`, and `::render` keys as needed. + +Controllers are passed this hybrid map and return an updated version of it. + +If it has one of the "magic" keys, FW/1 turns that into a redirect or rendering response. Otherwise, FW/1 looks for views based on the action, then layouts, and produces a regular (HTML) response. + +Middleware can decide whether or not to call the handler. FW/1 could be middleware that calls `:before`, `before()`, the item controller itself, `after()`, and `:after` -- and decide whether / if to call the handler somewhere in there perhaps? After calling the handler (and the controllers), FW/1 could decide to run the view / layout pipeline to produce a response. + From ee35ada4636cd2d1bb2c8f4b2ba85d866d689f91 Mon Sep 17 00:00:00 2001 From: Sean Corfield Date: Wed, 16 Nov 2016 22:53:31 -0800 Subject: [PATCH 2/2] More thoughts on FW/1 and Ring --- RING.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/RING.md b/RING.md index 6ca885b..ca7e59d 100644 --- a/RING.md +++ b/RING.md @@ -8,3 +8,10 @@ If it has one of the "magic" keys, FW/1 turns that into a redirect or rendering Middleware can decide whether or not to call the handler. FW/1 could be middleware that calls `:before`, `before()`, the item controller itself, `after()`, and `:after` -- and decide whether / if to call the handler somewhere in there perhaps? After calling the handler (and the controllers), FW/1 could decide to run the view / layout pipeline to produce a response. +The question at this point is, what would become the handler in this model? + +The current implementation uses a (configured) router that accepts a keyword that determines the section / item, and the section determines where to find the `before()` and `after()` functions. + +If the handler was a simple Var, that could take the place of the keyword. But that wouldn't allow for FW/1 to wrap other middleware, making it a brittle solution. If the handler was a general request-handling function, what would be lost in FW/1? The automatically deduced `before()` and `after()` functionality (but the overall `:before` and `:after` hooks would still be present); the item controller would need to become a normal Ring handler, which could update into Ring's `:params` directly (or just add keys to the Ring request itself?); redirects, aborts, and render requests would need to be detectable by FW/1 based on normal Ring requests, to determine whether to run the view / layout pipeline. + +Need to examine how other middleware deals with this logic!