2026/04/29
|
Wednesday, April 29, 2026 (#119)
|
|
References |
FTM update
Current task: remediating the Element clade-family so it can be a general-purpose renderer for rich text. I specifically need something that can render to a log file as well as on screen, in the same app.
This clade-fam does try to be medium-agnostic, though it wasn't immediately clear how that could be so if it's doing its own rendering. It looks like what I did was that anything which needs to output differently depending on output-medium will use a Style object to do the rendering.
The question now is whether it's set up in a way that allows two Element objects in the same app to output to different media.
Style objects are created by looking at the class's StyleClass() value, which is a class-static function that can be set at config time.
...but in any case, it's pretty much really Style-objects doing the rendering; the only thing the Element-object handles is to spider through the tree of subordinate Elements.
The current problem is that each Style only applies to a single Element-class -- there's no way to define a Style which supplies Style-classes for every Element that an application is going to need.
The obvious solution is for each Element-class to have an associated slug (which they already do, in ClsSlug(), so that the appropriate Style-class can be pulled from a Styles-collection class. The [WFe]Config\cStyles class was an attempt at that: it provides FindStyle() (finds closest match) and FindStyleSafe() (finds exact match only). This is kind of what I had in mind, but something about it feels off...
The thing which set this exploration into motion is that I need to replicate some task-specific logging functions - a quick collection from [WFe]Sys\IO\Store\File\Log:
function LogSourceFolder(PieceIface $ofSrce); function LogSourceFile(PieceIface $ofSrce); function Write(string $s); function WriteLn(string $s); function WriteHeader();
The idea is that these functions render a particular type of information in a particular way -- which does seem compatible with the idea of a Style. My impulse, though, is to create a Styles subclade which has those methods -- but is that going to break something? Does Styles provide brain-friendly methods for accessing particular Styles?