Client-side Scripting in DesignBais

DesignBais doesn’t have documented support for JavaScript or VBScript for customized client-side behaviors, but that doesn’t mean you can’t do it. Here’s a discussion on the topic.

One of the main purposes of JavaScript and VBScript is to put code into the client to avoid a round trip to the server – specifically to avoid a full page refresh. With Ajax techniques allowing us to use the server fairly painlessly, the need for scripting in average pages is greatly diminished.

I won’t take a firm stance on a position that we don’t need scripting, because there are times when it is much more efficient, or at least it seems elegant, to just put in a little scripting rather than making a round trip to the server.

The Position of DesignBais International

The DBI position is a bit more firm. They don’t support client-side scripting for a few reasons.

Interference with DBI code

There is a possibility that client-side scripting will interfere with the code that DesignBais itself generates and uses to manipulate pages. If a developer’s code conflicts with DesignBais code, DBI will get the support calls. The current stance is that DBI would rather have full control and responsibility for the client-side environment, and if there is anything wrong with their code they will fix it or make enhancements, rather than expending effort on problems caused by someone else’s code.

Why do we need scripting?

Support for client-side scripting implies that pages deployed with DesignBais need such a thing. That might be a faulty assumption.

The goal of DesignBais is to satisfy all needs of a real business application. What might someone truly need to do in a business application that requires client-side scripting? What limitation in DesignBais needs to be overcome? I’ve been hard pressed to answer this question myself. In a real business application where the end-user is doing data lookups and entering transactions we don’t need rotating banners or stock tickers. DesignBais already includes support for menus, dialogs, collapsing sections, hidden and disabled fields, clickable dynamic images and many other behaviors, so custom scripting just doesn’t seem necessary.

The DesignBais target audience doesn’t script

The target audience for DesignBais doesn’t know anything about scripting and an application that uses DesignBais along with custom scripting is un-maintainable by that target audience.

I need to approach this carefully. You as an individual and the decision making authority might be well versed with all forms of client-side browser-specific scripting. You as a developer might be providing solutions for your end-users and you want to take advantage of your extensive knowledge in the field. But next month or next year, who will be maintaining the code you’ve written? Most of my clients want to own their software assets. Many of them want sophisticated user interfaces but don’t have the skills to maintain them. They want me to kick-start their development process but they don’t want to have to call me to make a small change to some page. There’s nothing wrong with this. Remember that one of the original reasons why we all like Pick is that we can quickly make ad-hoc changes. The average programmer who learned about computers through pick BASIC knows nothing about cross-browser compatible JavaScript or VBScript. If I or another developer puts script into their baseline code, they now have another language to learn in order to maintain their software assets. This defeats some of the benefits of the Pick model for quick ad-hoc changes and of DesignBais as a tool for the average Pick developer.

My idea of a successful project is one where the client doesn’t need me when the project is complete. I’m all for anything that minimizes post-project maintenance because I like to work on new projects. By using JavaScript, VBScript, Perl, PHP, VB.NET, or C# in code that is intended to be "owned" by an end-user or someone else, I’m imposing a requirement upon them to learn my tools of choice. That’s not fair. Projects that use these languages must be agreed upon prior to development. It would be very bad if I were to write source code for resale or for someone else’s maintenance using a language that my target audience doesn’t understand – that compels decisions on the part of my clients to learn the language(s) or simply not buy my software. I’d much rather completely avoid this situation and keep everything in pure Pick BASIC.

4 thoughts on “Client-side Scripting in DesignBais

    • Tony,
      We at Laner Electric are currently evaluating DesignBais, which is what caused me to stumble across your blog in my research. Good Job!
      An issue that is tangential to THIS blog topic: Have you found any way to make an iframe to render on the page WITHOUT the bounding box? I’ve looked into this a bit (when trying to insert a PICK generated html snippet – specifically a table of reference information) and couldn’t find a way to turn off the visual bounding box.
      On second thought, this might NOT be an issue since we can use the technique you demonstrated for displaying "This came from js.html!" to embend the HTML for the table.
      Again – Thanks!! — Steve

    • Hi Steve – welcome to Neblog, and thanks for your comment and question!!

      Check the frameborder=0 attribute of the <iframe> tag in the first example. I intentionally removed the border from the first example and left it in the second. If you’re doing a table then you can similarly remove borders or change their width. You can also change background colors to try to get a uniform look across the page, and eliminate a coloring difference which might be a visual clue that an iframe is present.

    • Tony – Kewl – Thanks! Frankly, I was just struggling to USE it to imbed a .htm file and never got around to looking at the formatting options.
      One thing I DID find is that for iframes to work correctly from ie 6, then the url has to be from the same site as the page that embeds it. So if I want to programmatically generate html on the fly for imbedding using an iframe, I have to write it to a file that is within the url tree. Will probably somehow attach a network drive (which is actually a samba share) as a directory somewhere UNDER the root of the website running on WS2k3.
      Of course, the inability to have a url from another site COULD be just an artificate of my own IE6 security settings, but since I never tried to look deeper, I just may not have found the solution to THAT problem.

    • Hi Steve – yes the problem you are having wioth iframes from another site will be due to your ie6 security settings.The most common error is if a web page from one zone has an iframe from another then it will give you an error message. e.g. if  your designbais site is internet and your iframe is coming from your trusted sites. Make sure both sites are in the same zone.If there are still problems then there are a plethora of security settings that you may need to take a look at.Having said that, as you say above, the samba share and IIS virtual direcotry work well anyway.rgdsSymeon.

Leave a Reply