Ticket #287 (closed task: fixed)

Opened 2 years ago

Last modified 17 months ago

Get rid of decorators and slots and invent something biblically good to replace them

Reported by: david Owned by: david
Priority: normal Milestone: 0.11
Component: _OTHER_ Version:
Severity: normal Keywords:
Cc: Patch attached:

Description

Just a reminder ticket for the big things we want to change for 2.0

Attachments

Change History

Changed 23 months ago by david

(In [1448]) work in progress: new execution flow, action stack is gone, decoration doesn't require special abilities of the renderer anymore, but still needs further abstraction. decorators in decorators (for slots) should work now, and slots are available in the main content template. also, caching for execution filter is in place, albeit not enabled/complete yet. refs #373, #377, #287 and #290

Changed 23 months ago by david

  • status changed from new to assigned

Changed 23 months ago by david

  • milestone changed from 2.0 to 0.11

Here's ze plan:

  • Decorators get thrown out
  • In a view, people can now set any number of templates which are rendered after another, similar to an onion or russian doll
  • Each of these individual templates can have slots
    • Which means people can use one template, without an outer "decorator", but still use "slots"
  • The individual templates may use different renderer implementations, examples:
    • The outermost template is smarty, while inner stuff is done in PHP for prototyping, and ported to smarty later by a designer.
    • The content is SVG, which is rendered via XSL, then embedded with XHTML using PHP, and decorated normally with Smarty
  • The slots can use different content types, too, examples:
    • One of the "slots" run produces JSON which is used in a <script type="text/javascript"> block in the <head> of the page
  • Each template "layer" can have an identifier, which may be used to cache fragments of the page (only the inner template, not the outer "decorator" with the slots)
  • Maybe even some more control over how responses of slots are merged together etc?

This should be just as powerful as action chains, but with the cacheability and convenience of the old decorator implementation.

To have the same behavior as before, with decorators, one would do (pseudo code, not yet sure about the implementation): 

$this->addTemplate('IndexSuccess');
$decorator = $this->addTemplate('Master');
$decorator->setSlot('navigation', 'Default', 'NavigationWidget');

Changed 22 months ago by david

(In [1548]) fire eagle number awesome: new layouting system. look at the sample app to get to know it a bit. of course, you don't have to use preconfigured layouts, and of course you can alter a loaded layout at runtime, e.g. prepend another layer, move stuff around, etc etc. now also fully stream-based templating, so you can load template from ftp, http, memory, whatever you like, as long as you have a stream wrapper for it (which you can write yourself) - or you just implement your own layer class that loads templates from database and caches to disk etc. filter and context support will follow in 1.0. renderers are per layer now, too, and more stuff I can't remember. refs #287

Changed 22 months ago by david

(In [1550]) removed extract_slots, removed colision detection, that all makes things a lot simpler in the renderers (and likely way, way faster). smarty and phptal renderers should now work again, too. refs #287

Changed 22 months ago by david

(In [1553]) added ability to configure slots in layouts, too, and fixed some bugs and typos discovered in the process. refs #287

Changed 22 months ago by david

  • status changed from assigned to closed
  • resolution set to fixed

(In [1568]) merging in changes from david-execution flow branch. contains remodeled execution flow system, totally new templating stuff, request data holders including painless header and file handling, new redirect system, and improved file validators. closes #373, #389, #184, #287, #377, #391

Changed 22 months ago by david

(In [1609]) added 'more'-assigns for the template that are resolved at rendering time, these are 'container', 'view' and 'inner' (for the previous, wrapped layer's output). can be changed via 'assigns' parameter for the renderer, of course. container response gets now cleared prior to view execution. refs #287 and #373

Add/Change #287 (Get rid of decorators and slots and invent something biblically good to replace them)

Author



Action
as closed
Next status will be 'reopened'
 
Note: See TracTickets for help on using tickets.