Web architecture with javascript

[Halldor Isak Gylfason]

I am faced with the task of porting a client application to a web
architecture platform, e.g. to make it browser based. The technology I
used was J2EE, e.g. servlets/JSP pages and HTML/javascript.

The application I'm talking about is displaying data from database in
grids, roughly speaking from 3 tables, that have parent-child
relationship between them, and when you click on a row in a parent
grid the content in the child grid should change.

I decided for two design patterns, that I'm now beginning to doubt,
which is the reason I'm posting this.

In order to make the design similar I created a javascript component,
Table using the rather awkard javascript notation for object oriented
programming. The usage of that table is similar to the table in Swing
or SWT:

Table a = new Table()
TableColumn b = new TableColumn(a," Column1);
b.setWidth(100) ;
....
TableItem c = new TableItem(a)
c.setText(["Text for column1","Text for column2"]);

The other design pattern was to use IFRAMEs extensively in order to
make the visual appearance similar to the existing client application,
e.g. that the whole page doesn't refresh, when you do a new query.
The main problem I'm having is that when the result set of a query
that is intended to be displayed in the grids is large, the browser
takes a lot of time just interpreting the javascript.

The general problem with using IFrames is that in order to achieve
correct synchronization between frames you have to resort to cross
frame scripting and unusual method of synchronization because the
programmatic submittal of form is an asynchronous operation.

So now I think I must rethink my design to move more tasks to the
server, and simplify the framing. I wanted to know if someone has
experienced something similar, and could provide some hints.

Regards, Halldor

[Erwin Moller]

Halldor Isak Gylfason wrote:

I am faced with the task of porting a client application to a web
architecture platform, e.g. to make it browser based. The technology I
used was J2EE, e.g. servlets/JSP pages and HTML/javascript.

The application I'm talking about is displaying data from database in
grids, roughly speaking from 3 tables, that have parent-child
relationship between them, and when you click on a row in a parent
grid the content in the child grid should change.

I decided for two design patterns, that I'm now beginning to doubt,
which is the reason I'm posting this.

In order to make the design similar I created a javascript component,
Table using the rather awkard javascript notation for object oriented
programming. The usage of that table is similar to the table in Swing
or SWT:

Table a = new Table()
TableColumn b = new TableColumn(a," Column1);
b.setWidth(100) ;
...
TableItem c = new TableItem(a)
c.setText(["Text for column1","Text for column2"]);

The other design pattern was to use IFRAMEs extensively in order to
make the visual appearance similar to the existing client application,
e.g. that the whole page doesn't refresh, when you do a new query.
The main problem I'm having is that when the result set of a query
that is intended to be displayed in the grids is large, the browser
takes a lot of time just interpreting the javascript.

The general problem with using IFrames is that in order to achieve
correct synchronization between frames you have to resort to cross
frame scripting and unusual method of synchronization because the
programmatic submittal of form is an asynchronous operation.

So now I think I must rethink my design to move more tasks to the
server, and simplify the framing. I wanted to know if someone has
experienced something similar, and could provide some hints.

Regards, Halldor

Hi Halldor,

Javascript is indeed very slow when you need a lot of IFrames communicating
and you have many fields with names (you table-grid is not 4 by 5 I
guess...)
I once faced a similar problem, very similar actually, which was extremely
slow too.
I think my case was easier because I didn't need to add new rows and such
without refreshing, which makes thing easier.
I had a x by y grid that didn't change its size during interaction with the
user. But maybe this helps you going anyway:

The solution I implemented was just a one-page HTML + 1 hidden frame, no
Inner Frames, with named textfields (like col3row8) in a table.
When textfields were changed by the user, I had to recalculate some stuff
and update other fields (just summing and averages, done by Javascript).

When certain other elements were changed, I had to update a dropdownmenu eg,
and needed new information from the database..
This can be accomplished by using a hidden frame, where you can post your
changes and/or query your server, which in turn responds with the new data.
You have to make the response from the server in such a way that it will
call some javascrip-routine when loaded. This javascript must then update a
dropdown or something by adding and removing elements.

It is not easy and you can expect certain troubles when the user is very
active or the server slow with responses. So I blocked userinteraction with
the fields during these kind of updates, otherwise I would still have a
headage. :-)

I hope this helps you a bit.
Good luck!
Regards,
Erwin Moller

[F. Da Costa]

Halldor Isak Gylfason wrote:

I am faced with the task of porting a client application to a web
architecture platform, e.g. to make it browser based. The technology I
used was J2EE, e.g. servlets/JSP pages and HTML/javascript.
I'm using Tapestry, which is an extremely powerfull framework for creating
& running web-apps. It uses any standard web-app server on the frontside
and java and all that comes with it on the backend. Absolutely superior to
servlets/JSP.
The application I'm talking about is displaying data from database in
grids, roughly speaking from 3 tables, that have parent-child
relationship between them, and when you click on a row in a parent
grid the content in the child grid should change.
I'm doing something similar with a TreeTable, the size of which can be 5k+
rows or more (or less, but i'll come to that later).
It is also fed by a db.
Obviously i'm also dealing with parent-child relationships (going down to a
beforehand unknown level).
I decided for two design patterns, that I'm now beginning to doubt,
which is the reason I'm posting this.

In order to make the design similar I created a javascript component,
Table using the rather awkard javascript notation for object oriented
programming. The usage of that table is similar to the table in Swing
or SWT:

Table a = new Table()
TableColumn b = new TableColumn(a," Column1);
b.setWidth(100) ;
....
TableItem c = new TableItem(a)
c.setText(["Text for column1","Text for column2"]);

The other design pattern was to use IFRAMEs extensively in order to
make the visual appearance similar to the existing client application,
e.g. that the whole page doesn't refresh, when you do a new query.
I decided to use as much 'standard' HTML as possible.
So the table is known and all the data is encapsulated by numerous tbodies.
Allowing me to handle distinct 'sub sets' independently of the rest.
The main problem I'm having is that when the result set of a query
that is intended to be displayed in the grids is large, the browser
takes a lot of time just interpreting the javascript.
What i am doing is filling a js array (hashtable like structure) on the
server with the html required for the different rows.
Those entries are written to the screen using the document.write( )
function. The array is stored in a hidden frame (which acts as a function
library as well as data-repository surviving page-sessions).
One only goes to the server for updating (not sending anything back except
errors). Otherwise one just stays client side (also for state)
The general problem with using IFrames is that in order to achieve
correct synchronization between frames you have to resort to cross
frame scripting and unusual method of synchronization because the
programmatic submittal of form is an asynchronous operation.
When someting changes (or a branch get loaded dynamically) I just produce
the proper code on the server (remember the js array), replace the old
tbody entry with the new entry in the hashtable and write the structure out
to the screen again (respecting the old state).

One of the issues I had was the fact that the elements of a document in a
window loose their meaning once the doc is gone. You cannot rely on making
references to any element after the document is gone.

I noted that Erwin uses a hidden frame for server comm and update the
viewable document from there. Sounds fine to me as well. I guess it all
depends on the complexity and size of the structure and the parts to be
updated. I produce all my HTML via Java on the server and just write out a
string on the client. I'm not using any createElement(x yz) js function at all.
So now I think I must rethink my design to move more tasks to the
server, and simplify the framing. I wanted to know if someone has
experienced something similar, and could provide some hints.

One small thing though, i am using Gecko to debug my js. MS however tends
to crap out quite often of stuff which is supposed to be standard. So,
unless you don't care about that just keep it in the back of your mind
(would have saved me a *lot* of rewriting)

Goog luck,
Fermin DCG