Looks like that wasn't my last Shy Says post. This is a real-time progress update for some unexpected FSTDT code changes. This one truly warrants discussing, and so does the template system in general. Will hopefully do later.

GOAL: Invoke the template engine on the Page.PreRender and Page.Render events and do just-in-time template interpretation. That way, I can insert template fragments in Response.Output.Write() calls for processing just before page rendering, i.e. the complete opposite of what it usually does: 'compiling' and caching its output and inserting it into a dummy control on PreInit so it will be available for rendering later in the lifecycle.

REVISED GOAL: Make a reusable solution to a one-time problem. Take a collection of tasks that plenty of other software, frameworks, etc. already exist to do, and do those tasks together, combining them in a useful and original way that the other existing stuff doesn't.

DONE: Preliminary adjustments to /Ysml/Ysml.vb, /Ysml/InlineCode.vb.
DONE: Created /Ysml/JitInterpreter.vb skeleton.
FUCK: Don't quite understand the ASP.NET page lifecycle as well as I thought. But does anyone truly completely understand this complex overwrought mess? Doesn't mean I can't do what I wanted, just that I'm going to need to go about it a little differently.
IN CONTINUING PROGRESS: Researching lifecycle wharrgarbl.

FACT: This template engine was not intended for use with WebForms, and one of its primary purposes is actually to re-implement equivalents of WebForms' useful parts and improve upon them for when I don't have WebForms anymore. That obviously means there are already much easier and better ways that exist to accomplish much of what I'm doing with the template engine in the current code. It also means making it work with WebForms is a PITA. However, I won't have WebForms anymore in the 'rewrite,' so I'm sort of pre-implementing and testing it in advance.

DONE: Reworking Lexer.vb.
TEST: The parts not specific to working together with ASP.NET successfully work with FrankenLanguage and compile into JS without an issue.

FACT: The way I am doing this and going about making the new version of FSTDT (i.e. coding almost everything — like, literally, almost everything — yourself right down to a programming language) is not a practical or even remotely sane way to do a web development project. Only do it if you're like me and want to exercise and improve your programming skills and knowledge (and hopefully — if you're really lucky — unwittingly take a few unusual or new approaches to doing something that you'll want to share because other people like it and want to use it too).

ABANDONED: Automagical approach to this problem. Plan B: Make a Response.Output.Write() wrapper that takes template code as an argument, generates the appropriate output, and passes it to Response.Output.Write(). Still, I learnt from this that just getting that much to work with the template engine is more feasible and less work than I originally thought. Even better: I see the solution I devised as potentially very useful for more than just the one-time problem it was intended to fix. Using XHR requests and responses to dynamically generate, parse, and modify templated content, much?? Aha moments like this are why I decided to take the batshit-insane route of making much as I could of the new version of FSTDT from scratch.

UNDONE: Abandoned changes
DONE: ParseToOutput()
DONE: Numerous client-side YsElement constructors
DONE: General round-o-testing
DONE: Targeted testing 1: XHR Request -> Dynamic Templating -> XHR Response

IN PROGRESS: Break to work on the original task of getting SSTDT ready.