Well, I’ve upgraded my FreeBSD server and everything is back in order, including a new version of WordPress.

And, I’ve reinstated the comments mechanism (restored the DB table) and installed the reCaptcha mechanism. So far, so good – spam appears to be throttled, but not completely eliminated.

At least it’s manageable.

On AJAX

I’m kind of mystified why so many sites haven’t incorporated AJAX – a lot of really big sites still do a full page refresh when something is updated. I can’t attribute it to ignorance, so it must be … dare I say … laziness?

Some notes on my approach to AJAX:

1. A lot of the AJAX libraries descend into baroque-ness, normally pointed toward updating parts of the page with HTML snippets. The MS implementation seems to be the worst offender. This seems like a bad idea, to me.
2. To maintain presentation/logic separation we like so much in architecture circles, you don’t want to be passing UI stuff over the wire – the only possible exception is if you’re creating all of your UI on the wire (which strikes me as prime fodder for loading up the server, so I don’t like to do that, anyway…)
3. JSON is the lingua-franca of AJAX, not HTML. Better to pass JSON-encoded data back and forth and let the server and the client handle their ends appropriately. I’m a big fan of off-loading as much as possible to the client, anyway. Stuff like forms validation should be done – at least preliminarily – at the client. The client should re-arrange itself based on JSON responses and data.
4. You never know what the next new big thing is. You’re client might be written in JS, now, but tomorrow’s need may likely be Flash, Silverlight, or who knows what? Passing back and forth snippets of JSON and keeping the semantics simple doesn’t break the back-end, or entail hoops trying to support multiple types of clients.
5. There’s nothing better than updating just part of a page. Full page refreshes are jarring.

I’m sure there are exceptions (there always are), but that’s the way things appear to this author, as of this writing.

… and with our coding dead… (with apologies to Shakespeare).

Again, I haven’t been keeping this up.. why? Spam is driving me crazy. I’m currently upgrading the server and will put in a captcha to re-implement comments. After all, what’s a blog without feedback?

Adobe Flex/Flash

On the development side, I haven’t been dormant: I’ve been investigating the new Flash and Flex technologies from Adobe.

Since Adobe took over Flash from Macromedia, there has been an all out push to turn the Flash technology into a bona-fide development environment. That makes it a candidate for investigation (especially to one who professes to be a graphics developer.)

The outcome? You can see one outcome on Facebook (this is also an exercise in exploring the ’social media’ platform): Active Biorhythm. It’s pretty cute – if you’re a Facebook user, you should be able to fire it right up (you might need to log in, first.) The first tab shows your six most compatible friends for varying attributes with a series of (active, of course) venn diagrams. The second tab shows your personal values with (active, again) bar-charts. (The ‘in-tip’ value labels is a nice touch…)

The third tab is the most interesting in terms of potential applications, IMHO: Think ‘Google Analytics’ type charting, with active information popups at appropriate places. As you hover over a curve, for instance, the other curves fade into the background and data at that point is reflected in an ‘info balloon’, which has a connector to the table readout value below, for good measure.

The current date can be changed by grabbing the red cursor and dragging it, or by hovering over the pointers on the sides of the graph. A friend can be loaded, either from the compatibility panel or from the name panel on top, and the chart will show comparison values, as well as a drop-down ‘compatibility panel’ for all attributes.

It’s an interesting demo of how to show a lot of information on a graph, without cluttering it up with legends, etc. I’m sure a graphics designer (which I don’t profess to be) could think of some very interesting possibilities. It needs a bit of work, still, but it’s quite functional.

The next exploration in this (Flash/Flex) technology will be a 3d library which has been built on top of Flash, talking directly to the GPU . From what I’ve seen, it looks very promising.

Aside: ActionScript3 is ok – it’s an ECMA-derived script, so there are a lot of familiarities. The only thing I don’t like is the kind of backward typing statements (typing, in and of itself is good, of course).

For instance, to declare a variable of type ‘String’ looks like thus:


var myVar:String;

Nothing wrong with that, but say this is local to a function and you want to promote it to class scope. What you need to do is remove the ‘var’ and the ‘:String’ so the lvalue in the assignment doesn’t have the type/instance declarations – that’s a two select-and-click process (other languages the type/instance declarations precede the variable name – one select-and-click to remove.)

No biggee, just a little bit of a nuisance.

Working with the FlexBuilder development environment is much better than working in the Flash Authoring Tool. The latter doesn’t help you very much — FlexBuilder is Eclipse, so it helps a lot (although not as much as it does with Java.) The only issue is that it produces large .SWF files, compared to those created with the FAT.

So, onward. I’ll be working the rest of the day putting in a ‘captcha’ and updating the wp software so comments can be left.

You will be free to add illuminating remarks when that’s done.

… but no spam!!…

(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.

(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.)

In my latest web project, I’ve been working on a set of forms for user registration and information. No great shakes there, of course, but, as I was working through it, I realized a couple of things I wanted to have:

• I wanted to disambiguate some of the input entries on the form – some are not relevant, unless the user checks an option.
• In a ‘history’ table, I wanted to dynamically add static rows as the user entered information, and I wanted the rows sorted in reverse by time, and I wanted the entries to be editable after the fact, including the time entries.

Initially, this suggested an AJAX solution, and I started going in that direction.

Not Necessarily AJAX

As I proceeded into the implementation, I realized I don’t really care about intermediate results – the user can edit his brains out for three days straight, for all I care. The only thing I’m interested in is the end result.

Sensibilities vary in this regard: Some schools of thought advocate controlling everything from the server. Others advocate controlling as much as possible from the client – at least the display portions.

For this project, I fall very much on the latter side. I’d rather do as much as possible in the user’s browser. For one thing, this saves bandwidth and server load, which, for me, is a limited resource.

The Implementation

I’ve divided the demo into three sections. The first two deal with restricting available choices:

Section One:

This takes the approach that what the user doesn’t see, he can’t enter. Irrelevant inputs are simply not existent until the user pushes the controlling option.

This works, but the result is that other elements on the form can jump as the form re-lays itself out to accommodate the new pieces or the removed pieces.

Section Two:

This takes the approach that the input elements should always be visible, but are inaccessible (when not relevant) via a disabling mechanism. They are grayed out to reflect their status.

The first makes sense for large blocks of controls, such as a choice of payment schemes. A PayPal vs. Credit Card scheme, for example.

The second makes more sense for small groups of controls, and reflects more what a user might expect in an application.

Interactive Table

The last section is the interactive table input. The first row is an input row. When the ‘Add’ button is clicked, a static row of information is added to the table. The rows are dynamically inserted in reverse order, by date – much as you would expect a resume or medical history.

Finally, I wanted the rows to be editable. The first approach was to provide an ‘Edit’ button for each row: clicking on this removed the row and put the data back into the input row, which the user could edit and then re-add via the ‘Add’ button.

That worked, and it was a good intermediate solution, but I wanted a better solution: I’d rather have the row editable in-situ.

This led to the final implementation: the user can now click on a static cell, and the content is temporarily replaced by an appropriate control set to the current contents. The user can edit, and when the control loses focus, it is removed from the cell and the static contents updated.

This works pretty well (tested on the latest versions of IE, FireFox, and Safari.) It could be prettied up some more (likely will be in the final implementation). One concern is that the rest of the contents of the form will jump as rows are added and removed. I think this can be addressed by setting the static part of the table to a fixed size and allowing it to scroll.

Next: Data in, Data out – a bit of AJAX to help the demo.

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.