XHP rocks so fucking hard, it isn't even funny. It is just so much better than alternatives.<p>IMHO, It is the only PHP tool I use at facebook that is better than alternatives in other languages. I'm looking at you, django templates!<p>The notation perfectly represents the objects, with no cruft associated with object oriented programming. That is really rare. You could argue that the markup syntax is cruft, but it really helps code readability to have two types of syntax, for code and for markup.<p><pre><code> $b = <span>quotes and variables</span>;
$a = <div>omg, I can't "believe" how easy these {$b} are</div>;</code></pre>
For me, XHP is far more interesting than HipHop. And I say that as someone who administers a pile of single-application CPU-bound PHP servers. This completely and forever changes the templates-vs-just-PHP debate, and I'm glad -- it's the kind of evolution PHP needs to continue to be taken seriously.
In a previous job, we used Apache::ASP, which is basically PHP-style <? ?> tags, only with Perl in the insides. We got an awful lot of mileage out of simply re-writing the default <?= ?> equivalent to automatically HTML-escape the contents, and adding a new <?! ?> type thing to pass through the inside unescaped.<p>It's less "cool" than this, certainly, but making the default reasonably safe and forcing you to ask for the dangerous level of output rather than defaulting to dangerous and having to ask for safe is a lot easier to implement.
The sentiment here seems to be overwhelmingly positive. Call me a cynic, but this reminds me of "magic_quotes" all over again: a "feature" that tries to help, but masks the fundamental problem.
<p><pre><code> That is, it is impossible to generate malformed webpages while using XHP.
</code></pre>
While the purist in me thinks this is great if everyone <i>else</i> uses it, the immense amount of productivity lost when I first started using kid templating (e.g. <a href="http://turbogears.org/about/kid.html" rel="nofollow">http://turbogears.org/about/kid.html</a> ) really burned me on this whole concept.<p>Sometimes I really do want to make a quick test page without crossing all my i's and dotting all the t's. Importing non-perfect markup from a designer is a big pain, too, in this kind of templating system.<p>And, though it's unfair to say so, some companies do well enough without 100% valid XML markup:
<a href="http://blog.errorhelp.com/2009/06/27/the-highest-traffic-site-in-the-world-doesnt-close-its-html-tags/" rel="nofollow">http://blog.errorhelp.com/2009/06/27/the-highest-traffic-sit...</a>
See also: Rasmus Lerdorf's discussion of XHP: <a href="http://toys.lerdorf.com/archives/54-A-quick-look-at-XHP.html" rel="nofollow">http://toys.lerdorf.com/archives/54-A-quick-look-at-XHP.html</a><p>"...when you combine XHP with HipHop PHP you can start to imagine that the performance penalty would be a lot less than 75% and it becomes a viable approach. Of course, this also means that if you are unable to run HipHop you probably want to think a bit and run some tests before adopting this."
Scala does basically the same thing with XML:<p><a href="http://www.scala-lang.org/node/131" rel="nofollow">http://www.scala-lang.org/node/131</a><p>...although I doubt it does escaping by default. Should be simple enough to add while you're converting the scala.xml.NodeSeq (iirc) to text.<p>For an API that required both XML and JSON output, Scala's built-in XML support had us wishing the JSON version of the API was as easy as the XML version.
BTW for those of you interested in installing on Linux, you'll need php5-dev (so on deb/ubuntu machines a quick apt-get install php5-dev solves it). Run phpize from the root, then the normal ./configure, make, make install etc...
maybe I've misunderstood, but this seems to advocate mixing inline HTML and php logic - isn't that a huge step backwards in terms of web software architecture? I thought we were all using the MVC model by now...<p>My head just hurts thinking how utterly unmaintainable all that spaghetti code must be.
Ugh, I dislike this a lot. I'm one of the guys who actually likes PHP, so this may be a bit skewed, but what's wrong with PHP's existing <i>alternate</i> syntax? Most people don't know about it, but it's clean and easy to follow:<p><pre><code> <?php if ( true === $some_value ): ?>
<div>display this div</div>
<?php else: ?>
<div>display this div instead</div>
<?php endif; ?>
</code></pre>
This way, you can keep basic logic in your templates (its inevitable and convenient), it's still PHP (there's endforeach, endfor, endwhile, etc.), and this method of templating is very clean.<p>You can now have a class that sets variables through __set(), loads up a .phtml file, starts output buffering, renders the file with those variables, and then returns it.<p>You can extend it further to automatically sanitize output variables for XSS and whatnot, cache output, etc. This way, you don't need some overly verbose system like smarty to do what PHP does already. XHP just looks like another smarty: solving a problem that I really don't think exists.<p>Edit: Ok, I probably shouldn't say I dislike this a lot, I do love seeing Facebook sticking with PHP and ultimately helping it out.
I'm using PHPTal right now to achieve more or less same effects, but it's not the easiest solution - it becomes a bit cumbersome for long fragments.<p>XHP looks very promising because it solves one of my problems with PHPTal - generating complex content in the loop (in PHPTal having multiple conditions in loop is possible, but not exactly elegant)<p>For example:<p><pre><code> <?php
$list = <ul />;
foreach ($items as $item) {
if ($item->bold) {
$list->appendChild(<li><b>{$item}</b></li>);
} else if ($item->foobar) {
$list->appendChild(<li><i>{$item}</i></li>);
} else {
$list->appendChild(<li>{$item}</li>);
}
}
?></code></pre>
Another awesome example of the lengths people will go to compensate for a lack of macros.<p>I would so much rather see
(define table (html-table (map [tr (td _)] rows)))<p>then<p>$table = <table>;
foreach($rows as $row) {
$table->appendChild(<tr><td>{$row}</td></tr>); (assuming this is even possible?)
}
Sure, let's take two clusterfucks, php and xml, and smash them together! Great idea!<p>(Actually, this looks rather handy.. but there is a certain amount of initial WTF.)
very, very cool. i can't wait to dig into this more... it looks like even the basic examples are cool, but there's lots of stuff under the hood waiting to be discovered.
seems to me that if they went to the trouble to make it understand xml syntax and error out on invalid code, they should have just made it auto-close tags. on pages where there are heavily nested divs and other things, auto-closing the tags would make the code smaller while still generating valid xhtml and not bothering the developer with such trivial things.<p><pre><code> echo <div><strong><em>blah;</code></pre>
looks like E4X, which security is a problem<p><a href="http://sla.ckers.org/forum/read.php?2,20408" rel="nofollow">http://sla.ckers.org/forum/read.php?2,20408</a><p>Any code mix operation & data is dangerous. That's all how overflow exp, injection and XSS works