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!
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.
$b = <span>quotes and variables</span>;
$a = <div>omg, I can't "believe" how easy these {$b} are</div>;1. How is this different from Django filters? Is it that the default is HTML escaping instead of having to specify the escaping with each template variable?
2. How does it handle different escaping contexts? For example, text in html attributes needs to be escaped differently from text in the body of the document. Text in URLs or JavaScript has to be escaped differently still, and often times you have to combine these escapings (eg. a JavaScript onClick attribute). Is XHP smart enough to recognize these different contexts and do the right thing, or do you need to fall back to some manual mechanism?
def view_foo( request ):
baz = "roger, roger"
return render_foo( baz )
def render_foo( name ):
return <html><head></head><body>hi, {name}</body></html>
I don't know well enough to answer about escaping. Check out the framework, and try it for yourself :)
If your code looks anything like that, or the examples on the Facebook page, you're doing it wrong.
I really liked what you had to say! Please let me know if you want me to remove the quotation or change the links around it. I'm jolie@readwriteweb.com.
If you want me to remove the quotation or change the links, just let me know. I'm jolie@readwriteweb.com.
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.
echo <span class="username">{$_POST['name']}</span>;
echo $_POST['name'];
If PHP gave all unsafe values the type "unsafe string" and disallowed all implicit conversion to safe types, then XHP's approach would be a welcome way of doing the right thing by default. Programmer-introduced errors like the above example would result in fatal type errors instead of exploits (presuming "echo" won't take unsafe strings and so requires a conversion function, like htmlspecialchars or the hypothetical unsafe_cast).
Anyone who's spent the 1990s coding Perl CGI will tell you just how big of a step backward this is.
That is, it is impossible to generate malformed webpages while using XHP.
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.
And, though it's unfair to say so, some companies do well enough without 100% valid XML markup: http://blog.errorhelp.com/2009/06/27/the-highest-traffic-sit...
For the rest of us, clarity and semantically correct code are much more useful.
As for semantic correctness - it's in the HTML spec, and every major modern browser handles it correctly. Sometimes I wonder if Google's the only folks who actually read the W3C specs, there's been so much cargo-cult advice passed down between web developers.
The "always close your tags" advice came from the early 2000s, when people were pushing XHTML as a way to make your HTML pages XML compliant (the big buzzword back then). It gives essentially no benefit to users, no benefit to developers, costs you bandwidth, makes your pages slower, and clutters up your markup.
"...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."
http://www.scala-lang.org/node/131
...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.
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.
Fatal error: Class 'xhp_a' not found in /home/me/public_html/test.php on line 3
<?php
$href = 'http://www.facebook.com';
echo <a href={$href}>Facebook</a>;
<?php
$href='http://www.facebook.com';
echo new xhp_a(array('href' => $href,), array('Facebook',), __FILE__, 3);
Fatal error: Class 'xhp_span' not found in ...
I get strange errors after I build and add the extension to php.ini
Benefits: I can use apt-get and have all the other conveniences of a true *nix environment. I can update and try out new software easily (I had XHP running in about 5 minutes). Also, I can create snapshots of my OS so that when my environment is just the way I like it, I can always revert right back to it.
I interact with certain paths on my virtual linux filesystem just as though they were local (like my ~/Sites dir) and have various dev domains in my /etc/hosts file pointing to the VM (which has it's own internal ip).
Cons: It's a standalone VM so it consumes a consistent 250mb of memory. Never really looked at what mysql/apache were doing on my Mac previously (I would assume far less) but I haven't really ran into an issue where the VM is a big issue yet. The convenience far outweighs the chuck of memory it eats up :)
I haven't had a single configuration problem yet ;) For developers the popular phrase is reversed, Debian "just works" and OS X is a pain in my ass.
My head just hurts thinking how utterly unmaintainable all that spaghetti code must be.
Does this offer any benefits to XML comprehension beyond syntactical sugar to allow echo avoid the use of quotes and to remove the god-awful <?php ?> syntax (which puts it at par, at the very best, in my opinion)? Does it handle XML syntax errors gracefully? Can you do native transformations on bound variables, for example, or do any more sophisticated XML DOM-ish tag functions? The post doesn't mention anything about any of these issues, which is where the real advantage would lie. If any of that were possible, you could put the browser DOM (and validation) one step closer to the application logic. As far as I can tell this just attempts to ambiguate the VC in MVC, where Django tries to replace V with T (template).
As far as I'm concerned this only increases the squinty-eyed "WTF" factor between PHP and other languages.
<?php if ( true === $some_value ): ?>
<div>display this div</div>
<?php else: ?>
<div>display this div instead</div>
<?php endif; ?>
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.
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.
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 think I might like the more concise, readable syntax that XHP offers for interpolating {$variables} (and any PHP code for that matter).
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)
For example:
<?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>);
}
}
?>I would so much rather see (define table (html-table (map [tr (td _)] rows)))
then
$table = <table>; foreach($rows as $row) { $table->appendChild(<tr><td>{$row}</td></tr>); (assuming this is even possible?) }
I think one of lisp's adoption problems is that it makes things that are just simply amazing become commonplace.
(Actually, this looks rather handy.. but there is a certain amount of initial WTF.)
echo <div><strong><em>blah;http://sla.ckers.org/forum/read.php?2,20408
Any code mix operation & data is dangerous. That's all how overflow exp, injection and XSS works