jkoudys / concrete5-xhp Goto Github PK
View Code? Open in Web Editor NEWXHP elements, so you can use Facebook's excellent XHP library to easily, and cleanly, include concrete5 data
XHP elements, so you can use Facebook's excellent XHP library to easily, and cleanly, include concrete5 data
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.
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.
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.