# Stefan Parker Insights from a Facebook engineer on the back of a horse. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Converting a Project to XHP DevFeed: [Converting a Project to XHP]() Original publisher: [Read original article]() Author: Codebeforethehorse Published: 2014-05-30T16:15:00Z Content type: tutorial Language: en Sources: [Stefan Parker]() Topics: [Refactoring](), [XSS](), [Code](), [HTML]() Tags: [code](), [html](), [refactoring](), [xhp](), [xss]() ### AI overview This tutorial explains how to migrate a project from HTML strings to XHP by wrapping selected raw HTML in marker objects and modifying XHP's child rendering and validation internals. It also argues against using automatic regex conversion because it could perpetuate HTML-string usage. ### Source excerpt Unless you're starting from scratch, using XHP is most likely going to take some refactoring of old HTML-as-string code. The problem is that because of XHP's auto-escaping to prevent XSS holes, you can't include strings of HTML as children into XHP elements. Fortunately there's something you can do to allow XHP to ignore certain strings and return them directly as HTML. This is essentially what Facebook had to do when we started converting our entire codebase into XHP in 2009. First off, you'll need a marker for strings that should be ignored by XHP. The best way to do this is to create an object that holds the strings and you can easily do instanceof checks on it. Let's call this object HTML (protip: objects and classes exist in different contexts, so they can have the same name without problem). class HTML { private $htmlString; public function __construct($htmlString) { $this->htmlString = $htmlString; } public function getRawHTML() { return $this->htmlString; } } function HTML($htmlString) { return new HTML($htmlString); } Now we'll need to adjust XHP's internals in two places to check for the existence of HTML objects: when rendering children and when validating children. The first location will be inside :xhp:renderChild(). The method looks like this: final protected static function renderChild($child) { if ($child instanceof :xhp) { return $child->__toString(); } else if (is_array($child)) { throw new XHPRenderArrayException('Can not render array!'); } else { return htmlspecialchars((string)$child); } } You'll need to add a check into this block for your HTML instances. Best place is right after your check for :xhp, since that should be the most common. final protected static function renderChild($child) { if ($child instanceof :xhp) { return $child->__toString(); } else if ($child instanceof HTML) { return $child->getRawHTML(); } else if (is_array($child)) { throw new XHPRenderArrayException('Can not render array!'); } else { return htmlspecialchars((string) ## Contexts Added to XHP DevFeed: [Contexts Added to XHP]() Original publisher: [Read original article]() Author: Codebeforethehorse Published: 2014-04-15T01:25:00Z Content type: tutorial Language: en Sources: [Stefan Parker]() Topics: [context](), [data]() Tags: [component](), [context](), [examples](), [feature](), [implementation](), [xhp]() ### AI overview The article introduces a new XHP feature for passing context--map-like key/value data--from a parent element through a rendered component hierarchy. It explains how this can avoid manually forwarding attributes through intermediate components, using a blog comments example with different behavior for permalink and feed views. It also notes that context becomes available during rendering and supports defaults and retrieving all available contexts. ### Source excerpt I just added a new feature to XHP to allow you pass data automatically through the hierarchy of an XHP tree being rendered. That's kind of a mouthful, but what it means is that you can set context (which is just a map of key/value pairs) on some parent element, and that context will be available on all rendered elements and their children. Let's take a look at some examples to better understand where this would be useful. Let's say you have a comment section on your blog. When you are on a permalink you want the comments to be expanded, but on the feed view you only want the counts exposed with an input field. You could create an attribute to pass your view into the component and it would work just fine. The problem lies in how you're going to get that attribute all the way into your comment component. Your comments might reside inside a feedback form (which also holds likes and shares), which itself resides in a blog post, which might reside within a blog post list, which resides within your main column content. Only your comment component needs that "page type" attribute, but now you're going to have to add it to each one of these parent components to pass it down the tree. Bummer. Context to the rescue! Think of XHP contexts as arbitrary attributes that get automatically forwarded to rendered components and children. You can set a value at the page-level (or any root element for that matter) and every element inside that tree will have access to the value. Let's look at an implementation of our blog comments example above. class :blog:comments extends :x:element { attribute array comments = array(); protected function render() { $comments = $this->getAttribute('comments'); $commentsXHP = ; if ($this->getContext('pagetype') == 'permalink') { foreach ($comments as $comment) { $commentsXHP->appendChild( ); } } else { $count = count($comments); $commentsXHP->appendChild( $count.' comment'.($count != 1 ? 's ## Rendering ONLY Children in XHP DevFeed: [Rendering ONLY Children in XHP]() Original publisher: [Read original article]() Author: Codebeforethehorse Published: 2014-03-27T19:54:00Z Content type: tutorial Language: en Sources: [Stefan Parker]() Topics: [ui](), [selectors](), [jQuery](), [Web Development]() Tags: [selectors](), [ui](), [xhp]() ### AI overview This tutorial explains how to use XHP rendering priority and :x:primitive to render only the augmented children of an element. It demonstrates the technique with Facebook news feed lists that add class names to children before appending them through an AJAX request. ### Source excerpt My last post, Rendering NULL in XHP, surprised a bunch of people by the use of extending :x:primitive to handle children rendering before the parent's rendering. So I thought I'd quickly discuss another useful trick you can do by extending :x:primitive, this one deals with getting just the children from elements that alter their children before rendering. There are a few cases where you want this to happen. For instance, Facebook has an element , which allows engineers to make lists with pre-defined spacing and border colors. The news feed is one of these lists. The problem we had was that we needed to add class names to its children because we couldn't use CSS selectors to target direct children (specifically, the > selector, which IE6 didn't support). So we had to add class names like .uiListSmallVerticalPadding to every child element. Keeping this logic inside meant we only needed to specify the spacing once and it would remain uniform over the whole list. This works fine until we need to append more children through an AJAX request. When we load more news feed stories we need to create another , render it, but then remove the root element and only append its children to the existing news feed. :x:primitive to the rescue! We can use the rendering priority of :x:primitive to create an element that will let its child render first (adding class names to its children) and then remove the root. class :render-children extends :x:primitive { children (:xhp); protected function stringify() { $xhp = {$this->getFirstChild()->getChildren()} ; return :xhp::renderChild($xhp); } } Now we're left with the augmented children to append to the existing list. Easy peasy. ## Rendering as NULL in XHP DevFeed: [Rendering as NULL in XHP]() Original publisher: [Read original article]() Author: Codebeforethehorse Published: 2014-03-21T00:17:00Z Content type: tutorial Language: en Sources: [Stefan Parker]() Topics: [Code](), [Security]() Tags: [blog-post](), [code](), [security](), [xhp]() ### AI overview This article examines returning null from XHP elements, especially for conditionally rendered content. It discusses the trade-offs, explains how moving checks outside the element can create unsafe code paths, and considers CSS-based alternatives and their limitations. ### Source excerpt There are some at Facebook who have argued against returning null when rendering an XHP element. In fact, it's actually against Facebook's standards now. Personally, I prefer to structure my code to return null in XHP, but there definitely are pros and cons. I'll cover the situations in which you might want to return null and what the alternatives could be, and then you can decide for yourself. First, let me clarify that when I say returning null, I actually mean returning an empty element from your :x:element-extended class - basically meaning you don't want it to render into anything. So when would you return null from an XHP element? Well, often times it is when the element should only conditionally exist. Let's contrive a simple example. class :post:edit-link extends :x:element { attribute Post post @require; protected function render() { $post = $this->getAttribute('post'); if ($post->author != get_loggedin_user() && !user_is_admin()) { return ; } return id}/edit"}>Edit; } } class :blog:post extends :x:element { attribute Post post @required; protected function render() { $post = $this->getAttribute('post'); return
{$post->title}
{$post->content}
· ·
; } } So in this scenario, we have which will conditionally return a link to edit the post if you are the author. However, if you are not the author you'll see a floating · underneath each blog post. We cannot tell without rendering if it will return content or not, so there's no way to conditionally control the last · from inside :blog:post::render(). This is the primary reason some people feel rendering null in XHP is bad practice. To remove the null rendering from we'll have to take that check and put it somewhere e ## When and How to Use XHP Categories DevFeed: [When and How to Use XHP Categories]() Original publisher: [Read original article]() Author: Codebeforethehorse Published: 2013-10-29T21:23:00Z Content type: tutorial Language: en Sources: [Stefan Parker]() Topics: [html elements](), [HTML](), [HTML5](), [ui](), [Web Development]() Tags: [how-to](), [html-elements](), [html5](), [opinion](), [ui](), [xhp]() ### AI overview The article explains how XHP validates child elements in two passes: custom components are rendered into HTML primitives before the resulting HTML tree is validated. It recommends grouping custom XHP elements by the type of root node returned from render(), allowing related abstractions to remain composable while preserving child validation. ### Source excerpt I remember when we first added the children keyword to XHP. We had the problem that validating them was really cumbersome. Nearly every element was valid inside a
but not all (for instance ). Listing out every valid child wasn't very elegant and certainly would cause problems for custom XHP components. Fortunately, the HTML spec categorized elements just for this purpose. Grouping elements into "block" or "inline" categories made validation far simpler. But if you've used XHP you might be wondering, "Why have I never needed to define my elements as inline or block before?" Well, the answer lies in how XHP renders an element tree. First it will render down all your custom elements into their eventual HTML primitives, then it will render the entire HTML primitive tree into a text string. The key here is that there are actually two passes, meaning XHP validates children in two sets: your elements first and then core HTML elements second. When you put a custom component inside of a element, you don't need to give it a category of %phrase (the HTML5 equivalent of %inline). When XHP renders the tree it will wait on validating the children of the root until its children are HTML elements. class :ui:hello-world extends :x:element { protected function render() { return Hello World!; } } $root = ; So when you render $root, XHP will first render the instance (which will produce the following node tree: Hello World!). Then it will render (and validate) the and elements. If we returned a
element from the :ui:hello-world::render method, then the validation would fail. So since we can use categories with free reign in our custom components, what pattern should we use? HTML groups elements by purpose, but it is my personal opinion that the best way to use categories is to group XHP elements by the type of their returned root node from render(). Let's look at an ex ## Building a Good UI Framework with XHP DevFeed: [Building a Good UI Framework with XHP]() Original publisher: [Read original article]() Author: Codebeforethehorse Published: 2013-06-12T23:23:00Z Content type: tutorial Language: en Sources: [Stefan Parker]() Topics: [ui](), [Framework]() Tags: [building](), [component](), [framework](), [patterns](), [ui](), [ui-framework](), [xhp]() ### AI overview The article explains how Facebook built a UI framework on XHP, focusing on attribute forwarding and composition. It describes forwarding valid attributes from custom components to their rendered nodes and recommends composing components instead of extending them further. ### Source excerpt 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. Here's the problem, when you make your own XHP component, the element you return in your render method is exactly what will be sent down the wire. That means if you want to apply IDs, classes, onclicks, or any other attributes to an individual instance, you'll have to account for that in your class and set it on the returned node. Here's what I mean by that. class :ui:div extends :x:element { attribute :div; protected function render() { $root =
; $root->setAttributes(array( 'id' => $this->getAttribute('id'), 'class' => $this->getAttribute('class'), ... ); return $root; } } That's not a good pattern, so a good UI framework should do this for you. At Facebook, we call our UI core element :ui:base, and this is how we forward attributes: First, we set :ui:base::render() to be final and instead create an abstract method compose() that all extensions will need to override. Then we can get the attributes set on the instance being rendered and compare it with the attribute declaration on the returned node from compose(). We loop through the set attributes and forward them onto returned node (if valid). So our class ends up looking something like this: abstract class :ui:base extends :x:element { abstract protected function compose(); final public function addClass($class) { $this->setAttribute( 'class', trim($this->getAttribute('class').' '.$class) ); return $this; } final protected function render() { $root = $this->compose(); if ($root === null) { return ; } if (:x:base::$ENABLE_VALIDATION) { if (!$root in ## Data- & Aria- Attribute Support Added to XHP DevFeed: [Data- & Aria- Attribute Support Added to XHP]() Original publisher: [Read original article]() Author: Codebeforethehorse Published: 2013-01-31T03:47:00Z Content type: release Language: en Sources: [Stefan Parker]() Topics: [aria](), [html elements](), [ui]() Tags: [aria](), [download](), [framework](), [html-elements](), [source](), [xhp]() ### AI overview The article announces data- and aria-attribute support in XHP. The support is implemented in :x:composable-element, allowing these attributes on XHP elements; HTML elements render them, while custom extensions do not use them by default. ### Source excerpt 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. ## Why Control Flows Should NOT Be In XHP DevFeed: [Why Control Flows Should NOT Be In XHP]() Original publisher: [Read original article]() Author: Codebeforethehorse Published: 2012-11-19T21:58:00Z Content type: opinion Language: en Sources: [Stefan Parker]() Topics: [PHP](), [Code](), [HTML]() Tags: [code](), [html](), [php](), [xhp]() ### AI overview The article argues that control-flow constructs should not be placed in XHP. It explains that conditionals instantiate both outcomes before rendering, while loops can create unnecessary wrapper objects and produce results that differ from expectations when evaluated later. XHP should remain focused on HTML rendering rather than acting as a programming language. ### Source excerpt 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: , , , and (and occasionally , which really is just a different ). 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? $panel = userIsAdmin() ? : ; $root =
{$panel}
; $root =
; So much more efficient, right? Wrong! There's a big difference between these two practices, can you think of it? Putting the conditional in XHP actually instantiates both outcomes. Because the conditions are only evaluated on render, they need to be instantiated even if they're just going to be thrown away later. Plus, it may seem readable now, but what happens with nested statements?
This is getting complicated quickly. XHP is really good at giving you an abstracted view at what the generated HTML structure will be, but this completely breaks that ability. I have to parse and separate out in my head the pieces that will be rendered. But really, you're creating tons of objects just to throw them away, that should be enough to never do this. Ok, so that eliminates and , but what about and ? They won't instantiate anything extra so we should be good, right? Well, let's take a look at an example. $list =
    ; foreach ($items as $item) { $list->appendChild(
  • {$item}
    • ); } $list =
      ) Original publisher: [Read original article]() Author: Codebeforethehorse Published: 2012-11-10T18:16:00Z Content type: tutorial Language: en Sources: [Stefan Parker]() Topics: [XSS](), [Sanitization](), [HTML](), [JSON](), [html elements](), [Ajax]() Tags: [foreach](), [function](), [html](), [html-elements](), [json](), [payload](), [protection](), [render](), [rest](), [xhp](), [xss]() ### AI overview This article explains when to use :x:element versus :x:primitive in XHP. It recommends :x:element for most cases because its render() method produces more XHP and supports recursive rendering, while :x:primitive ultimately stringifies the result. It identifies custom HTML nodes and non-HTML output such as JSON AJAX responses as the main reasons to use :x:primitive. ### Source excerpt 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. First, the main difference. :x:element implements the render() method, which returns more XHP while :x:primitive implements to stringify() method, which returns a string. When you echo XHP to the page, it recursively calls render() on itself until it returns an :x:primitive. It will continue to do this to any children of an :x:primitive as well. Once the entire tree is just :x:primitives (usually meaning just HTML nodes) it stringify()s it. So why the difference? The big reason was that we can put XSS protection in all HTML elements and so long as you just return HTML nodes you'll never have to worry about input sanitization again. There are two cases where you would want to create an :x:primitive though. The first being if you wanted to create a custom HTML node. Let's say you wanted to create a tag for your own purposes. All you would need to do is extend :xhp:html-element (which extends :x:primitive) and define its tag name. class :foo extends :xhp:html-element { protected $tagname = 'foo'; } Pretty simple. You could define custom attributes and children restrictions too if you so desired. The other reason you would extend :x:primitive is if you wanted to return something other than HTML. Consider an AJAX response that returns a JSON object. You might construct an object that behaves like this: class :ajax:response extends :x:primitive { attribute array payload; attribute array errors; protected function stringify() { $html = ''; foreach ($this->getChildren() as $child) { $html .= :x:base::renderChild($child); } $response = array( 'payload' => $this->getAttribute('payload'), 'errors' => $this->getAttribute('e ## XHP Upgraded to HTML5 DevFeed: [XHP Upgraded to HTML5]() Original publisher: [Read original article]() Author: Codebeforethehorse Published: 2012-11-09T04:30:09Z Content type: release Language: en Sources: [Stefan Parker]() Topics: [HTML5](), [PHP]() Tags: [compatibility](), [download](), [html5](), [php](), [source](), [standards](), [validation](), [xhp]() ### AI overview The article announces an update to XHP's default HTML classes to conform to the latest HTML5 working draft. It warns of possible backward-compatibility issues, adds the forceAttribute() method to bypass attribute validation, includes PHP 5.4 compatibility fixes, and links to the latest XHP source. ### Source excerpt 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. ## Image Spriting in XHP DevFeed: [Image Spriting in XHP]() Original publisher: [Read original article]() Author: Codebeforethehorse Published: 2011-10-04T15:28:00Z Content type: tutorial Language: en Sources: [Stefan Parker]() Topics: [PHP](), [Code](), [HTML](), [Web Development]() Tags: [code](), [html](), [image](), [images](), [php](), [web-development](), [xhp]() ### AI overview This tutorial shows how to build an XHP component in PHP that abstracts image spriting. The component behaves like an HTML element, maps image sources to sprite classes, and can optionally disable spriting for individual icons. ### Source excerpt 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. Consider the follow XHP element: class :ui:sprite extends :x:element { attribute :img; attribute bool usesprite = true; private static $_spriteMap = array( '/icons/apps.png' => 'appIcon', '/icons/photos.png' => 'photoIcon', '/icons/users.png' => 'userIcon', ... ); protected function render() { $img = ; $src = $this->getAttribute('src'); if ($this->getAttribute('usesprite') && isset(self::$_spriteMap[$src])) { $img->addClass($this->_spriteMap[$src]); $src = '/images/spacer.gif'; } $img->setAttribute('src', $src); return $img; } } Your CSS would then look something like this: .imageSprite { background: url('/icons/sprite.png') no-repeat; display: inline-block; height: 16px; width: 16px; } .appIcon { background-position: 0 0; } .photoIcon { background-position: 0 -16px; height: 14px; } .userIcon { background-position: 0 -30px; width: 15px; } Now you can intermix this element with your HTML and get code that looks like this: With the XHP element set up the way it is you can even add icons to your code before you get a chance to sprite them, or con ## XHP Talk at the PHP Developers Conference DevFeed: [XHP Talk at the PHP Developers Conference]() Original publisher: [Read original article]() Author: Codebeforethehorse Published: 2011-05-26T21:06:00Z Content type: article Language: en Sources: [Stefan Parker]() Topics: [PHP]() Tags: [conference](), [developers](), [dpc11](), [php](), [talk](), [xhp]() ### AI overview This post presents slides used for a talk at the annual PHP Developers Conference in Amsterdam. ### Source excerpt XHP Talk at the PHP Developers Conference: The slides I used for the annual PHP Developers Conference in Amsterdam. ## Add HTML5 Data Attribute Support to XHP DevFeed: [Add HTML5 Data Attribute Support to XHP]() Original publisher: [Read original article]() Author: Codebeforethehorse Published: 2011-04-21T01:18:00Z Content type: tutorial Language: en Sources: [Stefan Parker]() Topics: [PHP](), [HTML5 and CSS3 tricks](), [aria](), [Accessibility](), [Web Development]() Tags: [accessibility](), [aria](), [html](), [html5](), [php](), [xhp]() ### AI overview A tutorial on modifying PHP-based XHP to support HTML5 data-* and WAI-ARIA attributes. It explains how to bypass validation for these attributes, limit that behavior to HTML elements rather than custom components, and optimize the relevant attribute-access methods. ### Source excerpt UPDATE: I've added data- and aria- attribute support into XHP by default. Downloading the latest source will get you this for free. XHP runs validation checks on all attribute sets and gets, but in the emerging world of HTML5, data attributes are validation-less. With a little bit of tweaking, you can add HTML5 data attribute support to all HTML elements in XHP. In the same swing, you can add WAI-ARIA support for your accessibility users. In this post we'll dig into the php source of XHP and do a little optimizations of our own. First, you'll need to change the getAttribute() and setAttribute() functions inside :x:composable-element to account for these special attributes. The logic behind it is simple, if it's a data or aria attribute, skip the validation checks. This is how those two functions would now look: final public function setAttribute($attr, $val) { if (substr($attr, 0, 5) != 'data-' && substr($attr, 0, 5) != 'aria-') { $this->validateAttributeValue($attr, $val); } $this->attributes[$attr] = $val; return $this; } final public function getAttribute($attr) { if (isset($this->attributes[$attr])) { return $this->attributes[$attr]; } else if (substr($attr, 0, 5) == 'data-' || substr($attr, 0, 5) == 'aria-') { return null; } // Maintain the rest of this function as is. } Voila! Now all your XHP elements support HTML5 data attributes. You could stop here and be just fine, but technically this isn't the best solution. HTML elements support data attributes, but you don't want your own custom XHP components to take them*. To allow HTML5 data attributes on only HTML elements, we need to rethink our approach. Going back to XHP's default behavior, rename the getAttribute() and setAttribute() methods in :x:composable-element to getDeclaredAttribute() and setDeclaredAttribute() respectively, make them protected, and replace them with the following non-final functions: public function getAttribute($attr) { return $this->getDeclaredAttribute($attr); } public function setA ## Abstracting CSS with XHP DevFeed: [Abstracting CSS with XHP]() Original publisher: [Read original article]() Author: Codebeforethehorse Published: 2011-02-25T17:11:00Z Content type: tutorial Language: en Sources: [Stefan Parker]() Topics: [CSS](), [ui](), [Web Development](), [HTML]() Tags: [class](), [classes](), [css](), [enum](), [format](), [function](), [html](), [render](), [root](), [ui](), [xhp]() ### AI overview The article explains how XHP elements can centralize reusable CSS styles such as colors and font sizes. It demonstrates defining enumerable attributes and rendering corresponding CSS classes, reducing duplicated styles and helping keep implementation aligned with design standards. ### Source excerpt A good site design uses a consistent palette and reusable styles, but the unavoidable pitfall is the developer will have to remember every classname for every color and format, or redeclare the same values for multiple CSS classes. There are many frameworks and scripts that try to simulate CSS variables to help with this problem, but they actually make the situation worse. You'll still have to remember all the variables and you'll also have to put them in multiple CSS classes. XHP provides a new (and perhaps the first real) solution to this problem. By creating a simple element that holds your common formatting and styles, you can both avoid having to remember all the CSS class names as well as stop duplicating the same style in multiple CSS classes. Your XHP element will have an attribute for every reusable style on your site. These are the core styles like your colors and sizes. Let's pretend we have these basic styles: .blue { color: #3b5998; } .lightBlue { color: #edeff4; } .gray { color: #808080; } .darkGray { color: #333; } .bigText { font-size: 16px; } .normalText { font-size: 13px; } .smallText { font-size: 10px; } Just some basic colors and sizes for the text on our site. Now create an XHP element that will add these values for you, with enumerable attributes: class :ui:text extends :x:element { attribute enum {'gray', 'darkgray', 'blue', 'lightblue'} color, enum {'small', 'normal', 'big'} size; protected function render() { $root =
      {$this->getChildren()}
      ; switch ($this->getAttribute('color')) { case 'gray': $root->addClass('gray'); break; case 'darkgray': $root->addClass('darkGray'); break; case 'blue': $root->addClass('blue'); break; case 'lightblue': $root->addClass('lightBlue'); break; } switch ($this->getAttribute('size')) { case 'small': $root->addClass('smallText'); break; case 'normal': $root->addClass('normalText'); break; case 'big': $root->addClass('bigText'); break; } return $root; } } You can extend on this to add any number of commo ## Basic XHP Abstractions DevFeed: [Basic XHP Abstractions]() Original publisher: [Read original article]() Author: Codebeforethehorse Published: 2011-02-14T07:22:00Z Content type: tutorial Language: en Sources: [Stefan Parker]() Topics: [Development](), [HTML](), [modern web development](), [Web Development](), [Code](), [Programming](), [ui]() Tags: [browser](), [class](), [code](), [component](), [components](), [css](), [development](), [examples](), [function](), [html](), [markup](), [programming](), [render](), [ui](), [web](), [web-developers](), [xhp]() ### AI overview This tutorial demonstrates how XHP can abstract HTML rendering logic into reusable components. Examples cover generating form inputs from a data object and conditionally adding markup for rounded corners based on browser requirements. ### Source excerpt On the surface XHP is nothing more than eye candy, but used correctly it can greatly simplify development. Creating good abstractions has always been smart programming, but it's very difficult to do that for your HTML components without mucking up your rendering code. Enter XHP to the rescue. Here I'll show you some basic examples of how XHP can be used to abstract out your rendering logic. These will be pretty basic, but hopefully enough to give you some ideas for your own setups. Let's start off with a simple abstraction to render form inputs of a basic data object. We can create an XHP element that takes the object as a parameter and returns the correct HTML input: class :ui:data-input extends :x:element { attribute DataObject data @required, string property @required; protected function render() { $data = $this->getAttribute('data'); $property = $this->getAttribute('property'); $input = $property} placeholder={$data->getPropertyDesc($property)} />; if ($data->propertyIsRequired($property)) { $input->addClass('dataRequired'); } return $input; } } Now all we have to do is use a element everywhere we want a text input for our DataObject. We can continue this abstraction out, assuming we model our DataObject well enough, to handle multiple form elements. The resulting XHP might look something like this: class :ui:data-form-element extends :x:element { attribute DataObject data @required, string property @required; protected function render() { $data = $this->getAttribute('data'); $property = $this->getAttribute('property'); switch ($data->getPropertyType($property)) { case 'text': $element = $property} placeholder={$data->getPropertyDesc($property)} />; break; case 'select': $element = $property}