I’m becoming more of an advocate of namespaces.

Traditionally, they’ve been defined informally by prefixing function and/or variable names with some unique mnemonic – such as ‘Q’ for Qt stuff, ‘wx’ for wxWidgets stuff, or even something as potentially ambiguous as ‘C’ for MFC stuff.

All well and fine and helpful, but you can still run into name collisions. For instance, I was browsing the mac utility headers a while ago and ran into a raft of ‘QT’ names – for QuickTime. Dangerously close to ‘Qt’.

The newer languages, such as C# and Java, enforce namespaces. In C#, you can’t write a single line of code, unless it’s wrapped in a namespace.

The usefulness was heightened for me in a recent project with C#: we were attempting to use an underlying module for statistical binning and drawing. But, we needed a highly optimized version so we could dynamically select bins and draw the results on the fly.

Some customization was in order.

Now, in an ideal world, we would go to the creators, explain what we needed, and collaborate with them to get the enhancements we needed. In the real world, though, the creators are off doing something else highly urgent, and we’re not on their ‘to-do’ list.

So, we did the undesirable: clone the module and get the modifications in, ourselves.

Of course, we didn’t want our version to collide with the older version. How to avoid? Simple: since it’s C#, there’s guaranteed to be a namespace associated with the module. Just change the namespace of our cloned module and proceed.

Voila! (I’m writing this in Paris, so I get to stick in my bit of francaise.)

Of course, things aren’t quite so simple – the binning module used several namespaces (a bit of fragmentation overkill, IMHO), and relied on other underlying modules, which had to be detected and determined if they needed cloning, namespace changes, et al. It still can get pretty ugly. But the namespace feature helped.

Another time when namespaces would have been useful was when a somewhat recalcitrant vendor provided a package with a modified libjpg. Naturally, none of our stuff that relied on libjpg worked any more after we integrated their new code…

After the initial shock and dismay, we had to come up with a solution – the vendor was in Germany and were perfectly happy with the solution, as it was, so were disinclined to make changes. In that case, I think we isolated their libjpg into a fully resolved dynamic library along with their system, and didn’t export the jpeg functions. A pain in the ass, to be sure.

Back then, namespaces weren’t widely supported in the compilers (notably, Microsoft), but had they been, it could have been a better solution. Granted, libjpg is in C, but it can be compiled as C++ and then wrapped in a namespace that would prevent it from colliding with our libjpg (assuming we could get the vendor to cooperate.)

As software grows, and applications become more of a ‘mash-up’ of different modules, namespaces can become an increasingly important construct to eliminate conflicts. For instance, if Trolltech wrapped everything in a ‘TT’ namespace, or, better yet, a ‘TT_QT’ namespace, it would disambiguate them from any other code that might just happen to start with ‘Q’. Like ‘QT’ for QuickTime.

So, in my current effort (creating an extension for Qt), I’m wrapping everything in a namespace (’KIS_QX’). It means users will have to sprinkle ‘using’ statements in their code. A bit onerous, admittedly, but I think utimately that namespace usage is a good habit to get into.

So, I think I finally have the MacBook situation stabilized. The machine is running well, and I’ve been working it pretty hard, usually running two Parallels VM’s and the MacOS, itself. I normally have a second monitor hooked to it for development purposes.  My only complaint is the ‘chicklet’ keys sometimes don’t register a hit.  I have to be somewhat deliberate in my typing.

Been compiling Qt4.3 in various configurations for all platforms, and the huge disk is just gobbling them right up. That’s nice. I understand I can upgrade the memory to 4gb. Have to future that – it’s not in the budget, right now. But I wonder if getting it would allow me to run three VMs at once? I’d like to have the FBSD server, XP, and Ubuntu Linux running simultaneously alongside the MacOS. That might take the next generation hardware leap (which should be out in, what? A week or two?)

I do assiduously avoid getting any liquids near it…

rickb

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