|Syntactic Confectionery Delight|
Re^2: Cool uses for Dancer/Mojo hooks (libraries over frameworks)by Dallaylaen (Chaplain)
|on Dec 14, 2016 at 11:37 UTC||Need Help??|
Thanks for your reply.
Frameworks are a pain
If they weren't, I wouldn't even bother to roll my own. And I'm trying hard to make Neaf [ni:f] act like you describe where possible.
For instance, Neaf's Request is just a regular class that is queried through public methods by both the core and the user's code. Neaf's Session storage is just a regular class with a well known interface (somewhat weird, though). Neaf's View is a regular object* with render method that converts a hashref to a pair of scalars (content & content-type). And the Model is entirely left up to the user and is supposed to be a normal Perl library usable from a standalone script.
That said, there are two complications:
1. Being run from under a web server imposes at least one inversion of control (i.e. need for hook) no matter what we do. Splitting the app into routes via URI path looks natural here. Returning status looks natural, so I decided to take it as far as "return a plain hash for rendering or die with a numeric code". But anyway the IoC is already there. Special measures are taken so that a Neaf application can run as a command-line script with --help and --list switches to aid debugging.
2. From my experience, top-down applications somehow tend to mix logic and side effects, eventually growing into huge monoliths tied to the web-server in use. The neat code glue between the well-defined, self-documenting function calls grows longer, and nobody ever cares to refactor it into more functions. It all ends in a huge Jack-of-all-trades function that has half of the model in it and cannot be split into smaller ones. Which of course is no worse than a callback hell ridden with cryptic side effects.
So now I'm seeking help in order to construct the shortest, the most obvious hook sequence with simple, straightforward primitives for transmitting shared state. Unfortunately, my own experience with existing frameworks is not enough to make conclusions. And my experience with AnyEvent tells me to be very careful when it comes to making room for callbacks.
* view => 'TT' mentioned in the example is actually a predefined alias to MVC::Neaf::View::TT->new(). One can create more such aliases via MVC::Neaf->load_view() function.