Ferreteria/v0.5/layout/event: Difference between revisions

From Woozle Writes Code
< 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.
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:

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.