not obvious to control block execution (on_display/on_init)

# User problem

Currently a block works like this.
1. If there is a action.blah in the request - execute that. If its a redirect then redirect
2. else render the template
3. execute each element as its reached in the template

There are a range of issues with this
- if you want to execute code before rendering a template (such as redirect) then you have create a fake action in your request
- if you want to do some heavy calculations shared between many elements its not clear where to put that code. It's also not clear where to store the results.
- if you want to have those shared values easily accessible in the template, how do you do that? Would you have to create a new element for each value?
- if you don't want to return html but return json or a pdf, how do you do that? You can currently call a element directly but this doesn't seem to be the right level and it results in long urls. Elements normally are used to render html into a template but suddenly now they are api endpoints?
- if you want set which record is being used in the context, how do you do that?
# History
## pyramid

Handles this by making making the python callable always the first thing called. It then produces a dict and that gets passed to the a template. but alternatively you can return whatever you want.
## plone browserviews

These are classes that have an **init** method that always gets called with context and request. There is also the **call** method you can override.
## Options
## controller function

Make it such that you can have controller function that can direct or return custom content without the need of templates or elements.

```
def on_init(context):
# tuple or list lets you create a simple response
return ("text/xml","responseresponse${element1}
```

Start by reading the block execution flow and the on_init/controller entry points described in the issue. Compare the proposed return forms—template data, redirects, custom responses, and files—and clarify which behavior should be implemented before changing code. Done requires an agreed controller contract and corresponding handling for the selected response types.

Written by the indexing model from the issue text.