arteymix
commented
8 years ago I've been working on a few things: I try to converge the features into a release for this summer. Right now, I'm working on a formal rule parser to reverse them!
I don't see anything that would prevent anyone from sub-classing Router. It would actually be a very good approach to solve structural complexity. It's worthy of an example and documentation recipe!
Valum supports the concept of subrouting, which can be used to assemble various routers under a single one serving requests.
var app = new Router ();
app.rule (Method.ALL, "user/*", new UserRouter ().handle);
new Server ("org.valum.example.Subrouting", app.handle);In short, you would have something like:
public class UserRouter : Router {
construct {
rule ("user/<int:id>(/<method>)?", setup).then ((req, res, next, ctx) => {
switch (ctx["method"]) {
case null:
view (req, res, next, ctx);
break;
case "delete"
delete (req, res, next, ctx);
break;
default:
throw new ClientError.NOT_FOUND ("method '%s' not defined",
ctx["method"]);
}
}).then (teardown);
}
public void setup (Request req, Response res, NextCallback next, Context ctx) {
// verify rights
next (req, res);
}
public void view (Request req, Response res, NextCallback next, Context ctx) {
// work here!
next (req, res);
}
public void new @delete (Request req, Response res, NextCallback next, Context ctx) {
// work here!
next (req, res);
}
public void teardown (Request req, Response res, NextCallback next, Context ctx) {
// (render or handle status codes)
}
}I like it!
What I think is that this is just what people need. It's flexible on all possible aspects. The rest of the answer is more hypothetical and would probably be a basis for a derived project.
GObject Introspection is surely powerful enough to automate the binding work (see template-glib, it's able to resolve method).
However, such a feature (namely a controller layer) would imply that we would enforce some conventions, which is not in line with Valum.
- what methods are bound to a function (this would require a custom annotation, probably by linking with
libvala) - how do we resolve the called function in the controller? (probably a key in the context)
Also, this would be useful only for user interaction. APIs have other requirements: work is delegated given on possible manipulations of a resource.
You could even go one step further: resolve the controller using GType, so your application would just be a set of class definitions with a middleware that handle all the resolution automatically.
As said, this would be a quite complex piece of code, but ultimately very useful.
Bob131
Hi again, I was just checking out all the new shiny stuff that's been added since I last had a peek, and I have to say I'm actually quite excited by the progress you've made. I've not had enough time with the docs to properly grok all the bits and bobs, but from my quick peruse it looks fantastic.
That said, there's a feature I'd be quite interested in. As far as I can see, currently if one so wished they could subclass the
Routerclass, add their own functions and callthis.get()etc in theconstructblock to try and move logic out ofmain()and into it's own discreet class. If this behaviour already works, could this become an official and documented way to use the framework? Perhaps further down the line some introspection magic could be added to automatically register routes based on declared functions (if that's even possible).I don't think this would confer any technical benefit, but I feel like officially supporting this method of usage would enable applications leveraging the framework to be more Vala-esque (or at least according to my understanding of "the Vala style"). In any case, it would be an additional style in the API consumer's toolbox from which they can choose depending on taste ;)