jkoudys / concrete5-xhp Goto Github PK

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.

Here's an idea now that c5 elements can be used with Cache:

A future-feature could be something like WebSphere dynacache's cachespec.xml, but more readable and without the bloat. The xhp tree can be traversed with selectors, so you could apply caching rules based on those. This would, of course, require that you build your whole view into an XHP tree, and not have any errant 'echo' statements, but have the whole tree built under one xhp. Having a standard place for this is a definite 'nice-to-have' reason to put something like this in the c5 core.

I can't find any way to search down more than one level (e.g. the :xhp.getChildren($selector) only selects the immediate children), so there might be a bit of work to do to traverse the whole tree. I'd much rather see a feature on this come from the hack-people, since anything I'd write as an extension couldn't run half as fast, and it's self-defeating if tree-traversal is slow. You might be slowing down rendering time for a feature meant to speed up rendering time.

This repo is just leaving the c5.php for xhp as a loose file. This really should be included as its own package, so it can be distributed and installed easily.

After implementing my views up using c5 elements, I see a very powerful way to use xhp: for fragment caching. c5 comes with what I think is basically a wrapper-class in 'Cache', which can be configured underneath to use different caching implementations. This Cache can be called directly from the c5:base element, and configured with the timeout.

I'll use this as a model for other helpers, but to start the image helper could be extended. Any helper that either does an 'echo' inside of it, or returns an html string, could be extended to return xhp instead. The xhp would then get its own element inside c5.php.

e.g. in ImageHelper, define getThumbnailXhp(), then inside :c5:thubmnail::render(), call ImageHelper::getThumbnailXhp(), so as to avoid anything but the simplest logic inside the c5.php itself.

I'm sort of torn on this decision, since I can see advantages to either side. So long as c5 helpers, like the form helper, are being maintained, it makes sense to use them in the interest of DRYness. On the other side, I wan to reduce the usage of that c5:raw element down to a minimum, and that won't happen as long as I'm just dumping out raw HTML from everything.

As the form helper is rendering actual HTML elements, that logic could be re-implemented inside the render() code for the :c5 elements themselves. This could be extra handy if traversing your xhp dom later on, since form elements are one of the main things you'd want to search inside your tree for.