Commit c181803a authored by Markus Willman's avatar Markus Willman

reformat the appendix a little

parent 027d5fe3
......@@ -81,7 +81,7 @@ for the scenarios where it is still necessary. Does not support any HTTP cache m
Response\XmlResponse
: This typed response represents, usually dynamically generated, XML response supports both ``SimpleXml`` and
``DOMDocument`` out of the box, along with strings and files, however, ill suited for static files due to lack of
``DOMDocument`` out of the box, along with strings and files, however, ill-suited for static files due to lack of
support for caching. Likewise suited for API responses.
#### A2. DCBase: Code, Usage and Design
......@@ -94,21 +94,19 @@ that calls the ``send()`` method of an instance of ``WebResponse`` which matches
As for the WebResponse instances, their public interface aims to be such that most of the time all that is required is a
call to one of the static factory methods of the abstract parent class corresponding to the expected return type, with the
correct parameters, chained directly to a send call.
correct parameters, chained directly to a send call. The best code usage examples, would actually probably be the myriad of
factories defined as part of WebResponse. Particularly the ones for errors and redirects.
Additionally, the system aims deliberately to be as stateless as possible, excluding data that is the same for every visiting
user when it comes to what happens on the server side the default style add some limited state through the use of cookies.
Which ironically is in part to comply with the largely useless EU directive about browser cookies.
The best code usage examples, would actually probably be the myriad of factories defined as part of WebResponse. Particularly
the error and redirect factories.
Drawing some parallels to the ever popular MVC pattern the Model doesn't really exist, View would correspond to the Twig
template which most content pages inherit from and the only controller would be the aforementioned front controller, because
there really is only one action the backend does and that is map a file (or a set of files) to a request URI. The closest thing
to a model, that being the actual content of the page, would be then be the Twig template file inheriting the base template. The
generic views for PDF's, page source, and markdown make the comparison a little more obvious.
The twist, if it can be called that, is that in this system the Twig templates itself are used as a both a content authoring
format and tool as well as the way to present the content. Resulting no hard boundaries existing between content and presentation
but rather creating a soft boundary through template inheritance. Leaving it up to the user to respect this boundary or not.
In this system the Twig templates itself are used as a both a content authoring format and tool as well as the way to present the
content. Resulting in no hard boundaries existing between content and presentation but rather creating a soft boundary, through
template inheritance, that the user can choose to ignore respect this boundary or not.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment