Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • All the interfaces I have built in the last 4 years or so use HTML or the command line (or both).

    Is there going to be an XML section in the cookbook?

    --
    mirod
    • While it is the case that many programmers want to use a browser for an interface, there are considerable difficulties with this approach. First, you have to create a state maintenance mechanism. Second, it's tough to duplicate true application behavior with a Web-based GUI.

      Right now, I'm building a "temporary" CGI application that will be replaced with a desktop app when we have time. Originally, the designers had it create a lot of pop-ups for searching. However, the pop-ups can't be used as a modal dialog box. Further, the pop-ups had to remain if the search failed, or update the parent page if they succeeded. The only convenient way to do that was send all data back to the pop-up and have it update the parent and close itself on success, or to reprompt the user for input. It was such a kludge that I convinced the designer to put the search function on the original Web page and get rid of the pop-up.

      That raised the problem of the DHTML menus not appearing over <select> boxes because of an IE bug that puts the z-index of the select box so high that nothing appears over it. ANd I won't even begin to discuss the horrors of making the DHTML cross-platform (we still haven't succeeded).

      Further, when we had a 500 error, the DHTML menus from one frame wouldn't appear over the 500 error causing us to trap the errors, return a 200 OK status and write things to the log rather than allow proper error handling. Web-based GUIs are quick and easy, but you get what you pay for :) Of course, if you stick with very vanilla HTML, many of these problems go away, but so does fine-grained control over the appearance and behavior of the application.

      • Well, as most of the code I write is of the type "set parameters right, shoot, wait for results, go home" I don't have that kind of problem. Plain vanilla HTML is more than enough for me (for example, I just used multi-valued checkboxes for the first time 1 hour ago).

        I agree that HTML does not give you nearly as much power as a regular GUI. It's just that you don't necessarily need the full power. The added bonus is also that with a web-based interface, users expect the application to be slow (they are r

        --
        mirod