Glom Web UI

If nobody else gets around to it, I might have to implement the Web interface for Glom myself. But I haven’t done web programming recently and I’m very out of touch with the latest stuff. The last time I did any, JSP was the nobody-ever-got-fired-for choice.

It just has to read the Glom .XML file and from that allow people to navigate through tables and records, getting and setting the data from the database, laying the fields out appropriately as per the simple Glom layouts.

Feel free to add comments to tell me what the latest popular proven technologies are. Note that I’m not interested in using .Net or Mono, and I’d rather avoid relatively new programming languages like Ruby, or APIs that were invented last week. Python would be nicely middle of the road if there’s some suitable APIs for it. It might be nice to be able to call a C++ libglom library, to reuse some logic.

I’m not going to do this any time soon. (Unless someone pays me for it. As ever.)

Update: I’d like to have a nice AJAXy responsive UI, so I can, for instance, update a list of choices in one field based on what the user has just entered in another field. A small delay would be acceptable, but a page refresh would be annoying. But I don’t want to write any javascript myself. It would be nice if I could just have all that hidden inside some widget objects, like using GTK+ that renders itself to a browser.

7 thoughts on “Glom Web UI

  1. Check out DWR — it is a really simple bridge that lets you call server-side Java methods from Javascript running in the user’s web browser. You don’t have to write complex Javascript, all HTML can be generated server-side, the Javascript just allows you to replace nodes of the current page with whatever the server sends you.

  2. I have been playing with quite a few Python frameworks and both Pylons and TurboGears are very nice. Pylons is good because of the WSGI support and its excellent integration with eggs. TurboGears is very nice as well and in fact has started to support a widget based design for forms that seem promising (I am using it now). One interesting thing about TurboGears is that it was written to support a web application meant to be run on the desktop (Zesty RSS Reader).

    The bad news is that you will have to write Javascript if you want AJAX features. The good news is that the current libraries such as MochiKit and Prototype make programming in Javascript much nicer. In fact I have really been enjoying Javascript, which is rather a big surprise.

  3. Well, CPPSERV is a good base for writing web applications in C++, and it now even supports
    CSP (C++ Server Pages). However, we do not yet have any AJAX framework around it.
    That will probably come about later one – either when we are ready to start working on
    some project that really requires such thing, or if there is someone willing to pitch in and
    contribute at least a good design document for such a framework.

Comments are closed.