view layer in rodakase will be a simple convention for preparing data for the template rendering. Since every request is handled by a processing pipeline with plugable objects (through transflow-style composition) we can simply provide a simple infrastructure for taking output from an object that is part of the pipeline and decorating it somehow to prepare a view object that is then passed to the renderer object (which is also part of the pipeline).
We can also have "helpers" but they wouldn't share any state from the request as we know how much accidental coupling it creates. Instead, we should provide the context for helpers explicitly. A helper could be an object that has that context injected, so rather than doing things like user_path(user) we'd have user_helper.resource_path. Notice that the same thing can be achieved with decorators, it is yet to be discovered which approach is simpler.
This style of view objects is nicer for templates, that's why I'm against "function" helpers, as they create way more coupling between framework-specific APIs and your templates. user_helper.resource_path is much more abstract than "a path helper" since it can easily hide the details of how that specific path is actually constructed.
view layerin rodakase will be a simple convention for preparing data for the template rendering. Since every request is handled by a processing pipeline with plugable objects (through transflow-style composition) we can simply provide a simple infrastructure for taking output from an object that is part of the pipeline and decorating it somehow to prepare aview objectthat is then passed to the renderer object (which is also part of the pipeline).We can also have "helpers" but they wouldn't share any state from the request as we know how much accidental coupling it creates. Instead, we should provide the context for helpers explicitly. A helper could be an object that has that context injected, so rather than doing things like
user_path(user)we'd haveuser_helper.resource_path. Notice that the same thing can be achieved with decorators, it is yet to be discovered which approach is simpler.This style of view objects is nicer for templates, that's why I'm against "function" helpers, as they create way more coupling between framework-specific APIs and your templates.
user_helper.resource_pathis much more abstract than "a path helper" since it can easily hide the details of how that specific path is actually constructed.