0000489: Progressive Tempcode evaluation - ocPortal feature tracker

feature request / bug tracker

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0000489

ocPortal

core

public

2012-05-21 16:40

2012-07-02 14:41

Reporter

Chris Graham

Assigned To

Chris Graham

Priority

normal

Severity

feature

Reproducibility

N/A

Status

closed

Resolution

won't fix

Platform

OS Version

Product Version

Target Version

Fixed in Version

Summary

0000489: Progressive Tempcode evaluation

Description

If Tempcode isn't in some kind of diagnostic mode (showing the Tempcode tree or whatever), then have a new paradigm for Tempcode evaluation in the API. Use this paradigm primarily for outputting the header/panels/blocks before a page finishes executing.

Currently we build up a complete Tempcode tree, and then evaluate it. If we drop the idea of preprocessing (discussed in another issue) we no longer need to do this).

Instead of build up the HEADER/GLOBAL/FOOTER templates last, do it first. But obviously the 'MIDDLE' parameter would be unbound at this point, as execution has not finished.

We initially call do_template without passing 'MIDDLE'.

Then we have a new method on the Tempcode object we call instead of evaluate_echo()... evaluate_echo__until_stalled().
This method iterates over the Tempcode seq_parts until it gets to one that has not been bound. It then quits out, storing where it was.
We can then call evaluate_echo__until_stalled(true) again when we know 'MIDDLE' is computed, and it would finish the output [true indicates it now should expect all parameters to be known as we're finishing off -- and give errors if ones missing].

This allows data transfer to be parallel to server-side execution, and reduced memory consumption (theoretically).

We can go further and allow output of the MIDDLE component iteratively (e.g. post-by-post for a forum topic). We'd check a global state that asks if we're currently outputting and if we are we call evaluate_echo__until_stalled() on the screen template we're currently building up (like 'GLOBAL' this would need preinitialising with some missing variables calculated later). The pattern in this case would be a bit more complex as we'd be splitting a variable into multiple parts. The code would look something like...

$tpl=do_template('OCF_TOPIC_SCREEN',array('TITLE'=>$title,'POSTS'=>NULL));
if (is_outputting_already()) $tpl->evaluate_echo__until_stalled();
foreach ($posts as $post)
{
    $_post=render_post($post);
    $tpl->extend_binding('MIDDLE',$_post);
    if (is_outputting_already()) $tpl->evaluate_echo__until_stalled('MIDDLE'); // Tells it 'MIDDLE' is not done yet so to output what it has but not advance the iterator yet
}
$tpl->mark_fully_bound('MIDDLE');
if (is_outputting_already()) $tpl->evaluate_echo__until_stalled(true);
return $tpl; // When attach'd it would have to know that output had happened, stored as a note inside $tpl -- so when evaluate_echo__until_stalled() was called on the global template it would skip over this value for MIDDLE knowing it was done already

Tags

Type: Performance

Time estimation (hours)

Attached Files

Relationships

Notes
(0000509) Chris Graham (administrator) 2012-05-21 16:44	Also the get_screen_title() function would need to call evaluate_echo__until_stalled() on the header/global/footer output because it would have stalled on the missing $HEADER_TEXT before outputting anything at all really (well it should stall -- we'd need to make the code smart enough to recognise if the data the $HEADER_TEXT symbol needs is actually missing at that point).

(0000666) Chris Graham (administrator) 2012-06-17 18:48	One issue that would come up is errors. If we get a fatal error but have already started, we're in trouble. I propose we detect this in our error API and have a mechanism to insert a meta-refresh header, that takes the user to a new error screen -- that is arguably valid XHTML5, as we are allowed in-stream metas now, and if we don't finish the XHTML stream, it doesn't matter, we're dumping it and we have done a valid parse to the point of it being dumped.

(0000735) Chris Graham (administrator) 2012-07-02 14:41	Moving this stuff elsewhere.

Issue History
Date Modified	Username	Field	Change
2012-05-21 16:40	Chris Graham	New Issue
2012-05-21 16:42	Chris Graham	Description Updated	View Revisions
2012-05-21 16:44	Chris Graham	Note Added: 0000509
2012-05-21 17:08	Chris Graham	Tag Attached: Type: Performance
2012-06-17 18:48	Chris Graham	Note Added: 0000666
2012-07-02 14:40	Chris Graham	Issue Monitored: Chris Graham
2012-07-02 14:41	Chris Graham	Note Added: 0000735
2012-07-02 14:41	Chris Graham	Status	new => closed
2012-07-02 14:41	Chris Graham	Assigned To	=> Chris Graham
2012-07-02 14:41	Chris Graham	Resolution	open => won't fix