This is the article I wanted to write ever since I started this blog. XHP is a really powerful tool, but like any tool you need to know how to use it for it to be really effective. Facebook has built a very powerful UI framework on top of XHP, but we had to change the way we think about object patterns to do it. I’ll get into that in a bit, but first I’m going to jump right into the most important feature of Facebook’s UI library: attribute forwarding.

Read more …

Last night I added data- and aria- attribute support into XHP. I baked it into :x:composable-element directly instead of relying on previous methods which only added it to :xhp:html-element. I did this for a few reasons. First, I didn’t like the idea of getAttribute() and setAttribute() not being final within :x:primitive. Secondly, if you want to build a UI framework on top of :x:element that forwards attributes, you’d need to un-final getAttribute() and setAttribute() in :x:element too, and duplicate all the logic in :xhp:html-element into your UI framework. No, I feel it’s much better to have the slightly nuanced behavior of always allowing data- and aria- attributes on XHP, even if they won’t do anything on custom :x:element extensions by default (HTML elements render them just fine).

You can download the latest source at: https://github.com/facebook/xhp.

About every six to nine months or so, an engineer at Facebook tries to add a control structure into XHP. These usually come in up to four flavors per diff: <x:if>, <x:switch>, <x:for>, and <x:foreach> (and occasionally <x:map>, which really is just a different <x:foreach>). A diff is submitted and invariably a long discussion ensues before the diff is eventually abandoned. I have to admit, it is tempting sometimes. I mean, we can keep everything in a single XHP block. How much cleaner is that?

Read more …

I was recently asked to clarify the differences between :x:element and :x:primitive, and when to use each one. It’s actually pretty simple; the basic rule of thumb is this: always use :x:element. If you’re only doing simple things in XHP you can stop reading now, but for the rest of you I’ll get into the rare instances where you might use :x:primitive.

Read more …

I just checked in an upgraded list of the default HTML classes in XHP that conform to the latest working draft of HTML5. This might cause some backwards compatibility issues, so I’ve also included a new public method available to all XHP elements called forceAttribute(). The method allows you to set attributes on an element and skip validation checks. I’ve also checked in a few fixes and changes to conform to the new strict standards of PHP 5.4. Please let me know if you find any issues.

You can download the latest XHP source here.

I want to share with you a quick XHP class you can build that will greatly abstract your image spriting. Image sprites are a great way to reduce the number of resources downloaded from your server, but they can be a hassle to maintain. If you already sprite your images then you might have a class that generates the styles for your images. Your API might look something like this:

ImageSprite::getSpriteHtml(ImageSprite::ICON_PHOTOS);

You can sprinkle those into your rendering and it’ll work just fine, but with XHP you can build a custom component that behaves more like an HTML img tag than a PHP class and generates your spriting code behind the scenes.

Read more …

XHP was built for Unix, and thus can run just fine on a Mac, but sometimes for whatever reason, XHP has a little trouble. Here are the steps to installation that seem to work if you’re getting unknown errors.

Read more …