Ferreteria/v0.5/layout/event: Difference between revisions
< Ferreteria | v0.5 | layout
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
{{fmt/title|Ferreteria: '''layout''' system}} | |||
==About== | ==About== | ||
The '''layout''' system provides classes to encapsulate the rendering of serial-text output, working from the most general output concepts down to specific HTML tags. It should be adaptable to other forms of markup. | The '''layout''' system provides classes to encapsulate the rendering of serial-text output, working from the most general output concepts down to specific HTML tags. It should be adaptable to other forms of markup. It includes a small set of '''event''' objects to allow objects in the tree to coordinate their actions, which are triggered in this order: | ||
: '''1.''' {{l/ver/class|cEventNodeBuild}}: create any subsidiary nodes which might themselves need to receive events | |||
: '''2.''' {{l/ver/class|cEventNodeFigure}}: do any calculations involving other nodes (which will have been created by this point) | |||
:* This allows, for example, the number of visible twigs to be calculated before rendering. Some elements may only display themselves if they have at least one visible twig -- or may display differently if they don't. | |||
:** ...although that kind of process could probably be done without an event-system. One that can't, however, is where one element needs to access another one that is outside of its branch, to read or write data. There needs to be a means of ensuring that all required nodes will have been created by a certain point, and the layout system's event-subsystem is what does that. | |||
:** The event-subsystem also provides an unambiguous waystation for ensuring that those calculations (which may be relatively expensive) are done exactly once. | |||
: '''3.''' {{l/ver/class|cEventNodeRender}}: assemble the string representing the markup for the object's appearance within the output (typically the screen, but in theory could also be a document or even audio markup of some kind). | |||
The basic layout classes use the <code>ferret\{{l/ver/class|layout}}</code> namespace. | The basic layout classes use the <code>ferret\{{l/ver/class|layout}}</code> namespace. |
Revision as of 15:09, 15 July 2022
Ferreteria: layout system
|
About
The layout system provides classes to encapsulate the rendering of serial-text output, working from the most general output concepts down to specific HTML tags. It should be adaptable to other forms of markup. It includes a small set of event objects to allow objects in the tree to coordinate their actions, which are triggered in this order:
- 1. cEventNodeBuild: create any subsidiary nodes which might themselves need to receive events
- 2. cEventNodeFigure: do any calculations involving other nodes (which will have been created by this point)
- This allows, for example, the number of visible twigs to be calculated before rendering. Some elements may only display themselves if they have at least one visible twig -- or may display differently if they don't.
- ...although that kind of process could probably be done without an event-system. One that can't, however, is where one element needs to access another one that is outside of its branch, to read or write data. There needs to be a means of ensuring that all required nodes will have been created by a certain point, and the layout system's event-subsystem is what does that.
- The event-subsystem also provides an unambiguous waystation for ensuring that those calculations (which may be relatively expensive) are done exactly once.
- This allows, for example, the number of visible twigs to be calculated before rendering. Some elements may only display themselves if they have at least one visible twig -- or may display differently if they don't.
- 3. cEventNodeRender: assemble the string representing the markup for the object's appearance within the output (typically the screen, but in theory could also be a document or even audio markup of some kind).
The basic layout classes use the ferret\layout
namespace.
Methods
Events: general
- ShouldDoTwigs():
protected function ShouldDoTwigs() : bool
- Action: Determine whether events (including rendering) should be passed down to twigs. This typically returns a flag that is set during the calculations event.
Events: rendering
- OnRender():
public function OnRender(cEventNodeRender $oe) : void
- This is the optional dispatch method which the rendering event looks for. If present, it is called.
- RenderOutput():
public function RenderOutput() : string
- Action: Assemble the entirety of the object's output, including any twigs.
- RenderValue():
protected function RenderValue() : string
- Action: Assemble the object's own output (separate from twig outputs).
- RenderBranch():
protected function RenderBranch() : string
:- Action: Assemble the twig outputs, applying any whole-list formatting (e.g. <ul>) or conditionals.
- RenderTwigs():
protected function RenderTwigs() : string
- Action: Assemble the basic twig outputs, applying any list-item formatting (e.g. <li>.
The canonical/typical method tree for rendering:
- OnRender() calls:
- RenderOutput() calls:
- RenderValue()
- RenderBranch()
- if ShouldDoTwigs(), calls RenderTwigs()
- RenderOutput() calls:
This tree can be overridden at any point, but generally it's best to do so at the lowest level in order to cause the least disruption to offspring classes.