Java & JavaScript

Use Java & Java Script To Enhance Your Website.

How to test for the Javascript DOM?

By Riaan Pieterse

Browsing the forums, development articles and other resource sites raised an interesting yet recurring question: "How do I test for the Document Object Model (DOM) employed by a browser?". Strangely enough I was asking the same question when starting out in Javascript. However, after enough time has passed, with the same thing done more than once, I started to realise that this is a question that begs answering for once and for all.

A Typical Test

Testing for the DOM in itself is easy enough. A recommended approach is
testing for the support of a DOM, and not for a browser
version. The following describes Boolean variables that indicates the compliance
to
the DOM methods and parameters that you are targeting:

The above items return a set of true or false values for any browser. This
method still requires that you access objects described by the DOM through
that DOM's methods. In the long run the amount of work you have to do
remains more or less the same.

Javasript is an Object Orientated language

Everyone who is familiar with Javascript knows that the language supports Object Orientation (OO). Passing objects around in variables is nothing new, so why do people persist in performing lengthy tests for the DOM each time we need to access an object?

The item which describes the document's referencing structure is nothing more that an object itself. This means that you only need to perform the test once, and then proceed to use an arbitrary object that describes the DOM object throughout the remainder of your script. However, since this approach would require that you define a variable for each and every object you will be referencing, we need an approach which is more robust.

A Compromise

Typically you access objects though the DOM for one of two reasons: Get a value, or Set a value. Previous approaches require that you access the object through the DOM methods each and every time you need to perform some action on the object. The same holds true for every other object accessed by your script. What we need is a method that will:

1. Access the correct DOM using the relevant methods
   
2. Return the object of interest
   
3. Not waste time and patience

A practical approach used by myself is described in a function that returns your object without any hassles.

The above function comprimises by using the typical test defined earlier to identify our browser DOM, and returns the object identified by its ID / NAME pair. So whenever you need to do something to an object, this approach requires that you call the getDOMObeject () function. For example, the following will set the value attribute of a hypothetical text box to 'test value'.

The value of this approach comes to the front in scripts where you need to access multiple objects in your document. For example:

Looks like a lot less work, doesn't it?

About the Author
Riaan Pieterse is the CEO and founder of Kerberos Internet Services CC, South Africa. Having spent a number of years conducting various consulting assignments in the Far East, Middle East, Africa and Europe to businesses and governments alike, Riaan has a solid understanding of the business and technology issues in today's market.
For more information visit www.kerberosdev.net or www.kerberosb2b.com

Performance Tuning of a Daffodil DB / One$DB -JDBC Application

By Parveen Aggarwal

This article illustrates the best practices to improve the performance of Daffodil DB / One$DB JDBC Driver. This article focuses on how to improve the performance of a Daffodil DB / One$DB JDBC application using Statement, PreparedStatemnt, CallableStatement and ResultSet interfaces. Choosing the right statement interfaces and right methods according to your SQL query plays a vital role in improving the performance of a JDBC Driver.

JDBC Overview

JDBC API provides standard set of interfaces to work with databases like Daffodil DB / One$DB, Oracle, Derby etc.

Connection interface encapsulates database connection functionality, Statement interface encapsulates SQL statement representation and execution functionality whereas ResultSet interface encapsulates retrieving data which comes from the execution of a SQL query using Statement.

Following are the basic steps to write a JDBC program.

1. Import "java.sql" and "javax.sql" packages. (Import "javax.sql", if advanced JDBC feature like XA is to be used)

2. Load Daffodil DB JDBC driver (embedded or network JDBC Driver)

3. Establish connection to database using Connection interface

4. Create a Statement

5. Execute the Statement

6. Retrieve results by using ResultSet interface

7. Close Statement and Connection

Choosing right Statement interface:

There are three types of Statement interfaces in JDBC to represent/execute a SQL query-Statement, PreparedStatement and CallableStatement. Statement is used for executing static SQL statement with no input and output parameters; PreparedStatement is used to execute dynamic SQL statement with input parameters whereas CallableStatement is used to execute dynamic SQL with both input and output parameters. One important thing to note about PreparedStatement and CallableStatement is that they can also be used for static SQL statements. However, CallableStatement is mainly meant for stored procedures.

PreparedStatement gives better performance when compared to Statement because it is pre-parsed and pre-compiled. This means that compilation and parsing of such statement is done only once by the database. Afterwards the database reuses the already parsed and compiled statement. This significantly improves the performance because whenever a statement has to be executed repeatedly, it doesn't need to be parsed and compiled time and again. So the overload incurred by parsing and compiling the same statement can be reduced.

When there is a requirement for single request to process multiple complex statements, CallableStatement gives better performance as compared to PreparedStatement and Statement.

To read the full article please visit http://www.daffodildb.com/daffodildb-performance-tuning.html


About the Author
This article has been contributed by (Mr.) Parveen Aggarwal, Technical Consultant to DSL India ( http://www.daffodildb.com ). With more than 6 years of industry experience in Java and allied technologies, he has an in-depth understanding of J2EE, J2ME and database management systems. Parveen is currently working on the concept of data-archiving in embedded databases. He can be contacted at [email protected]

Google and Sun - a partnership to kill Microsoft or a deal with the devil?

By Rob Sullivan

As you have probably already heard, Google and Sun have partnered up to distribute the Google Toolbar with Sun's Java. While this may seem like a minor deal in the grand scheme of things, upon further reflection I find this could be the deal which will ultimately break Microsoft.

While the implications could be huge and far reaching, only Google knows for sure what it wants. We can speculate however and that's what this article is all about. Is such a deal good for Sun (and Google) or is it a pact with the devil?



At first glance, such a deal doesn't seem like much. After all java to most people is just a plug in for your Internet browser. What good would such a deal be to Google? Well lets take a look at what Java can do. The following is taken straight from Sun's website:

The Java programming language is robust and versatile, enabling developers to:
Write software on one platform and run it on another.
Create programs to run within a web browser.
Develop server-side applications for online forums, stores, polls, processing HTML forms, and more.
Write applications for cell phones, two-way pagers, and other consumer devices.

Let me break this down for you point by point:

Write software on one platform and run it on another

To me this says it all platform independent applications. What is one thing Windows does well? The programs generally run only on Windows. Developers usually have to port applications to run on other operating systems like Mac or Linux. But an application built on Java can be run on any platform regardless of the architecture.

Create programs to run within a web browser

This is an area Google lacks in somewhat. Sure they own search and have some great web based applications such as Gmail, but there are so many potential other web based applications out there. From web based collaboration software to web based application suites (such as office applications). The possibilities are endless.

Develop server side applications

Again, since Java is platform independent, different types of server applications can be built for websites regardless of their operating system. An E-commerce system could be developed which would easily plug into a website whether it was ASP or PHP based. This would be a huge competitive advantage for Google.

Write applications for...consumer devices

Portable web is the future. There is no doubt about it. Rather than building mutiple platform dependent applications, one could again develop a java based platform independent application. Since it's independent it can not only run on your desktop or within your web browser but also your cell phone, blackberry or PDA.

So, now that we know what Java can do, lets take a look at what Google can do with Java:

Compete on the Desktop

Virtually any application could be ported from it's current Windows based version to a platform independent Java version. Even current Google applications like Picasa and Google Earth could now be available to non-Windows users.

Obviously, there is a potential to compete with current Microsoft products as well. The first that comes to mind is Microsoft Office. One would expect this to be one of the first areas Google moves into.

Imagine the potential though. I think of how good that would be just for me personally. My computer runs Fedora (a version of Redhat Linux) yet for other reasons (games) my son's computer runs Windows XP.

When he needs help with homework it can be trying because he uses Microsoft software and I use open source. If we could collaborate on something which doesn't care what OS it runs on, it would make our lives so much easier.

And that leads to my next point collaboration.

Compete with future Microsoft products

One thing Microsoft has been getting better at, but is still lagging in, is online collaboration. Sure they have Exchange Server and Sharepoint, but those systems are somewhat cumbersome and don't always play together nicely.

But imagine a system which is (again) platform independent and web based and allows collaboration among multiple users from different areas using a shared application base. The system could incorporate version control for shared documents, as well as calendaring, email and other communications.

This system could be hosted by Google (of course) but be open to who you want. In other words, you could openly collaborate with clients, or co workers regardless of what system you are using you could connect and read email with your PDA, schedule appointments with your laptop and even have a Google Talk VOIP conversation with your cell phone. The possibilities are endless.

Take Over the Desktop

To go even a step further, what if Google built a small lightweight version of Linux that hosts links to web based versions of the Java applications. You could then have this light Google Linux stored on a USB device.

That way, no matter what computer you use, you could reboot it into the USB version of Google's Desktop and have all your customizations and settings just like you would at home or the office.

You could borrow your neighbors laptop or even go to the local Internet cafe and reboot into "Glinux" to read email, respond to appointments and even have a virtual conference via Google IM.

Again, depending on how aggressive Google wants to be (and I bet you they are very aggressive) Google could become a viable alternative to Microsoft. And not just Microsoft applications but Microsoft as a whole.

Google could take over the desktop (or at least temporarily supplant it) as well as any MS based application.

This is the true power of the deal today. While it make take months or years to see the first "real" Google/Sun java application, I do expect to see them taking aim at Microsoft and what it has accomplished.

Because this is still all in line with Google's mission of making the worlds information universally accessible.

All I can say is I hope Bill Gates has a big enough war chest because he's going to need it.


About the Author
About the author:
Rob Sullivan - SEO Specialist and Internet Marketing Consultant. Any reproduction of this article needs to have an html link pointing to http://www.textlinkbrokers.com

The future of software development according to seppia.

By lorenzo puccetti

• Don't write your application. Assemble it
  
  Let's face it: whatever application you have in mind you are going to need some third party software.The more sophisticated your application, the more third party software.
  
  If you don't agree and you think you can write a new application all on your own (or with your team of faithful followers) we probably should be more clear about what we intend by "application". Here we are talking about a piece of software that does its job: one that is used by people who find it useful, reliable and functional. We are talking about building quality software delivered in time. We are talking about flexible software that is easy to maintain.Yes, because when successful software is delivered , it's not "thank you very much and good night" but it demands to grow and it does grow...
  
  Now unless you were on the moon in the last few years you must have noticed that there has been a proliferation of many jars, APIs, open source projects, freebies,... all of them few clicks away from you.
  Now some are good and some are very bad.
  You want to write an application, you need to learn to choose the good ones from the bad ones.
  Familiarize with them, study them, make them interact with each other and write the least amount of code. Yes, because that is the only code you might want to debug.
  
• Make your application classpath-less
  
  I know you learnt java and you know how to set up your classpath. I know you have probably answered the questions of some of your colleagues asking why they were getting a java.lang.ClassNoDefFoundError you are missing such and such jar - was your answer.
  Sometimes was even more tricky: you are use using an old jar... you need to use version such and such .
  
  Too sad. That's not the way forward. Those embarassingly long classpaths that you need to manually change on every installation because your client is using a different jms, jdbc, or whatever else...
  
  Did you know that you could write a tiny program that containing only imports from the core J2SE APIs. and using a URLClassLoader can load all of its Java resources (jars included) from subfolders. That bootstrap program can then launch any application.
  
  Incidentally this is how both Seppia and the Eclipse Plugin Architecture work.
  
• Glue your component-based-software together with Javascript
  
  How many times have you heard of component based software ? Plugin architectures ? Modularity ?
  Loads.
  So what's the problem with them ? None.
  So why should your application be different ? It should not. End of the story !
  I know ... I know you have been too busy building your application that you forgot to think of its foundation.
  
  So what exactly is a module in seppia ?
  A module is that "piece" in your software that provides certain functionalities via some javascripts. The javascript code can access the classes of the jars associated with the module and easily perform its task. It can also delegate some of its work to other javascripts or other modules (more precicely other javascripts in other modules).
  Did you get it ? Probably not... don't fool yourself. Read it again:
  A module is that "piece" in your software that provides certain functionalities via some javascripts. The javascript code can access the classes of the jars associated with the module and easily perform its task. It can also delegate some of its work to other javascripts or other modules (more precicely other javascripts in other modules).
  
  Now at this point there is the most frequenly askes question: Why javascript to define the functionality of a module why not to use XML ?
  We like XML but we are not XML addicted. We like using XML when we need to use it but not when it's not its natural place * .
  
  If you want to glue a few jars together and provide a new service we want to achieve this by
  1) placing the jars in one folder
  2) write one or few javascripts that create java objects, interrogate them and handle naturally any conditional step.
  
  Too often people are over-eager to use XML configuration files, while a scripting language makes a straightforward and powerful configuration mechanism.
  
  Have you read this far ? Thank you very much dear reader. We hope you will enjoy Seppia as much as we enjoy writing it (that means a lot). All The best.