Posts in JavaScript

Friday, June 26, 2009

Spaz Comes to the Palm® Pre™: How You Can Be Part of It

Transparency

Folks who got the fancy lad Palm® Pre™ on opening day found the App Catalog chock full of superapps. One of them is Spaz, a ground-up rewrite of the award-winning desktop application I created for the Adobe AIR platform using pure HTML+JavaScript. Getting Spaz on webOS™ has been a big undertaking for me, and the process has certainly had it’s ups and downs. But I’m proud of the fact that we shipped a truly open source, transparent app on the first day of a new platform.

But much like Spaz on the desktop, this is not a revenue generator for the project. Everyone who works on the Spaz project is a volunteer, and we rely on motivated folks to help us make cool software. It doesn’t need to be a huge commitment — even just getting involved in the discussion and coming up with ideas is a big help. But here’s where we need help the most:

Coding

While I intend to be the lead on Spaz for webOS™ for a while, I really could use help — I’m working in my free time, and that’s pretty limited with a family and a day job. The full source code of Spaz for webOS™ is available on GitHub, and people who want to help make new features happen are encouraged to check it out.

Even if you’re not well-versed in webOS™ coding, if you have a good JavaScript background (or don’t and are just interested in developing one), we need help to build up SpazCore, our component library that drives Spaz for webOS™, and will drive all our projects in the future. Hacking on SpazCore requires no knowledge of webOS™.

Support

We have a brand new, very awesome support site at http://spaz.tenderapp.com/ which is sponsored by the awesome folks at ENTP. We need to direct people there, and we need to get involved in helping them there. We also should build up the FAQ/Knowledge base. In addition, identifying folks on Twitter who are trying Spaz or having issues and pointing them to the support site is very important.

Advocacy

Do you like Spaz? Why? First off, let us know — I’d like to build a repository of positive mentions like that. In addition, telling people about Spaz and encouraging them to check it out is great. Hwoever, this needs to be done in a nice, non-abusive, non-spammy way, and we always need to respect other applications and their developers. THIS IS NOT A COMPETITION — it’s making people aware of quality alternatives to closed, non-transparent software.

Design/UI

I’m an opinionated fellow and rather controlling of how the Spaz apps look, but I also know there are better designers and UX experts than me. If you’re interested in helping with design and UI work on Spaz — including additional themes — I’d love to hear your ideas.

What About the Desktop?

You are not forgotten. Spaz’s desktop client is long in the tooth, and we have Big Plans for a full rewrite based on SpazCore. That’s long-term though, and in the interim work is still being done on the current Spaz codebase, including adding multi-account support and improving filtering capabilities. We also intend to transition away from AIR to the Titanium platform.

So if you want to stop bitching in your Twitter account and actually make things better, here’s your change. Drop me a line at spaz@funkatron.com and we’ll sort out the best way for you to kick ass.

Posted in Development, JavaScript, Mobile, Spaz, webOS by funkatron on 06/26 at 01:24 PM
(0) CommentsPost a comment

Sunday, February 22, 2009

Change is coming to Spaz

"Change is coming"

As I’ve mentioned in the past, I’m currently working on a new project that’s been taking my time away from Spaz. While most details are still under wraps, I can say now that the new project is a version of Spaz for mobile devices. Rather than a port, this is a whole new codebase that takes advantage of all the stuff I’ve learned writing Spaz for AIR.

While I will still be working hard on the mobile app for at least another month, I have been thinking a lot about where the desktop app should be going. Here’s the plan:

  • Version 0.8 will be the last version of Spaz using the current codebase. We are currently being held back by the design decisions I made, and they need to be tossed. Versions 0.9 and later will be based on a complete rewrite of the codebase. It will use an MVC-style pattern, and will be powered by the SpazCore component library. SpazCore being worked on now, and is hosted on GitHub at http://github.com/funkatron/spazcore/.

  • I may switch from the AIR platform to Titanium for the new Spaz codebase. I am still weighing this decision, but I’m very interested in TI, especially after having the opportunity to meet the development team last week. They have a very strong platform, and their approach is very much in line with the “Spaz philosophy.” http://titaniumapp.com.

  • Feature-wise, I’m targeting all1 existing features, plus:

    • multiple instances of the “main” windows (basically the current Spaz window, multiple times for multiple accounts)
    • multiple search windows with auto-updating results
    • less reliance on the web site for user and message details

Spaz should still be very suitable for average Twitter users (under 100 friends), but will also offer powerful search features for folks who need them. And of course, Spaz will still be completely open-source under a New BSD-style license.

Questions? Comments? Post them in the Google Groups thread


  1. Actually, one feature of Spaz that may see a reduction in functionality is theming. Supporting multiple themes in the main release is an enormous pain whenever I need to make an interface change. While I expect it will still be possible to override most or all of the interface with CSS, I will likely shoot for a single good theme to ship with Spaz, and leave modifications as an exercise for the motivated user. 

Posted in AIR, My Projects, JavaScript, Spaz by funkatron on 02/22 at 12:37 AM
(0) CommentsPost a comment

Tuesday, December 23, 2008

PHP Advent 2008 Post: JSON is Everybody’s Friend

Security

Reposting something you wrote is a lot easier than coming up with original content. This article was originally posted as part of the 2008 PHP Advent Calendar

Last year I wrote some kind of feel-good, hippie crap for the PHP Advent Calendar. This year I got a haircut, took a shower, and am ready to tell you about something practical: working with JavaScript Object Notation (JSON) in PHP.

“JSON?!” you cry. “But that’s for JavaScript fruitcakes!” And you’d be right. But JSON, while valid JavaScript code, is actually a very effective serialized data format for exchanging data between applications written in a variety of languages. And as of PHP 5.2, we have native support for JSON encoding and decoding.

But I Love XML!

Who doesn’t? The thing is, for moving data around—not documents, but data—I think JSON is superior to XML. This is mainly because JSON tends to map better to the data models in most programming languages—arrays, objects, etc. JSON is serialized JavaScript, so it’s easy peasy representing these kinds of things. Moving between JSON and your language’s internal data models is usually just a single function call. Smarter people than me can debate the pros and cons of XML and JSON in various scenarios, but for a lot of what I do, JSON does the same thing and requires less work.

Get Your PHP Objects On

In PHP 5.2+, there are two functions that handle JSON: json_encode(), which takes a PHP data structure and returns a JSON string, and json_decode(), which takes a JSON string and converts it into a PHP data structure. Let’s take a look at json_encode() and how it handles converting a PHP object into JSON:

<?php
// make a simple object
$obj->body           = 'another post';
$obj->id             = 21;
$obj->approved       = true;
$obj->favorite_count = 1;
$obj->status         = NULL;

// convert into JSON
$json_obj = json_encode($obj);
echo $json_obj;

This will output the following JSON string:

{"body":"another post","id":21,"approved":true,"favorite_count":1,"status":null}

Now, let’s take that JSON and turn it back into PHP:

// convert back into PHP
$new_obj = json_decode($json_obj);
var_dump($new_obj);

And we’ll have the following PHP object:

object(stdClass)#2 (5) {
  ["body"]=>
  string(12) "another post"
  ["id"]=>
  int(21)
  ["approved"]=>
  bool(true)
  ["favorite_count"]=>
  int(1)
  ["status"]=>
  NULL
}

Notice that the data types are retained in the process. JSON supports strings, numbers, objects, arrays (kinda), booleans and NULL. Things like methods, constants, and non-public properties are dropped in the encoding process, as shown in the example below:

<?php
class Foo {
  const     ERROR_CODE = '404';
  public    $public_ex = 'this is public';
  private   $private_ex = 'this is private!';
  protected $protected_ex = 'this should be protected';

  public function getErrorCode() {
    return self::ERROR_CODE;
  }
}

$foo = new Foo
$foo_json = json_encode($foo
echo $foo_json

This outputs the following JSON:

{"public_ex":"this is public"}

Also note that when you decode JSON into a PHP object, the object type is always stdClass. If we use $foo_json from above…

$foo_new = json_decode($foo_json);
var_dump($foo_new);

…we’ll get back the following object:

object(stdClass)#4 (1) {
 ["public_ex"]=>
 string(14) "this is public"
}

Arrays, Indexed & Associative

Array support in JSON is limited to indexed arrays—those with sequential, numeric keys. Associative arrays are converted into an object with corresponding properties.

<?php
// here's an indexed array. JSON natively handles these
$arr = array('orange', 'yellow', 'green', 122);
$json_arr = json_encode($arr);
echo $json_arr."\n";

That gives us this JSON:

["orange","yellow","green",122]

And we can convert it back into PHP…

$new_arr = json_decode($json_arr);
var_dump($new_arr);

…without losing anything in the process.

array(4) {
  [0]=>
  string(6) "orange"
  [1]=>
  string(6) "yellow"
  [2]=>
  string(5) "green"
  [3]=>
  int(122)
}

With associative arrays, the array is converted to an object. Also note that all associative keys are converted into strings in the process:

// associative PHP arrays are converted into objects
$assoc = array('orange'=>'yellow', 'green'=>122, 9=>122);
$json_assoc = json_encode($assoc);

The encoded JSON will be {"orange":"yellow","green":122,"9":122}. Decoding that gives us this PHP object:

object(stdClass)#5 (3) {
  ["orange"]=>
  string(6) "yellow"
  ["green"]=>
  int(122)
  ["9"]=>
  int(122)
}

You can, however, convert the JSON object back into a PHP associative array by passing TRUE as the second param to json_decode() (thanks Richard Orelup).

Playing Well with Others

That’s all fine and good, but it might help to actually do something useful with all this encodin’ and decodin’. JSON is a really good choice for moving data between client-side JavaScript applications and server-side applications, because JSON is JavaScript code, and maps perfectly onto JavaScript’s data structures.

So, let’s contrive a simple application that passes a “counter” object back and forth between the client and server. The counter object stores information on how often the PHP server application and the JavaScript client application “touch” it. First, we’ll make a PHP script to serve up some JSON code to our JavaScript client. It will look for an action parameter in $_GET, perform the requested action, and serve up some JSON in return.

<?php
if ($_GET['action'] === "getinit") {

  // make the PHP object and add a PHP touch
  $counter->php_touches    = 1;
  $counter->js_touches    = 0;
  send_as_json($counter);

} elseif ($_GET['action'] === "updatedata") {
  // decode JSON
  $counter = json_decode($_POST['counter']);

  // increment php touch counter
  $counter->php_touches++;

  // serve up as JSON
  send_as_json($counter);

} else {
  send_as_json(false);
}


function send_as_json($obj) {

  // convert object to JSON
  $json = json_encode($obj);

  // set appropriate headers
  header('Content-Type: application/json');

  // output JSON string as body
  echo $json;
}

The getinit action will create a $counter object, initialize it with a couple of variables to track “touches” by PHP and JSON, and serve up the object as JSON via the send_as_json() function. The updatedata action will take JSON from the $_POST array, decode it into the $counter object, increment the php_touches property, and serve up the modified object as JSON.

In the send_as_json() function, note the header() call that sets the Content-Type to application/json. Setting the content type correctly is good practice, and will sometimes avoid unexpected security issues.

On the client side, we’ll make a short HTML page with some embedded JavaScript to interact with our PHP service.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
  <title>JSON PHP Example</title>
  <!-- Load the Google JS libs hosting API -->
  <script src="http://www.google.com/jsapi"></script>
  <!-- Load the newest jquery major version 1 from Google -->
  <script type="text/javascript" charset="utf-8">
    google.load("jquery", "1");
  </script>
  <!-- load the JSON2.js parser -->
  <script src="JSON2.js"></script>

  <script type="text/javascript" charset="utf-8">
    var counter;

    function processData(data, textStatus) {
      counter = JSON.parse(data);
      counter.js_touches++;
      $('#js-count').val( parseInt(counter.js_touches));
      $('#php-count').val( parseInt(counter.php_touches));
    }

    // when the DOM is ready, do this stuff
    $(document).ready( function() {
      $.get('jsonphp.php?action=getinit', processData, 'text');
      $('#increment-button').click( function() {
        counter.js_touches = parseInt( $('#js-count').val() );
        counter.php_touches = parseInt( $('#php-count').val() );
        var json = JSON.stringify(counter);
        $.post('jsonphp.php?action=updatedata', { 'counter':json }, processData, 'text');
      });
    });
  </script>

  <style type="text/css" media="screen">
    body, input {
      font-family: Baskerville, Georgia, "Times New Roman", serif;
    }
    table {
      border:1px solid #CCC;
      padding:.2em;
      margin: .2em;
    }
    td.label {
      text-align:right;
      font-weight:bold;
    }
  </style>
</head>
<body>
  <table>
    <tr>
      <td class="label">JavaScript Touches:</td>
      <td><input type="text" id="js-count" value="0" /></td>
    </tr>
    <tr>
      <td class="label">PHP Touches:</td>
      <td><input type="text" id="php-count" value="0" /></td>
    </tr>
  </table>
  <form>
    <input type="button" name="increment" value="Increment!" id="increment-button" />
  </form>
</body>
</html>

Rendered in the browser, the page will look something like this:

Screenshot

Note that we’re using the jQuery library (loaded from the Google JavaScript Libraries API) to handle DOM manipulation and Ajax calls. We’re also using the JSON2.js parser, available at JSON.org, to safely parse and create JSON. The default method for decoding JSON into a JavaScript object or array is eval(), but that leaves us open to all sorts of code injection issues.

Jumping into our JavaScript code, the $().ready() is the most interesting portion. The ready() method called on $(document) takes the anonymous function passed into it, and executes the function as soon as the document is “ready”—that is, when the DOM is completed and can be safely messed with. So, when the DOM is ready, two things will happen:

  • A GET request is made to jsonphp.php?action=getinit, and the results are passed as text to the processData() function

  • An event listener is assigned to the click event for the button with the id of increment-button. This listener will fire a function that:

    1. Grabs the values for the touch counts out of the form fields

    2. Assigns them to the counter object

    3. Encodes the counter object as JSON

    4. POSTs counter to the server

So, each time we click the “Increment!” button, the object is sent from the JavaScript application to the PHP application as JSON. Each side will increment its own counter in the object, and the JavaScript application will display those values to us in the page. If we want, we can even change the values, and the JavaScript application will bind the new values to the object before sending it to the server.

What’s It All Mean, Dave?

Metaphysically, I have no idea. But practically, JSON support in PHP means that our favorite server-side language is an even better glue language— something it’s been good at for a long time. Now, go forth and make the next mega-ajax-crowdsourced-mashup masterpiece.

Posted in JavaScript, jQuery, PHP by funkatron on 12/23 at 04:34 PM
(9) CommentsPost a comment

Thursday, November 06, 2008

The Funkatron.com PHPMAX 2008 US Tour

The Funkatron.com PHPMAX 2008 US Tour

The coming weeks are gonna be a little hectic for me, as I fly to Atlanta on the 12th to attend php|works / PyWorks 2008. I’ll be doing the following talks:

I’m pretty excited about php|works / PyWorks 2008, especially because we can interact with the Python community and learn more about each other’s tech. Cross-pollination is a Good Thing.

I’m flying back to IND on the 15th, but then I’m leaving again on the 16th for San Francisco and the Adobe MAX 2008 conference. I’m giving the following talk:

Originally this talk was going to be given by John Resig, creator of the jQuery library, but he ran into some time constraints and thoughtfully suggested me. Of course, the description still mentions his name, which likely means I’ll be tarred and feathered by the audience. This also looks like it may be the largest audience I’ve ever given a talk before: there are currently about 70 folks listed as attending, with ~300 capacity. So if I wet myself on stage, please forgive me.

Posted in AIR, JavaScript, jQuery, Python, PHP by funkatron on 11/06 at 06:29 PM
(2) CommentsPost a comment

Wednesday, October 15, 2008

Safely parsing JSON in JavaScript

Wear safety shoes

I love me some JSON. It saves me tons of parsing headaches when exchanging data between web services because it maps so well to concepts shared among most common programming languages. It’s super easy to take a PHP object, convert it to JSON, and then push it to a Javascript (or a Ruby, or a Python) app.

Because JSON is valid JavaScript code, the most common method for converting it into native JS objects is to just eval the JSON. This is an extremely bad idea, because it opens your app up to all sorts of code injection attacks. Even with “trusted” sources, a security failure on your source’s end, or just a disgruntled employee, could wreak havoc on your apps and your users. I’d recommend reading Douglas Crockford’s “JSON and Browser Security”. Go ahead; I’ll wait. Rockford is impatient

jQuery, which we’ll use for all our examples because it’s awesome, will in many cases automatically parse JSON responses for you. This, as we learned above, is a Bad Thing. The following Ajax methods will automatically parse JSON in jQ (as of 1.2):

  • jQuery.getJSON()always
  • jQuery.ajax()if type is ‘json’
  • jQuery.get()if type is ‘json’
  • jQuery.post()if type is ‘json’

So my rules of thumbs are:

  1. never, ever use $.getJSON()
  2. never, ever set the type option to ‘json.’

To force the issue, I set my type to ‘text’ in my ajax calls. For example:

<script type="text/javascript" charset="utf-8" src="/js/jquery.js"></script>
<script type="text/javascript" charset="utf-8">
    $.ajax('http://twitter.com/statuses/public_timeline.json', function(data, textStatus) {
        alert('Status is '+textStatus);
        alert('JSON data string is: '+data);
    }, 'text');     
</script>

In the example above, we’re including the jquery library with the first <script> tag, and then calling the jQuery.ajax() method in the second. We’re passing three parameters:

  1. the URL we’re pulling the JSON string from. In this case, it’s the Twitter public timeline
  2. an anonymous function that’s called when the request is successful
  3. the type of data we’re getting, as a string. Using ‘text’ ensures no extra processing is done on the response string

So this is great, but all we’ve got is a string of serialized data, which isn’t terribly useful. Thankfully, there’s a handy library at JSON.org that takes care of parsing JSON without using eval without using eval on non-JSON code1. The library gives us two methods: JSON.parse() for turning a JSON string into a JS object, and JSON.stringify() for turning a JS object into a JSON string. So let’s utilize JSON.parse() in our code, and actually do something with that data:

<script type="text/javascript" charset="utf-8" src="/js/jquery.js"></script>
<script type="text/javascript" charset="utf-8" src="/js/JSON2.js"></script>
<script type="text/javascript" charset="utf-8">
    $.get('http://twitter.com/statuses/public_timeline.json', function(data, textStatus) {
        alert('Status is '+textStatus);
        alert('JSON data string is: '+data);

        // this will give us an array of objects
        var public_tweets = JSON.parse(data);

        // iterate over public_tweets
        for(var x=0; x < public_tweets.length; x++) {
            var twt = public_tweets[x];
            var elm = '<div class="tweet" id="'+twt.id+'"> \
                <a href="'+twt.user.url+'"><img src="'+twt.user.profile_image_url+'" /></a> \
                    <div class="tweet-text">'+twt.text+'</div> \
                </div>';
            $('BODY').prepend(elm);
        }
    }, 'text');
</script>

In the modified example above, the second script tag loads the JSON2 library. We then use the JSON.parse() method to turn the data string into a JavaScript object – in this case, and array of Twitter message objects. Then we iterate over the array, building a string of HTML for each entry and prepending it to the <body> tag (so the newest item is on top).

Note: If you’re using this code on a remotely-hosted html page (or loading it as a local file under Firefox 3), it won’t work, and if you check in your error console you’ll probably see a security warning. That’s because our $.get() call directly accesses the Twitter API hosted on Twitter.com, which is almost certainly not the domain your files are hosted on. When we try to do so, it violates the same-origin policy enforced by browsers. The only workaround that I think is safe is to set up some sort of proxy on your domain to pass requests – other approaches like JSONP rely on eval()ing the result, which is what we’re trying to avoid here. I’ll try to cover setting up a local domain proxy in a future post.

By handling JSON with a parser rather than just using eval(), we mitigate the risk of code injection. This helps us protect both our application and our users.


  1. Basically, JSON.parse() runs a regex search for code that appears to be defining a function or redefining prototypes or other kinds of stuff beyond simple data transmission, and guts those parts. 

Posted in AIR, JavaScript, jQuery, InfoSec by funkatron on 10/15 at 11:24 AM
(5) CommentsPost a comment
Page 1 of 2 pages  1 2 >