⇥ PHP 5.2 support ends just as its adoption begins

July 23, 2010
25 comments
 
⇥ Permalink

In case you missed it, the PHP team has just released 5.2.14, which effectively ends active support for the 5.2 branch1:

This release marks the end of the active support for PHP 5.2. Following this release the PHP 5.2 series will receive no further active bug maintenance.

The logic behind this decision is… puzzling.

Several large projects—WordPress and Drupal among them—recently announced that they intend to push support for 5.2 into their products with their next major release. For example, Drupal 7 will accept 5.2 features, and the WP folks are just working on EOL’ing their support for PHP 4.

This means that a large number of people are just beginning learning, using and stress-testing PHP 5.2. Remember—these projects have very large user bases, so even moving a small percentage of adopters over to a different platform means a big shift. Perhaps—just perhaps—it might be better to reconsider canning 5.2. If, from a technical perspective, the move from 5.2 to 5.3 is an easy one, there is a huge psychological barrier to finally adopting 5.2 only to have it yanked from under your feet.

The real issue at hand, however, is the fact that these large user communities are not engaged in the PHP world, and vice-versa. Ignoring the hundreds of thousands of Drupal and WordPress integrators and developers is bad for both PHP and for those products; we should, instead, try our best to open a dialogue between all the communities that are centred around PHP and ensure that everyone’s interests are properly represented.

This is not to say that the fact that WP has only now decided to move to PHP 5.2 should necessarily affect the progress of PHP, nor that the PHP developers should take a “we don’t need you” attitude toward projects that are based on the language. Ultimately, it’s up to these projects if they want to actively contribute back to PHP or not, and that is the only way for them to effectively affect the development of the language itself.

However, PHP development is too unevenly connected to downstream adopters. Some—particularly framework makers—have an unusually high level of participation in deciding how PHP evolves, and that needs to change.

At least year’s WDC, a small conference organized by Microsoft, I made this very same point and managed to bring a room full of developers into complete disarray in less than five minutes—which means that, in addition to the fact that my ability to drive a bunch of people up the wall in no time flat has not changed over the years, there is plenty to talk about.

[Update: the latest 5.2.x release is 5.2.14, not 5.2.11 as I originally stated. Thanks to Ilia for pointing that out.]

  1. As I understand it, this means no more added features or bug fixed. Presumably, security issues will still be taken care of.

The GPL: legit, but may contain malicious code

July 22, 2010
No comments
 
⇥ Permalink

WooThemes’s official Twitter account, in response to a request on whether a site giving away all their GPL’ed themes1 for a low fee is in breach of the license:

[I]t’s legit, but we don’t promote it as the themes are outdated & may contain malicious code.

So that’s it, then: the GPL is great until someone copies your commercial work and openly resells it, at which point making subtly unfounded allegations is the best way to save face.

  1. I’m not linking to it out of respect for the work that actually went into building Woo’s themes. For the record, I think that what has been done here is despicable, although it illustrates the weakness of the GPL model that the WPF wants everyone to adopt perfectly.

⇥ Graphr for iPhone · Say it with a smile(y)

July 21, 2010
No comments
 
⇥ Permalink

It is with a certain amount of pride that I announce the release of Graphr (iTunes link), my new iPhone app that allows you to copy and paste special characters like ☺, ⌘ and ✈ directly into any iOS app that supports text, including Mail, Twitter and Safari (or even the OS itself, if you want to create fancypants folders). Simply launch it, choose one of the eighty symbols it supports and then paste it directly into your favourite app using iOS’s copy-and-paste feature. Because it’s an iOS 4 app with minimal memory footprint, you can switch in and out of it in a heartbeat, making it the perfect companion for your day-to-day device usage.

Graphr also learns which symbols you use most often and moves them to a location that is more readily accessible so that they become easier to find. As you use the app, you will notice that your favourite characters will slowly move towards the top-left corner of the screen (note that it takes a while for the algorithm to kick in). Plus, it’s iPhone 4-compatible, taking advantage of that device’s Retina Screen with high-resolution graphics for its button frames and text.

Why Graphr?

Graphr is an app that I have wanted for a long time. Unicode characters are handy for a number of reasons; first, they are there: most OSs support them, so I don’t see why we shouldn’t be able to use them on iOS the way we do on other platforms. Plus, they are succinct: writing “YYZ✈MCO” is just as clear as “I’m flying from Toronto to Orlando” in Twitter parlance, but only requires seven characters. And those “I ♥ You” e-mails, while corny, always impress!

Graphr is inspired by GlyphBoard, a web-based Unicode symbol picker that features a great concept but that is ultimately impractical for everyday use, mostly because switching back and forth between Safari and any other app (including other Safari windows) takes too much time. By writing a native iOS 4 app and supporting fast switching, however, I can keep Graphr loaded and switch back-and-forth between it and other apps very quickly, thus making it almost an extension of the built-in keyboard. The app doesn’t support anything before iOS 4, because, frankly, the usage experience would be abysmal—can you imagine quitting your apps, launching Graphr, copying a character and then relaunching your other app on older iOS versions? Besides, GlyphBoard already does as good a job of that as possible under the circumstances.

Why not more features?

Graphr is the app I wanted to build—in fact, it didn’t even occur to me to release it to the public until after it was pretty much finished. Even though it doesn’t necessarily look like one, it’s pretty much built like a keyboard and, therefore, must be as simple and intuitive to use as one. And so it is: launch it, click on a button, and you’re done. There are no secret handshakes, no settings, no geeky character tables or codes. The app tries to learn how you use it and adapt to your specific needs rather than asking you to “tell it” something you may not even be aware of.

This is not to say that there are no features to add. For example, the app is built for right-handed users, a “leftie mode” that pushes popular symbols to the top-right corner instead of the top-left corner would be useful. Likewise, the symbols that the app supports are based on a thoroughly unscientific survey of web pages and tweets with some biases thrown in for good measure, which may or may reflect reality for everyone else.

Also, unlike Glyphboard, Graphr doesn’t allow you to copy more than one symbol into the pasteboard at a time. I considered this feature (obviously—it was staring right at me), but ultimately decided that having more characters and a simpler look was more important.

Why free?

Graphr is completely free, although it features iAd ads. This is not because I think the app is cheap or useless—quite the contrary. First, it’s an app that provides value over time; therefore, asking people to pay upfront doesn’t reflect the return that they will get out of it. With iAd, if you load the app and only use it once or twice, I will maybe make a few cents from showing you a couple of ads. If, on the other hand, you become a regular user, I’ll make more revenue over time. Of course, people are also going to be more likely to try out a free app, which doesn’t hurt, either.

Incidentally, I could have made the same decision for some of my other apps, but, well, iAd simply wasn’t available when I developed them, and I’m not about to show Google ads—the fast food of online advertising—alongside my work. Apple’s ad platform appeals to me because it has a high bar of entry, making it more likely that high-quality, brand names will appear next to my name. It’s not so much that iAd generates more revenue—it’s that using iAd is a bit like having lunch at the French Laundry while your favourite actor strikes up a conversation with you. As far as ads go, I want to be a foodie.

Headway Themes is now licensed under the GPL… uhm, no, wait. It isn’t. Well, sorta.

July 19, 2010
No comments
 
⇥ Permalink

Grant Griffiths on split-licensing the PHP code of his themes under the GPL and the images/CSS/JS files under a proprietary license:

The split GPL license still allows us to retain enough teeth that we can bite someone in the butt if they violate our own license for Headway.

I fear that Grant hasn’t quite thought this whole affair through. But let’s take a look at the Headway ToS themselves:

All WordPress themes produced by Headway Themes are released under the GPL version 2.0 license (http://www.gnu.org/licenses/gpl-2.0.html GNU/GPLv2). Specifically, the PHP code portions are distributed under the GPL version 2.0 license.

Are “all themes” released under the GPL or the PHP portions? I think the intent of the author are fairly clear, but this language introduces contradiction in a legal document—not a good start. You’ve just given a prepared attorney a way to show that your language is ambiguous and a reasonable third party could interpret it in a way other than the one you claim is the correct one. And believe me, they’ll latch on to this like the Shuttle on the Space Station.

The Headway Themes Proprietary Use License is a GPL compatible license…

Who has decided that it’s compatible? What happens if a court should decide that it isn’t?

You are authorized to make any necessary modification(s) to Headway Themes to fit your purposes. You may not however redistribute or release modifications as GPL or otherwise.

Wait, what? You get to release under the GPL but I can’t? Sorry, but the GPL says the exact opposite:

4.  You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License.

Incidentally, you also don’t get to choose which pieces of the GPL your code is subject to:

7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License.

See how confusing things get? And that’s without even counting the fact that a clever lawyer may well point out that the CSS, JS and image files are derivative of the theme because they cannot be used meaningfully outside of it (much like GPL proponents claim that the theme itself cannot be used meaningfully without the underlying WP code).

I hope that Grant got legal advice… uh-oh:

While I know Matt would rather we would have gone 100% GPL, we felt more comfortable with a split GPL license.  We actually modeled our license which we have included in a revised TOS after what Jason has at Press75.  Below, you will see the exact language we now have which according to Matt Mullenweg is “100% legal.”

These people are playing with fire.

⇥ WordPress and the GPL: the day after

Last week, I posted an article that pretty much started with “this is not about a legal interpretation of the GPL.” Therefore, of course, 80% of the people who commented on the article did so to give me their interpretation of the GPL, or to explain why my interpretation was incorrect. So much for that.

You are not Perry Mason

Let me, once more, explain why the legal interpretation of the GPL has no bearing on the issue at hand before addressing some of the issues that were raised in the comments. The positioning of the GPL with regards to derivative works has not been tested in a court of law. This means that there is no accepted definition of what a derivative work is in this context is simply undefined and can, by some account, lead to, shall we say, “interesting” conclusions. For this reason, my opinion on this matter, or Matt’s, or anyone else’s, is entirely meaningless, at least from a legal perspective.

You could say that Matt’s opinion counts, because he wrote the software and he should have the right to decide how his software is distributed and under what rules.

I couldn’t agree more—except for one minor detail: Matt made his decision when he chose to distribute WordPress under the GPL. From then on, both he and any user of WordPress are bound by the terms of the license, and not by what anyone thinks. Matt doesn’t enforce the license: that’s for a court of law to do. Therefore, what he thinks at this point only has value, from a legal standpoint, if a competent court determines that the terms of the GPL agree with him.

This, incidentally, is one of the biggest concerns that I have with the GPL. It’s a license that enforces a very particular meaning of “freedom” whose nuances a developer may simply not understand. Case in point: Matt may well believe that themes must be released under the GPL as derivative works, but there is no real case law to back this belief. The FSF says so1, but they are less than intellectually honest by not admitting that they do not have the legal standing to back their claims.

The reason why I say that this is not a legal issue, therefore, is that, unless and until the WPF sues a theme developer on the issue of whether a theme or plugin that doesn’t incorporate wholesale code from the main project2 is a derivative work, this is a business issue that can deeply affect the future of WordPress if not handled correctly. Hence my points in the previous article.

One thing that many do not seem to understand that the enforcement of a contract (or a license) is, essentially, a failure of the contract itself. A contract exists so that two parties can have an understanding on how a business relationship should take place. If the contract is sufficiently clear and unequivocal, it should only ever be enforced if one of the parties maliciously and willfully breaches it and then refuses to cure the breach. If it is unclear and equivocal, as is the case here, the enforcement of a contract represents a failure to draft a proper agreement in the first place.

When people play armchair lawyers and give their own interpretation of the legal meaning of the GPL, I can tell immediately that they have never had the unpleasant experience of being involved in a lawsuit. Those who have, on the other hand, know that lawsuits are a very dangerous game whose rules are known only to those in the legal profession—and are, ultimately, in the hands of a referee who is as human as everyone else, and often called upon to render judgment on topics he or she has no real technical expertise to understand, let alone determine. It’s like playing a game of soccer in which losing might mean forfeiting your business, house and livelihood, and in which each team can put as many players on the field as their money allows. Oh, and the refs are asked to rate the player’s bedroom technique instead of counting the goals.

When most people talk about lawsuits and court cases, they think “Law and Order” or (God forbid) “Boston Legal,” and truly have no idea of what they are getting themselves into—the long hours, constant uncertainty, ridiculous expenses and inevitably dangerous outcome. In real life, lawyers don’t stomp around a courtroom yelling “you can’t handle the truth!” They drudge endlessly through point after point, doing whatever they can to help their client prevail, often flying in the face of the very things their client has done or agreed to in the past. It’s their job and, even though while they are doing it you would like for nothing better than jump up from your chair and stab them in the eyeball with a pencil, you can’t fault them for it. Remember, despite the fact that everyone called bullshit on SCO’s claim against Linux vendors, it took seven years to finally kick them to the curb. Is that they way you want to run your business?

Regardless, enforcement is not the point of a contract—the point of a contract is to establish a clear framework in which everybody can conduct their business in a clear and unequivocal manner.

It was a honeypot!

Ultimately, I am happy that so many decided to post “legal” comments to my article. In fact, I was counting on it, because it helps me drive home a simple point: we need a better framework than the GPL to help us define our freedom.

What is happening in the WP world is a perfect example of how the GPL’s one-size-fits-all approach is failing us. If Matt wanted themes and plug-ins to only be distributable under the GPL, he could have simply expressly said so in his license, thus clearing the air once and for all. Of course, this wouldn’t prevent some third party from maliciously attempting to circumvent the license, but then at least we could focus on the maliciousness of their action instead of grasping at straws trying to figure out what the license means in the first place.

Instead, we are stuck with the GPL and its less-than-perfect definition of derivative work and this, at the very least, is going to cause concern and confusion. Remember, even though you may be convinced that a particular interpretation is the correct one, that doesn’t mean that everyone else will as well. I, for one, disagree with Matt’s interpretation of the license and I will freely admit that I would have probably missed this particular problem had it not been brought to my attention by what has happened. Luckily (for me), it doesn’t affect any work that I have done, but it will now force me to think twice about any project that we build based on WP.

By the same token, if this issue becomes big enough, any reasonably sophisticated client that does his homework will have to wonder how the licensing of WordPress—and the WPF’s willingness to go to court in an effort to enforce its own vision thereof—will affect their projects. At the very least, they will want to consult a lawyer on the topic, which is expensive and will probably lead to an inconclusive opinion (which, I believe, would be the only honest one). Again, what you think is the right or wrong way to interpret the GPL means absolutely nothing—what matters is what the client thinks and, if you’re handing out legal advice because they ask you, you’re setting yourself up for big trouble down the road when it turns out that you were wrong.

This is why, in my previous post, I said that no good can possibly come from what has happened. It’s not so much that I dislike the GPL—which I admittedly do; it’s that it needlessly introduces problems that we shouldn’t have to deal with. Contracts and licenses should be the legal expression of a business intent and must, therefore, be written with the business goals of each particular project in mind by lawyers who are acting the best interest of their clients (the project maintainers). The GPL, which is itself not free, is written in the best interest of the FSF to protect a prototypical, but abstract, software product. If you adopt it, you are letting someone else impose their philosophy, values and objectives on your work.

A final thought on copyrights and work for hire

A number of commenters honed in on whether client work is work for hire or not, expressing surprise at the fact that I do not normally assign copyright when I work as a consultant, so I thought I’d spend a few extra words explaining my position on the subject.

When a client engages my services, there are usually two scenarios: either they ask me to solve a specific problem, or they ask me to build something for them. The distinction is, in my mind, very significant. If a client comes to me and asks me to, say, develop an algorithm to do something, I consider that work for hire and am happy to assign all the appropriate rights to them.

When, on the other hand, a client asks me to develop a solution—for example, build a website or perform any work in which the end product is unique to client, but the processes that are used to arrive to it are not—then I insist on maintaining copyright and assigning a properly-drafted license to the client. The reasoning is that my client is not purchasing access to my trade secrets or to the methods and knowledge that go into creating whatever the final product is. Rather, they are employing my knowledge to enable them to perform a particular task. This is not unlike, for example, buying a car: you do not acquire the copyright in its design or the trade secrets that go into, say, the creation of the drivetrain: all you buy is a tool that allows you to move.

In these cases, the final license has, obviously, to be appropriate to what the client needs to do with the product—for example, modify, redistribute, sublicense and so on. But the ownership remains mine, because the knowledge that goes into the product is orthogonal to the product itself. Note that copyright and trade secrets are, obviously, two separate concepts, so that the copyright in code I write could be assigned without having to give up the associated intellectual property, but why confuse the issue? Being able to reuse portions of code between projects makes it possible for me to provide my clients with more affordable services without compromising the uniqueness of their product and gives me the opportunity, if I so choose, to release it as OSS. Naturally, the client maintains control and ownership of all of their bits and pieces, like trademarks, proprietary code that is included in the final product, etc. etc.

There are, of course, some exceptions, but by and large I have yet to encounter a client worth working for who has a problem with this—in fact, it’s great for clients whose internal policies make it difficult for them to interact with OSS, since the copyright never gets assigned to them and the product can, therefore, be directly distributed under an open-source license.

  1. In an FAQ that is not part of the license and therefore has no legal value whatsoever
  2. I should note here that Andrew Nacin has apparently found evidence of actual copying in Thesis, which, if true, would be an obvious violation of the GPL. But I also want to make it clear that this happened post-facto: the initial claim that Matt made is that a theme is a derivative work “no matter what,” so that my argument remains entirely valid.

⇥ WordPress, the GPL and cherries on top

July 15, 2010
21 comments
 
⇥ Permalink

The WordPress community is abuzz with news that the WP Foundation has essentially gone to war with the makers of the Thesis WP theme. The substance of the argument, as I understand it, is that the makers of WordPress claim that themes, since they rely on WP’s GPL’ed code to run, must be covered by the GPL as well because they are derivative works. Thesis, on the other hand, is distributed under a commercial license, therefore violating this tenet.

I have, in the past, expressed my dislike for the GPL, which, inevitably, colours my “legal” opinion on the matter—though, I assure you, this post is not about the GPL and I have absolutely no intention on engaging on a debate on the license. Write me or comment on the GPL and I will simply not care—you’ve been warned.

Legal opinions abound

As always when a legal matter is involved, everyone and their dog is giving an opinion. Matt went and asked the Software Freedom Law Center to officially render theirs, and they came through, true to their name, with a nine-paragraph letter that illustrates how themes are, in fact, derivative works covered the GPL.

Arguments on the other side of the fence typically focus on the fact that themes are not derivative works, or because of the fair-use doctrine1.

Personally, I find the SFLC’s argument very weak from a technical standpoint—particularly in the citation of the use of include (which is not a function2) as justification for their claim that themes are derivative works. Includes are designed specifically to create interoperability between different programs—in the world of PHP, where there is no concept of “binary,” they are the equivalent of dynamic linking.

One would have to physically copy code between projects, or physically include files from another project in a new work, in order to create a derivative work in this context, and to claim that themes do this is simply ridiculous because WordPress is designed to be expanded in precisely the way that themes are developed. To impose the GPL on themes—unlike, say, imposing it on a fork of WP itself, which would be perfectly logical—is to restrict a developer’s ability to interact with a particular piece of software and this would constitute an artificial limitation on a developer’s ability to interact with WordPress, which could give grounds to a fair-use claim.

Obviously, the SFLC probably believes that any form of linking or reliance of a piece of software upon another creates a derivative work, and they may well be right. Larry Rosen of the OSI believes that the determination of what constitutes a derivative work in the context of software should also take into account the element of intent—that is, whether the author of the work in question wrote their software in a specific way because they were aware of and attempted to circumvent the application of a license to derivative works. If he’s right, building a theme cannot possibly constitute the creation of a derivative work—again, WordPress is designed to be expanded, and it cannot taint downstream work that is not a direct derivation of itself, much like Linux cannot impose the GPL on commercial drivers or on commercial products built on it3).

Legal opinions are meaningless

Here’s the kicker: what I think is meaningless. What Matt thinks is equally meaningless. And what the SFLC means is most meaningless of all.

I am not a lawyer, and neither is Matt. The SFLC, which has an obvious bias towards the enforcement of the GPL4 is made up of lawyers and they, more than anyone else, should have made sure to cover their collective ass and Matt’s by explicitly pointing out that there is but one legal opinion that matters: that of a judge and jury.

Unless the WP Foundation ever takes the makers of Thesis to court, therefore, all these “legal opinions” have absolutely no legal value whatsoever. They are nothing more than a form of posturing and an exercise in public relations in the world of court opinion, to cite Adlai Stevenson.

And that is what puzzles me, because from a business and strategic perspective, the WP Foundation has nothing to gain from this exercise. Let’s look at the possible outcomes:

  • The WPF could sue and lose, and look like idiots who spend their time litigating rather than innovating (which is what they should stick with).
  • The WPF could sue and win—and still look like idiots because the implications of themes being covered by the GPL would have an enormously chilling effect on the professional WordPress community. More than that, they would have to sue every infringer, or risk looking like they are pursuing some secret Matt-centric agenda.
  • The WPF could do nothing and look like warmongering zealots—belligerent only in words, all they would achieve is a polarization and eventual schism of the community between those who believe that software is free, and those who believe that GPL is about freedom.

The way I see it, there is no possible outcome of this diatribe that could benefit the WPF, which is why I am puzzled.

Incidentally, you may be wondering why I think that GPL’ing the themes will be problematic for the entire community. Well, what I am wondering is: how will it affect the thousands of freelancers who create custom one-off themes for clients?

This is a big problem, because the GPL does not attach itself to a derivative work until you distribute it—this is why, for example, you don’t need to release GPL code if you hold copyright and use it for your internal purposes. If you are a freelancer, however, you normally hold copyright on a theme you develop but don’t use it for your own purposes—you give it to a client under some sort of license… which is exactly what amounts to distribution.

Unless you assign the copyright in your work to the client (and why would you want to? You are a freelancer, not an employee, and giving up copyright in a particular work is tantamount to giving up your trade secrets), you are, effectively, distributing the theme you developed, which now becomes covered by the GPL. Should the theme somehow include code that is owned by the client—for example to interface to one of their internal systems—that code might well be covered by the GPL, too, thus opening a can of worms of elephantine proportions: the client has gone from ordering a bunch of templates for its website to having to open-source and distribute its own proprietary code. If I were said client, I’d probably be switching to another CMS right now.

Naturally, the WPF could say that it won’t pursue those cases, but they don’t get to choose what the GPL attaches itself to or not—remember, the GPL is not GPL’ed itself: you can’t modify it, you can only use it or not use it. And the GPL says that derivative works must also be released under the GPL period.

So, what the WPF thinks the GPL applies to and what it actually applies to could be two completely different things. Therefore, while you may not get sued by the WPF for writing a proprietary theme specifically for a client, the GPL may still apply to it and all the code that is part of it—which means that, if your theme uses a client’s proprietary code, you’re both in potentially big, big trouble.

So, what should the WPF do?

First, it should back off; this fight isn’t helping anyone—least of all the WPF itself.

Second, it should draw very clear lines in the sand:

  1. WP is released under the GPL, and so has to be any direct contribution to core or fork thereof.
  2. Themes and plugins are not derivative works and are not covered by the GPL and can be released under commercial licenses.
  3. Themes and plugins distributed by wp.org must be released under a GPL.

This creates a fair and balanced set of clear guidelines for everyone to follow: if you want the exposure of wp.org—for example to increase your reputation and credibility as a WP expert freelancer—you have to release your code under an open-source license. If you want to distribute your code commercially, the burden of promotion and public relations is on you since the community doesn’t benefit directly from your work.

Now, I anticipate that some will simply say that, under my proposal, nothing would prevent commercial vendors from circumventing the fact that core is GPL and simply using plugins to effectively fork WP without forking it. Well, nothing has prevented them from doing that until now5, so how would this be different, other than giving developers and freelancers the confidence that the WPF board isn’t going to wake up on the wrong side of the bed one day and start suing people left and right?

  1. I link here to two articles by the same author only because these seem to be the best-researched among those I’ve seen. There are plenty more to go around.
  2. I am not splitting hairs: if you want to make a legally-valid argument, it needs to be based on a technically valid thesis, or you will be ripped to pieces by the opposing expert. Trust me—I’ve done the ripping myself.
  3. Again, the distinction is fuzzy here, because there are no binaries and no static linking in PHP—but that doesn’t mean that a court of law could create an analogous framework for PHP applications based on whether code was copied, whether there is overlapping functionality and what the intent of the downstream developer is.
  4. It’s the very reason of their existence, and there is nothing wrong with that.
  5. Sure, maybe the WPF claims that themes and plug-ins are covered by the GPL, but that hasn’t stopped developers from building commercial products anyway.

Non Hover?

Trent Walton:

Hover states are everywhere.  I don’t think I’ve ever written a stylesheet or designed a site without putting a significant amount of thought into how they should behave. As users, we’ve been conditioned to rely on hovers states to trigger changes in link color, reveal action items, and navigate through multiple tiers of a drop-down menu.

Fascinating how mobile devices are forcing designers to rethink their decisions and rethink “best practices.” One thing I dislike is the current trend of making changes on a per-device basis, because it needlessly complicates an already overly-complicated process. Do point-and-click devices need hover? I don’t think so—if mobile/touch is one of your target markets, just do without it.

⇥ Formatting Flex Datagrid rows

June 28, 2010
One comment
 
⇥ Permalink

I keep coming across people who seem to think that Flex’s data formatting facilities are somewhere between Voodoo and rocket surgery, particularly when it comes to data visualization elements like DataGrids.

Nothing could be further from the truth—Flex may not be the best system in the world, but it’s all about manipulating data; therefore, it has some excellent (and super-easy) formatters.

Inside a DataGrid, what seems to be a problem for so many is the fact that the data is seemingly rendered without any input from the developer. All this means, however, is that you need to write your very own, custom item renderer.

Sounds scary? It couldn’t be simpler: all you have to do is create a mini-component inside your DataGrid’s rows. For example, consider a simple DataGrid whose data provider contains the two columns orderDate (a date) and and orderAmount (a currency value). Normally, your code would probably look like this:

<mx:DataGrid dataProvider="{data}" width="100%">
  <mx:columns>
    <mx:DataGridColumn headerText="Order Date" dataField="orderDate" />
    <mx:DataGridColumn headerText="Order Amount" dataField="orderAmount" />
  </mx:columns>
</mx:DataGrid>

Obviously, there is nothing wrong with this code, which will work just fine… except that the output is not quite as user-friendly as it could be:

I don’t know about you, but my clients don’t normally work in GMT—and those crazy devils just insist that their amounts must be properly formatted with currency signs and thousand separators.

Luckily, this can be rather easily achieved using two of Flex’s many built-in data formatters—namely, mx.DateFormatter and mx.CurrentyFormatter. DateFormatter takes a string specification like “YYYY-MM-DD” and uses it to format a date. CurrencyFormatter, on the other hand, provides a number of parameters, like precision and thousand separators, that can be used to control the textual representation of a currency value. For example, we could write our two formatters like this:

<mx:DateFormatter id="dateFormatter" formatString="YYYY/MM/DD" />
<mx:CurrencyFormatter id="moneyFormatter" currencySymbol="$" useThousandsSeparator="true" precision="2"/>

Remember that both formatters are non-visual elements and, therefore, must be added to the <fx:Declarations> element of your component.

All that remains to be done now is to create item renderers to provide a custom representation of each of the DataGrid’s columns:

<mx:DataGrid dataProvider="{data}" width="100%">
  <mx:columns>
    <mx:DataGridColumn headerText="Order Date" dataField="orderDate">
      <mx:itemRenderer>
        <fx:Component>
          <mx:Label text="{outerDocument.dateFormatter.format(data.orderDate)}" />
        </fx:Component>
      </mx:itemRenderer>
    </mx:DataGridColumn>
    <mx:DataGridColumn headerText="Order Amount" dataField="orderAmount">
      <mx:itemRenderer>
        <fx:Component>
          <mx:Label text="{outerDocument.moneyFormatter.format(data.orderAmount)}" width="100%" textAlign="right" />
        </fx:Component>
      </mx:itemRenderer>
    </mx:DataGridColumn>
  </mx:columns>
</mx:DataGrid>

As you can see, we simply use <fx:Component> to declare an inline component inside the itemRenderer attribute of each column. Once instantiated, the custom component will have its own scope, but we can still access the data row whose values we must visualize through the data property, while the main component (where our formatters reside) is stored in the outerDocument property. Note that I am using <mx:Label> and not <s:Label>, because the DataGrid is a Halo container and, therefore, most Spark components cannot be fit into it1. For good measure, I also-right aligned the currency column; note that I am setting the label’s width to 100 percent so that it will stretch all the way to the end of the column; otherwise, the right-alignment will be ineffective because the label will only occupy as much space as necessary.

That’s it2! The output of our little application has improved considerably:

Now, we could, in theory, have placed the formatters into the individual item renderers, as long as we enclose them in their own <fx:Declarations> block:

<mx:DataGridColumn headerText="Order Date" dataField="orderDate">
  <mx:itemRenderer>
    <fx:Component>
      <mx:Label text="{outerDocument.dateFormatter.format(data.orderDate)}">
        <fx:Declarations>
          <mx:DateFormatter id="dateFormatter" formatString="YYYY/MM/DD" />
        </fx:Declarations>
      </mx:Label>
    </fx:Component>
  </mx:itemRenderer>
</mx:DataGridColumn>

This will arguably keep our code a little cleaner and make it easier to customize multiple columns to different formatting specifications. However, the added flexibility would come at the cost of creating an additional object for each item renderer for each row that is displayed at any given time.

  1. Ironically, <s:Label> will actually work here, but the compiler will complain about the fact that the data property cannot be accessed. That’s because Spark’s version of the label is not designed for use as an item renderer… which unfortunately is not mentioned in the error reported to you.
  2. Note, most interestingly, that we do not have to worry about the bindability of each row’s individual properties—that’s because the DataGrid object actively invalidates the data property of the item renderers for each row that needs to be displayed.

Should we get ready to go nuts over cookies?

The Register on a new EU law, due to go into effect next year, that requires sites to ask for consent prior to storing cookies on a user’s browser:

An exception exists where the cookie is “strictly necessary” for the provision of a service “explicitly requested” by the user – so cookies can take a user from a product page to a checkout without the need for consent. Other cookies will require prior consent, though, and the law must be implemented in member states by May 2011.

So, how do you define “strictly necessary?” If your PHP installation has sessions on by default even though you don’t use them, is that a violation of the law? What if you use Google Analytics on your site? Should you, or Google, request permission?

If any of my European friends want to chime in with what this means, I’d welcome the information. Please try keeping the swearing down to a minimum, if you can…

⇥ NoSQL, round holes and square pegs

June 25, 2010
2 comments
 
⇥ Permalink

Ivo Jansch:

In last year’s conference, there was a talk on CouchDB, introducing a ‘NoSQL’ database as a response to relational databases often being a hassle when web data needs to be stored and manipulated. This year, we could see that NoSQL is catching on and becoming more mainstream. Matthew Weier O’Phinney, project manager of the Zend Framework, discussed NoSQL in detail, and MongoDB (Another NoSQL database) was mentioned in a couple of talks. NoSQL is definitely something to have a look at, and it might be useful even in existing projects. More info can be found on the Wikipedia page.

We saw the same at this year’s TEK·X conference. More and more people are realizing that working with SQL is, at least in some cases, an exercise in fitting a square peg to a round hole; NoSQL, however, still presents a movement “on the rebound” from SQL, so that they seem to be trying to round out a lot of pegs that maybe don’t need to be. On the other hand, some uses of RDBMSs are a little ridiculous. If you’re storing documents inside a MySQL database, you’re not using the best tool for the job.

However, the NoSQL community still has a long road ahead of itself, with many issues that need resolving. Right now, fragmentation—the result of the relative youth of these systems1—makes the adoption of any one system risky, while the lack of a common data querying language (or even vocabulary) makes it difficult to future-proof any project based on a document-oriented database system.

Eventually, I suspect that we’ll reach some sort of equilibrium in which one of the document-oriented systems will prevail and become as ubiquitous as, say, MySQL has become, or, at least, some sort of bottom-of-the-barrel standard like SQL will become common among the various implementations, so that developers will be able to switch between systems more easily and focus on the differences that make one more appropriate than the others in a particular development scenario. Of course, the various NoSQL leads could simply attempt to get together and find some common ground that can help them grow more organically and cohesively—but this is software… so I won’t be holding my breath.

  1. Document-oriented databases have been around for a long time, but they were relegated to specialized applications until recently. With greater awareness, there are an increasing number of competing systems being developed in a completely haphazard and disconnected way.