Frequently Asked Questions


What is Bambookit GUI?

Bambookit GUI is a completely XML scriptable java-based GUI toolkit that allows you to create front-ends Internet Applications with rich functionality and high performance similar to desktop applications,over any network connection, from any device.

How does Bambookit work?

Bambookit is activated by Java Virtual Machine, which is present on every browser, every operating system. The Bambookit engine allows you to create applications that are accesible from browsers, desktops, and via any web enabled device. Bambookit renders User Interface with XML.

How big is Bambookit?

It currently stands at 100Kb (v2.0) containing various controls, XML parser, an object enabler and its own event and paint queues.

What browsers are supported?

Firefox
IE 4.0+
Safari
Chrome
Any java 1.1/1.2/1.3/1.4 enabled browser.


Why was Bambookit built on Java?

1. Portability, Java has implementations on largest of mainframes to the smallest of cellphones (Personal Java based). It has truly become a ubiquitous solution.
2. Security, both built into the language, like buffer overflows, and also built into the environment, like the sandbox security model.

Why should I use Bambookit instead of Swing?

1. Swing is ugly! Text is flushed next to borders, spacing between controls is off and the color choice is garish. Essentially it lacks polish, and this lack of polish will directly translate to applications written in Swing.
2. Writing applets requires developers, not just someone capable of modifying scripting languages.
3. Bambookit User Interfaces are XML based scripts. They are easy to read, write and understand. Making them easy to modify and maintain.
4. Developing Bambookit User Interfaces take very little time.
5. Bambookit is written on top of Personal Java (a slimed down version Java 1.1). Thus it can be run off of ANY device that has personal java installed including webpads, cellphones and of course desktops.
6. It is tiny (83k for version 1.6) and loads almost instantly. Making it extremely easy to deploy and maintain.


Why should I use Bambookit instead of DHTML?

1. Bambookit is a compiled library as opposed to DHTML solutions that are fully scripted. Thus all their code is an order of magnitude larger than Bambookit core components.
2. They lack a common library and need to write their own. Of course tested, deployed and patched.
3. All code written in JavaScript is inherently a LOT slower than anything written in a compiled language.


Why should I use Bambookit instead of Altio?

1. Licensing fees are quite high ($25,000 per server the last we checked)
2. Altio's front end REQUIRES a server side installation
3. Altio requires java programmers to create their front-end applications while Bambookit is completely XML scriptable
4. Altio's front-end jar file is 300k as opposed to Bambookit GUI's 100k jar file
5. Altio locks you in to a vendor specific solution.
6. Bambookit GUI controls are more flexible, faster, more responsive and architecturally superior to Altio's controls


Why is Bambookit's communication ONLY HTTP driven?

This is also known as HTTP-tunneling or HTTP piggybacking
1. Proxy compatibility.
A large portion of the world is trapped behind a corporate proxy or firewall. For those people, HTTP is All there is. By being HTTP driven, Bambookit is then guaranteed to work in those environments.
2. SSL enabled.
By piggybacking on the HTTP connection, becoming SSL enabled becomes a trivial operation. All that is required is to place the web page containing the Bambookit GUI onto an SSL server and that is it. No changes will be required to Bambookit GUI.


I get a gray screen?

1. Check to see if you have a java enabled web browser.
2. Check to ensure that java is enabled.
3. Check to see if it is a security exception (open the java console to confirm).
Ever since java 1.2 there has been a change on permissions granted to an applet running from a local machine. In the past local applets were considered safe and thus had access to the hard drive and other system resources. Bambookit GUI files are stored in separate XML files, thus to load a file it would need to read from the local drive. And thus the security exception occurred and the read operation was denied. There are two ways to solve this:
(a) Include Bambookit's directory in your java’s classpath.
(b) Modify the java.policy files located in your java runtime environment:
Open ../JavaSoft/JRE//lib/security/java.policy
and append the following line at the end of the file:
>>
grant { permission java.security.AllPermission;};
<<


When running Bambookit off of my web server I get a gray screen?

1. Make sure it is a java-enabled browser and that java is turned on.
2. If in the java console you get the message “serial check failed” then you would need to purchase a serial number before you would be able to deploy the applet on your server. The evaluation version ONLY works locally.
3. If you have already purchased a serial number, make sure that you copy the text file provided to the SAME directory that you have placed your bambookit jar file in. Then restart your JVM by closing all instances of your web pages (on some machines you would need to log out and log back in to restart the Java Virtual Machine). Then try again and it should work fine.

I'm having trouble with getting the applet to run from a subdirectory. I'm getting "java.lang.ClassNotFoundException: Loader" in the java console.

In the applet tag set archive="../../bamboo_1_6.jar", specifying the exact location of the bamboo jar file. To avoid a caching problem, you would have to close ALL instances of IE. On some machines this might also means logging out (The desktop and IE are run off of the same process).

Any further questions please email us


[Home][Tutorial]
[Demo] [Support]
Reference Guide FAQ Solutions Archives