Re: Cool uses for Dancer/Mojo hooks (libraries over frameworks)

in reply to Cool uses for Dancer/Mojo hooks

Frameworks are a pain, mostly because they end up needing hooks to be implemented. Hooks suck for more reasons that just it not being obvious what hooks should even be provided.

Libraries are a much better form of abstraction. Implement your functionality in properly abstracted subroutines with clear names that are easy to test. Then, if a user just wants the default behavior, they can just call the top-level subroutine and be done. If they want to customize parts, then they instead copy the structure of the top-level subroutine but add in their custom code where they need to. The top level subroutine should just be calls to other subroutines.

If you can easily test your subroutines and can give them clear names, then you've abstracted things well which means that the places where customization will be wanted are very likely to be "between" those subroutine calls.

- tye

Comment on Re: Cool uses for Dancer/Mojo hooks (libraries over frameworks)

Replies are listed 'Best First'.
Re^2: Cool uses for Dancer/Mojo hooks (libraries over frameworks) by Dallaylaen (Chaplain) on Dec 14, 2016 at 11:37 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^2: Cool uses for Dancer/Mojo hooks (libraries over frameworks)
by Dallaylaen (Chaplain) on Dec 14, 2016 at 11:37 UTC

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.

[reply]

In Section Seekers of Perl Wisdom