Diff between XC and XCL(X2): Render Sequence

Some documents explain about Generic Render Sequence. You may see Wiki, PDF, samples and video. This entry explains difference between XC and X2 at rendering. It shouldn't contain this to "official" Wiki now, because XOOPS Cube has to be explained without XCL and X2. (In the future, I will merge this to other Wiki documents)

Look at the following:



This is a theme format of XOOPS2 that consists of five place holders for block array and one place holder for a module. After those six place holders are rendered, the theme becomes renderable with quoting results of those place holders. XOOPS2 knows fix place holders, so it's difficult to extend. We, users assign blocks to five place holders in the control panel:



In XOOPS Cube, CMS shouldn't have relations to specific theme format directly. This is what many users have wished.

XOOPS Cube has flexiblity not the fixed format. But, how to implement that? Generic Render Sequence uses Sequence-ID, instead of fixed columns --- "left column", "right column" and so on.

It's important to understand Sequence-ID.

Normally, rendering execution sequence is different from program execution sequence. For example, theme is used by CMS core executed firstly, but has to be rendered lastly. Sequence-ID is the mechanism that separates rendering execution sequence from execution sequence.





In next XOOPS Cube, each program (Task) can not render directly and has to use Render-Operation including Sequence-ID.

The Collector of the root collects Render-Operation by taking a tour of the task list. After then, the collector sorts operations in order and begin rendering. In this time, later rendering can quote results of previous rendering. By this mechanism, themes quote a result of each place holder:



Of course, this basic mechanism is usable for any compositions.

Check again. The collector is an empty at the beginning:



If the collector collects operations simply, the group of operations will be in out-order like the following:



But, the collector collects operations with sorting. So operations will be in order lastly:



Then, the core executes rendering in order with each render system specified by each operation. Because "later rendering can quote results of previous rendering", lastly the theme will be rendered completely:



Incidentally, the theme operation is tied up with the special render-target that takes a role of the screen buffer. That is the reason that result of the final output is displayed to browser.

But, this mechanism is useful for programers but has to be hidden for end-users. Even if this mechanism is powerful for purpose of XOOPS Cube, CMS (BASE) has to provide control panel for users to assign contents to place holders, like XCL and X2. By reading Manifesto, CMS (BASE) gets a count of place holders of the theme and a kind of those and reflects those to the control panel:



I think that place holder informations are written on [Theme] chunk. But, Manifesto is extendable and contains various informations, so [BASE Name] chunk may contain the specific information for the Base.

BTW, render-operations can be tagged by programs. Later rendering can quote results of previous rendering by also the tag. It's usuful for bread crumbs list and banners.


Generic Render Sequence is fixed pipeline of the core and not exchangable for BASEs. Decided rendering-spec makes it easy to make programs and share those, because rendering-logic of all BASEs but Legacy is unified. Meanwhile, Generic Render Sequence is very flexible, so you may really do many things after understanding the mechanism completely.