It should come as no surprise that ActionScript3 (Flex/Flash) are second class citizens in the Facebook app world.

But, that doesn’t make it any less frustrating, when you encounter it.

The most recent turn appears to involve the app installing itself into the users account. This used to work swimmingly well. Now, all of a sudden, I’m discovering my potential users can’t install. They never get the ‘Allow’ dialog and the app just hangs on connection.

Various tests show that all of my Flex/Flash, apps and test platforms do this, so it’s not just the app in question. The PHP tests, of course, work swimmingly well.

Other AS3 app developers have noticed this, too, and have had to implement a range of workarounds to fix it. I think FB has screwed up their permissions files for AS3. It would be nice to get FB’s attention to figure out what went wrong, or Adobe’s, but that’s like trying to get through to MS. All you can do is spatter messages on the boards and pray.

So, I’m in the middle of figuring out how to do the workarounds and still stay in the AS3 codespace. Another alternative is to let PHP set up the session and then the Flex app can just attach itself to that session.

Of course, once I get this many-days-endeavor implemented, FB will fix it, and everything will work properly as it did before, in the original context.

But, should they mess up again, the workaround will be a good failsafe against that.

Grouse, grouse. Ommm, Ommm.

(Note: A demo version of this is available to play with in my example site. The directory is open, so you can examine the separate pieces.)

So, in the last post I talked about putting together a form that pretty much handled everything from the client side. In that, the goal was to eliminate as much interaction with the server as possible.

Of course, the server has to interact at some point – we need to get the data to the server, and data back out, since it’s likely the user will want to view his information or edit it in the future.

So, this bit requires a couple of extra pieces and a touch of AJAX just to get things working.

Other Pieces

doneform.php is a PHP file that gives the form a destination. It’s primary function is simple: receive the form output and do something with it. In this case, it does two things:

1. Dump the $_POST array so you can see the values.
2. If data was entered, store it somewhere. If not, clear anything that might have been stored, earlier.

(1) is easy. Just call var_dump on the $_POST array.

(2) is a bit trickier – I need someplace to store the information for subsequent editing. Since I’m reticent to devote database resources to a demo, I’m perfectly happy to use your browser as a data repository: if there is data to be stored, it’s stored in a session cookie (a session cookie is deleted by the browser when the session is ended. i.e., when you shut down your browser.) Valid $_POST information is detected at the top of doneform.php, and the cookie is set with some JSON, or deleted as appropriate. (I’m using the pear HTML_AJAX package for this endeavor.)

Editing

This is the bit of AJAX added – when the form is loaded, it checks with the server to see if there is any data to be used (is this an editing session?). This is done with an AJAX call to form_response.php, which checks for the cookie and retrieves it, if it exists.

If so, the server spits back a bit of JSON with the data (in this case, the cookie contents set earlier), and sets the form contents, accordingly. In addition, it brings up the red “Editing” banner at the top of the page. Other feedback might be nice to indicate to the user that he is editing current data.

Synopsis

This works well for the use I intended. If I were interested in intermediate results, or there was something that needed to be checked with the server before things could proceed, a bit more AJAX-ey approach would be necessary. But, for this usage, I really would rather offload processing to the client as much as possible, and keep bandwidth to an absolute minimum.

Could I have used a .js library? Maybe. I haven’t seen anything that allows manipulation of tables to the degree I’m looking for, here. Kits are always a trade-off – you can do what they expect you to want to do, easily. Doing what they might not expect you to want to do can be a real nightmare, and you’re better off rolling your own.

While constructing the previous post, I noticed a number of things I didn’t like, particularly in the list editing – the lists are cramped together, the lineheights aren’t right, and there’s no way to ‘paragraph off’ a list, like so:

• This is a list item.
• This is a continuing thought within the list item.
• This is another list item.

Notice the break in the continuing item. That’s achieved with a special list item (using <br/> is crude – hard to style.)

If you specify a css rule for a continuing list item like so:

li.continue { list-style:none; margin-top:0.4em!important; }

you can define a ‘continuing list paragraph’. Problem is, when WordPress sees such a thing, it strips it out.

So, I’ve had to crawl through the code and figure out what the heck is going on. Way down deep inside, there’s a file that lists ‘allowedposttags’ – an array of arrays following canonical rules. A bit of a hack, and I’ve got <li> behaving the way I want.

Just have to save off the changes in case of upgrade.

Another thing I like is a stand-off paragraph – something to introduce a new thought in the text, without having to use something like a header. That’s how this paragraph is defined. Again, another class description:

p.class  { padding-top:2.0em; }

Or some such thing, and now I have a stand-off paragraph.

As usual, packages are great – they get things going. But, to get what you want, you have to dig inside of them and control them by the tail. WordPress is no different.

Ok, I’ve got about ten things going at once, here. I’m the incarnation of Andy Grove’s pre-commitment exploration dictum: Let Chaos Reign!! Of course, the other side of that dictum is that when you’re committed to a particular direction, you apply the inverse: Reign Chaos In!!.

Well, it keeps me from getting bored between gigs, anyway.

The top four things (as of the moment) are:

1. Getting the Zend IDE up and running for PHP. Ostensibly, this would seem to be simple, but things are complicated by virtue of the fact that Zend has created a second IDE based on Eclipse. Eclipse is a good thing – it not only supports PHP, but HTML, CSS, XML, and the rest of the alphabet soup of net languages, for development on the net. But, it supports application development languages, as well, most notably C++ and Java.
2. Assiduously avoiding Java (don’t like things that consume half the machine’s resources to run a ‘hello world’ program), but C++ is right in there.
3. Ubuntu VM configuration. Ok, I like ubuntu bunches. I hate to say it’s almost ‘Windows-like’ in ease of use, but it is. It has what must be the best update manager in the open-source world – it really does ‘just work’.
4. Qyoto investigations: C# and Qt – what I think may emerge as the best cross-platform agile development environment, ever. C# has all the advantages of Java, without the overhead penalties. Qt is the best cross-platform windowing environment, albeit the cost is almost usurious, at least for small developers. Maybe in the future there would be a wxSharp effort? Not sure how that would work with wxWidget’s message map architecture…
5. I’ve put this up under monodevelop on the ubuntu system, but it’s not working (even though monodevelop says it is. Just copies down the reference .dll’s.Real anxious to get this working on as many platforms as I can.
6. Getting the WordPress rss feed plugin working. That’s the last piece of this blog. It’s installed, it’s recognized, I can set things up, but it doesn’t output anything.
7. Getting that done will finish up the blogging system.

It sounds like a lot, and it is, but it interleaves – a lot of these are embryonic efforts (especially Qyoto) and they require some feedback from forum query’s before I can continue. So, I can drop one while waiting for a response and pick up another. Or pick up the other when I get a neuron spark.

Enough playing around with the Ubuntu installation – I have to fix up a website.

PHP has been great for coding up web apps and even general website stuff. Debugging has been a bit wanky, though – up to now, my methodology has been to include a ‘debug’ class, sprinkle a few statements around (glorified print statements), and then remove them when it’s done. By removing the easily identifiable debug include (do a global search on the .php files), the various debug statements come up unresolved and I can insure they don’t dangle around in the production site.

Honestly, since there’s no heavy compilation step, doing this sort of thing in PHP is blindingly fast – make an edit, refresh the page, and you see the change, instantly.

But, you have to modify the code – sometimes extensively to get down to the problem – and then you have to re-modify it back to where it was minus the bug, once you have the fix.  It’s also a bit tough to do hidden form-response pages, and the like.

A real debugging environment would eliminate those issues.

Zend IDE

So, I popped for the Zend Pro IDE — the pro version supports remote debugging (which I think is essential vs. local. Pages may or may not behave correctly in a local installation, especially on Windows (where the IDE has to reside.) That’s why I put up a developer server – it’s a very close mirror of the production server. Thus, I want to debug on the development server.)

Obviously I use IDE’s for other development environments, but the fact is the edit and turnaround cycle for PHP has been so fast, I’ve put it off, for a long time. Now that I’ve decided to bite off the effort and cost, I’m finding it’s a bit of a hassle to set up, especially for virtual hosts.

Hopefully, it will be worth the effort and cost, once it’s up.