Closed smartiniOnGitHub closed 2 years ago
Just rebased on top of updated master (for latest V changes).
Just rebased on top of updated master (for latest V changes).
Plugin System starts to work and now I'm able to add routes from a Plugin. Next step: add more features to the example, to ensure some real cases are covered and all works as expected. Cleanup will follow at the end ...
Just rebased on top of updated master (for latest V changes).
Hi, I think that now the PR is ready for initial version ...
Hi all, after re-reading the code in this PR (and current V features) I think it could be simplified a lot; I'll try to do something during next days/weeks; hope it's useful, at least to discuss if it could help splitting features. Bye
Update: just rebased on top of updated master.
Hi @nedpals I think that now the current implementation is a lot simpler and useful the same. @spytheman do you think there is something that could be further simplified/improved ?
In the examples/plugin_example.v
I wrote some way to use Plugins, to try to give a complete overview/example usage.
With Plugins, it will be possible to split parts of application in different files, (or different repos), for a better/simpler reuse of some parts.
This now is very similar to some Node.js web frameworks; I removed all the Plugin status because is not really required (at least not now).
Hope you find it useful. Tell me if there is something to update/change.
Thanks for the review. Bye
Now I think about it, there are some parts of the plugin that seems overkill for me.
Also not to be biased and favor my opinions against Go but after writing an HTTP service for few weeks, I noticed that a simple Handler
interface and a mount
method would suffice. It contains all of the stuff I found in this PR without the complex setup process.
You can check the go-chi README especially their middlewares: https://github.com/go-chi/chi
One thing to point out is that a Plugin
sounds like a framework-specific term more like a term that can be easily associated when writing web services. Hence, I'd rather call them Handler
s instead so it can serve multiple purposes (as a middleware and as a "subrouter")
Hope that really helps!
Hi and thanks for the review.
Yes maybe we could try to implement something simpler:
mount
method and set 1 Handler in each call.Handler
function like fn (req &ctx.Req, mut res ctx.Resp)
and if needed in the handler function a reference to options (or other object outside function handler scope) via closure; not sure closures are still fully supported in all V platforms, but it shouldn't be a big deal for nowDid I well understood ?
I'll look better to chi; I have some basic knowledge of Fiber, many things should be similar between them ...
Well Plugin
in general is related to a portion of an existing application; anyway if Handler
seems a better term, it's fine the same.
At this point I think it would be better to close this PR and create a new one (if possible maybe keep that branch, for some time, but it's not a big concern), ok ? If no objections I'll close the PR in a few days ...
Thanks again. Bye
Hi, this is initial code proposal for a plugin system. But keep it as a proposal/PoC, for some time I think we'll need to discuss/improve/simplify (you can see many TODO commented code, for other discussions/improvements).
I already opened some issue in V for some changes here; for sure a check/fix with them could help to improve and simplify code here; I'll link all in the original issue in vex: issue#31.
I have some ideas still to implement these days (if possible) soi the PR could be updated too. I'll mark this PR as Work-In-Progress, just to not forget.
Of course be free to merge in a dedicated branch in vex if it would be simpler even for you to make some tests; tell me so I can rebase and re-target the PR (or create a new one).
Thanks for now.