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

From Woozle Writes Code
< Ferreteria‎ | v0.5‎ | layout
Jump to navigation Jump to search
m (Woozle moved page Ferreteria/v0.5/layout to Ferreteria/v0.5/layout/event: most of this page is actually about the event subsystem)
No edit summary
Line 1: Line 1:
{{fmt/title|Ferreteria: '''layout''' system}}
{{fmt/title|Ferreteria: '''[[../|layout]]''' system: '''event''' subsystem}}
==About==
==About==
The '''layout''' system is basically a {{l/wp|Document Object Model}}. It provides classes to encapsulate the rendering of serial-text output, working from the most general output concepts down to smaller layout components (e.g. HTML tag-types and specific tags within the document). 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:
The '''event''' objects allow element objects in a [[../|layout]] element tree to coordinate their actions. Each event object corresponds to a particular event; an event is triggered in an object by calling {{l/ver/meth|OnEvent}} with an event-object of the appropriate class. Core events are triggered in this order:
: '''1.''' {{l/ver/class|cEventNodeBuild}}: create any subsidiary nodes which might themselves need to receive events
: '''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)
: '''2.''' {{l/ver/class|cEventNodeFigure}}: do any calculations involving other nodes (which will have been created by this point)
Line 9: Line 9:
: '''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).
: '''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 core event objects are defined in {{l/ferreteria/code|layout/elem/event.php}}.
==Methods==
==Methods==
===Events: general===
===Events: general===
* {{l/ver/meth|layout|ShouldDoTwigs}}: <syntaxhighlight lang=php inline>protected function ShouldDoTwigs() : bool</syntaxhighlight>
* {{l/ver/meth|layout/event|ShouldDoTwigs}}: <syntaxhighlight lang=php inline>protected function ShouldDoTwigs() : bool</syntaxhighlight>
** '''Action''': Determine whether events (including rendering) should be passed down to twigs. This typically returns a flag that is set during the calculations event.
** '''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===
===Events: rendering===
* {{l/ver/meth|layout|OnRender}}: <syntaxhighlight lang=php inline>public function OnRender(cEventNodeRender $oe) : void</syntaxhighlight>
* {{l/ver/meth|layout/event|OnRender}}: <syntaxhighlight lang=php inline>public function OnRender(cEventNodeRender $oe) : void</syntaxhighlight>
** This is the optional dispatch method which the rendering event looks for. If present, it is called.
** This is the optional dispatch method which the rendering event looks for. If present, it is called.
* {{l/ver/meth|layout|RenderOutput}}: <syntaxhighlight lang=php inline>public    function RenderOutput() : string</syntaxhighlight>
* {{l/ver/meth|layout/event|RenderOutput}}: <syntaxhighlight lang=php inline>public    function RenderOutput() : string</syntaxhighlight>
** '''Action''': Assemble the entirety of the object's output, including any twigs.
** '''Action''': Assemble the entirety of the object's output, including any twigs.
* {{l/ver/meth|layout|RenderValue}}: <syntaxhighlight lang=php inline>protected function RenderValue()  : string</syntaxhighlight>
* {{l/ver/meth|layout/event|RenderValue}}: <syntaxhighlight lang=php inline>protected function RenderValue()  : string</syntaxhighlight>
** '''Action''': Assemble the object's own output (separate from twig outputs).
** '''Action''': Assemble the object's own output (separate from twig outputs).
* {{l/ver/meth|layout|RenderBranch}}: <syntaxhighlight lang=php inline>protected function RenderBranch() : string</syntaxhighlight>:
* {{l/ver/meth|layout/event|RenderBranch}}: <syntaxhighlight lang=php inline>protected function RenderBranch() : string</syntaxhighlight>:
** '''Action''': Assemble the twig outputs, applying any whole-list formatting (e.g. {{xml/tag|ul}}) or conditionals.
** '''Action''': Assemble the twig outputs, applying any whole-list formatting (e.g. {{xml/tag|ul}}) or conditionals.
* {{l/ver/meth|layout|RenderTwigs}}: <syntaxhighlight lang=php inline>protected function RenderTwigs()  : string</syntaxhighlight>
* {{l/ver/meth|layout/event|RenderTwigs}}: <syntaxhighlight lang=php inline>protected function RenderTwigs()  : string</syntaxhighlight>
** '''Action''': Assemble the basic twig outputs, applying any list-item formatting (e.g. {{xml/tag|li}}.
** '''Action''': Assemble the basic twig outputs, applying any list-item formatting (e.g. {{xml/tag|li}}.



Revision as of 18:50, 15 July 2022

Ferreteria: layout system: event subsystem

About

The event objects allow element objects in a layout element tree to coordinate their actions. Each event object corresponds to a particular event; an event is triggered in an object by calling [[Ferreteria/v0.5/onevent/{{{2}}}|{{{2}}}]]() with an event-object of the appropriate class. Core events 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 core event objects are defined in layout/elem/event.php.

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.