jkoudys
commented
10 years ago Added 31fd7ba to add a c5:html. This can be used to setup the basic contexts (e.g. the current page in your tree, as it's a bit too low-level for the HTML-loving people this project is focused on to have
Next to do is update the Page class, then see how it's called by View, to allow pages to be built as one big xhp tree.
A tough challenge will be doing 'mixed mode' for the areas. My blocks can all be XHP, but we're losing a lot of the CMS if every block must be XHP. This could be a new issue, but eventually we'll want the block controller to set some kind of ::isXhpEnabled(), so that at least on a per-template basis, say if you're getting a true xhp tree back, or to just start the output-buffer and log that block's rendering into a c5:raw.
I've been converting a medium-sized site over to concrete5-xhp, and while individual segments are properly XML-validated (ie being built as :xhp trees), ultimately they're just being echo'd out like any other olde-timey string-rendered view.
I need to find a place to start the document root, and keep adding to it as you render your views. A c5:html element would be handy for more than just validation -- while we all agree that globals are absurd (and not even allowed in strict <?hh), they have an obvious convenience in c5. We can swap out an old bad-practice (globals) for a new best-practice in xhp contexts. This way, the c5:html can set those variables in the context for everything you render in that view, e.g. $u (current user), $c (current collection), $cp (current collection permissions), etc. The end result will likely be a faster-rendering page too, if it avoids repeated instantiations of any object that requires a DB fetch.