AJAJS - thin client web app using mainly XMLHTTPRequest and eval()

T

timsamshuijzen

I was wandering what the Javascript/Ajax community think of a rather
unusual
method I am using to develop my new web app. At least I think it is
unusual
because I have not yet found much about this exact method on the
internet.
My web app uses no HTML templates and neither does it use any CSS
files.
It is totally JS/Ajax driven, and there are totally no page fetches/
reloads
(single page interface). My initial page looks a bit like this (the
only html
code in my whole app!):

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title></title>
<script type="text/javascript" src="./js/init.js"></script>
</head>
<body>
</body>
<html>

The init.js is a small script that starts it all up. It does a
XMLHTTPRequest
to a server-side application that only outputs JS code. ALL returned
content
is passed into eval() (I actually do not need to call eval() directly
because
the Content-type is "text/javascript"). The first JS code that is
returned
builds up the whole page, loads some simple libraries, and registers
some
events to observe. From then on, ALL events (except for simple things
like
resizing) are sent to my server application which then outputs more JS
code
that get executed back on the client. For example, a user clicks on a
button,
the request is sent to the server which then returns some JS code to
build
a message dialog and register the corresponding message handlers, and
so on.

Therefore, for every event, the browser "asks" the server what to do,
and the
server tells the browser directly what to do with a snippet of
Javascript.

This has great advantages for me as I now have all my layout, model,
business
logic, etc. in one place. It is like "lazy loading", but an extreme
form.
One might think that it could run quite slow because it connects to
the server
for every user-action, but the returned pieces of code are small
pieces of
code, so the speed is actually quite impressive. This setup results in
an
extremely thin-client. I am very pleased with the first results, and
it makes
the whole development experience much like my original profession:
building
client/server desktop applications.

This is probably a sort of controversial method because I noticed that
there
are mixed opinions about using the eval() function to execute code.
Ofcourse,
the returned code comes from my own server (same origin policy), so no
major
reasons for concern. Another point of criticism is possibly the fact
that I
do not use any (X)HTML templates or CSS files. This aspect is
something I
actually like very much, as I can now build and position all
components with
code, instead of looking all these things up in HTML and CSS files
(great
for website design, but not for desktop-like application development).

So, my questions to you all are:

- what do you think of this strategy?
- If this strategy has already been discussed before, then what is it
called?
(I am calling it AJAJS for the time being (not AJAJ which is JSON
oriented)).
- Where can I find more information about this?
- Are there already existing frameworks based on this?
- Do you think that browsers will continue to support eval(), and not
depreciate
it in the future for security reasons?
 
T

timsamshuijzen

(Oops, sorry for the messy layout of my message. I now know that I
should not wrap the texts myself when posting here.)
 
C

Captain Paralytic

I was wandering what the Javascript/Ajax community think of a rather
unusual
method I am using to develop my new web app. At least I think it is
unusual
because I have not yet found much about this exact method on the
internet.
My web app uses no HTML templates and neither does it use any CSS
files.
It is totally JS/Ajax driven, and there are totally no page fetches/
reloads
(single page interface). My initial page looks a bit like this (the
only html
code in my whole app!):

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title></title>
<script type="text/javascript" src="./js/init.js"></script>
</head>
<body>
</body>
<html>

The init.js is a small script that starts it all up. It does a
XMLHTTPRequest
to a server-side application that only outputs JS code. ALL returned
content
is passed into eval() (I actually do not need to call eval() directly
because
the Content-type is "text/javascript"). The first JS code that is
returned
builds up the whole page, loads some simple libraries, and registers
some
events to observe. From then on, ALL events (except for simple things
like
resizing) are sent to my server application which then outputs more JS
code
that get executed back on the client. For example, a user clicks on a
button,
the request is sent to the server which then returns some JS code to
build
a message dialog and register the corresponding message handlers, and
so on.

Therefore, for every event, the browser "asks" the server what to do,
and the
server tells the browser directly what to do with a snippet of
Javascript.

This has great advantages for me as I now have all my layout, model,
business
logic, etc. in one place. It is like "lazy loading", but an extreme
form.
One might think that it could run quite slow because it connects to
the server
for every user-action, but the returned pieces of code are small
pieces of
code, so the speed is actually quite impressive. This setup results in
an
extremely thin-client. I am very pleased with the first results, and
it makes
the whole development experience much like my original profession:
building
client/server desktop applications.

This is probably a sort of controversial method because I noticed that
there
are mixed opinions about using the eval() function to execute code.
Ofcourse,
the returned code comes from my own server (same origin policy), so no
major
reasons for concern. Another point of criticism is possibly the fact
that I
do not use any (X)HTML templates or CSS files. This aspect is
something I
actually like very much, as I can now build and position all
components with
code, instead of looking all these things up in HTML and CSS files
(great
for website design, but not for desktop-like application development).

So, my questions to you all are:

- what do you think of this strategy?
- If this strategy has already been discussed before, then what is it
called?
(I am calling it AJAJS for the time being (not AJAJ which is JSON
oriented)).
- Where can I find more information about this?
- Are there already existing frameworks based on this?
- Do you think that browsers will continue to support eval(), and not
depreciate
it in the future for security reasons?
Click to expand...

This strategy looks very similar to XAJAX and also to the way that
Google Mail works.
 
P

Peter Michaux

Hi,

I was wandering what the Javascript/Ajax community think of a rather
unusual
method I am using to develop my new web app. At least I think it is
unusual
because I have not yet found much about this exact method on the
internet.
My web app uses no HTML templates and neither does it use any CSS
files.
It is totally JS/Ajax driven, and there are totally no page fetches/
reloads
(single page interface). My initial page looks a bit like this (the
only html
code in my whole app!):

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title></title>
<script type="text/javascript" src="./js/init.js"></script>
</head>
<body>
</body>
<html>
Click to expand...

On request, I'm writing one of these sort of pages now (and it is a
lot of fun!) It is for a back-end tool that requires login for IE6+/
FF2+/O9+/S2+ only with images, CSS, and JavaScript enabled.

The page I am writing is _not_ something for general Web consumption
where users may/may not have images/CSS/JavaScript and may have
various levels of support for each of these.
The init.js is a small script that starts it all up. It does a
XMLHTTPRequest
to a server-side application that only outputs JS code.
Click to expand...

This means the JS code is probably not cachable. That's bad for
performance. Better to have a build system that just puts the
JavaScript init.js call directly in init.js itself. Then you can play
caching games like name the file init-23456436.js where the number is
a timestamp of the last build. You can have the server set far-future
cache expiration.
ALL returned
content
is passed into eval() (I actually do not need to call eval() directly
because
the Content-type is "text/javascript").
Click to expand...

Ajax doesn't autatically call eval() if the Content-type is "text/
javascript". Who calls eval() for you? Are you using a JavaScirpt Ajax
library like Prototype? If so that is something to change pronto.

The first JS code that is
returned
builds up the whole page, loads some simple libraries, and registers
some
events to observe. From then on, ALL events (except for simple things
like
resizing) are sent to my server application which then outputs more JS
code
that get executed back on the client. For example, a user clicks on a
button,
the request is sent to the server which then returns some JS code to
build
a message dialog and register the corresponding message handlers, and
so on.
Click to expand...

This sounds like Rails RJS. This style is fine for some applications
but some folks here will say that this tight coupling by using
language response is bad and a data response is better. If the server
never reuses the templates that build up the JavaScript response, then
it may be more flexible to send the data back to the client and the
client decides what to do with that data.

Therefore, for every event, the browser "asks" the server what to do,
and the
server tells the browser directly what to do with a snippet of
Javascript.
Click to expand...

If these events need to interact with the database then you must
contact the server. Only pester the server if there is the event
handler needs some information you can't reasonably load into the
browser. Looking up phone number, for example. You can't load the
phone book into the browser in a reasonable time period.

This has great advantages for me as I now have all my layout, model,
business
logic, etc. in one place.
Click to expand...

"One place" isn't the important concept in the DRY principle. If you
write your server-side in JavaScript then you can share code with the
client, have a thicker client and still be DRY. This is what I'm
shooting for eventually.

It is like "lazy loading", but an extreme
form.
One might think that it could run quite slow because it connects to
the server
for every user-action, but the returned pieces of code are small
pieces of
code, so the speed is actually quite impressive. This setup results in
an
extremely thin-client. I am very pleased with the first results, and
it makes
the whole development experience much like my original profession:
building
client/server desktop applications.
Click to expand...

With caching tricks you can make the second load of the page very
fast. I wouldn't worry so much about how thick the client is because
even a relatively thick client like GMail loads sufficiently fast for
me given how long I keep the application open.

This is probably a sort of controversial method because I noticed that
there
are mixed opinions about using the eval() function to execute code.
Click to expand...

A lot of fuss is made here about that. The recent comp.lang.javascript
archives are full of discussions. Search for "Randy Webb script
insertion" or similar.

Ofcourse,
the returned code comes from my own server (same origin policy), so no
major
reasons for concern. Another point of criticism is possibly the fact
that I
do not use any (X)HTML templates or CSS files.
Click to expand...

Don't use XHTML for the Web if Internet Explorer is involved.

http://www.thewebcreator.net/2007/04/16/why-you-should-be-using-html-401-instead-of-xhtml/

http://www.webdevout.net/articles/beware-of-xhtml
This aspect is
something I
actually like very much, as I can now build and position all
components with
code, instead of looking all these things up in HTML and CSS files
(great
for website design, but not for desktop-like application development).

So, my questions to you all are:

- what do you think of this strategy?
Click to expand...

I think having empty body tags and building the whole thing with
JavaScript is fine.

I only transmit data to and from the server.

Make sure you take advantage of browser caching to make second page
loads fast.

Use JavaScript on the server-side so you can share code and stay DRY.
Using JavaScript server-side is something I'm just starting to explore
now.

- If this strategy has already been discussed before, then what is it
called?
(I am calling it AJAJS for the time being (not AJAJ which is JSON
oriented)).
- Where can I find more information about this?
- Are there already existing frameworks based on this?
Click to expand...

In the Rails world it is RJS. Also search google for "Dan Webb ejs".

- Do you think that browsers will continue to support eval(), and not
depreciate
it in the future for security reasons?
Click to expand...

I'd guess eval() is not going away since it is part of the ECMAScript
standard. There are other options that you'll find in the "Randy Webb"
threads.

Peter
 
D

David Mark

I was wandering what the Javascript/Ajax community think of a rather
unusual
method I am using to develop my new web app. At least I think it is
unusual
Click to expand...

It is unusual.
because I have not yet found much about this exact method on the
internet.
My web app uses no HTML templates and neither does it use any CSS
files.
Click to expand...

That's an odd approach for a Web-based application.
It is totally JS/Ajax driven, and there are totally no page fetches/
reloads
Click to expand...

But lots of script fetches.
(single page interface). My initial page looks a bit like this (the
only html
code in my whole app!):

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title></title>
<script type="text/javascript" src="./js/init.js"></script>
</head>
<body>
</body>
<html>
Click to expand...

I assume that last line is actually </html>. Anyway, a user without
scripting enabled will see nothing. I understand that your app
requires scripting, but you need an explicit disclaimer in the page.
The init.js is a small script that starts it all up. It does a
XMLHTTPRequest
to a server-side application that only outputs JS code. ALL returned
content
is passed into eval() (I actually do not need to call eval() directly
because
the Content-type is "text/javascript"). The first JS code that
Click to expand...

I don't know what you mean by that. The script doesn't evaluate
itself. Is Prototype or the like mixed up in this thing?

is
returned
builds up the whole page, loads some simple libraries, and registers
some
events to observe. From then on, ALL events (except for simple
Click to expand...

Why wouldn't this code be in init.js?

things
like
resizing) are sent to my server application which then outputs more JS
code
that get executed back on the client. For example, a user clicks on a
button,
the request is sent to the server which then returns some JS code to
build
a message dialog and register the corresponding message handlers, and
so on.
Click to expand...

You've turned browsers into dumb terminals.
Therefore, for every event, the browser "asks" the server what to do,
and the
server tells the browser directly what to do with a snippet of
Javascript.
Click to expand...

You shouldn't query the server unless you need data from the server.
The presentation logic should be downloaded once and run on the
client.
This has great advantages for me as I now have all my layout, model,
business
logic, etc. in one place. It is like "lazy loading", but an
Click to expand...

Why would you want your business rules mixed up in your presentation
layer. Whether you mean logically or physically in one place, this
makes no sense to me.

extreme
form.
One might think that it could run quite slow because it connects to
the server
for every user-action, but the returned pieces of code are small
pieces of
code, so the speed is actually quite impressive. This setup
Click to expand...

Not nearly as impressive as it would be with the presentation logic
running on the client.

results in
an
extremely thin-client. I am very pleased with the first
Click to expand...

An extremely thin client makes sense for an app that runs on a cell
phone, but is wasteful on a PC. Why not leverage the power of PC
browsers instead of turning them into dumb terminals?

results, and
it makes
the whole development experience much like my original profession:
building
client/server desktop applications.
Click to expand...

Don't take this the wrong way, but what decade was this in?
This is probably a sort of controversial method because I noticed that
there
are mixed opinions about using the eval() function to execute code.
Click to expand...

Not really. It leads to all sorts of headaches and is practically
never needed. Why invite trouble?
Ofcourse,
the returned code comes from my own server (same origin policy), so no
major
reasons for concern. Another point of criticism is possibly the fact
that I
do not use any (X)HTML templates or CSS files. This aspect is
something I
actually like very much, as I can now build and position all
components with
code, instead of looking all these things up in HTML and CSS files
(great
for website design, but not for desktop-like application development).
Click to expand...

Why not use CSS files? Why would you want to lump appearance in with
business rules and presentation logic. If you need to change the
appearance of your app, you modify your CSS file(s). If you need to
change your business rules you modify your server-side scripts. If
you need to modify your presentation logic, you modify your client-
side scripts. This would seem a lot easier than having everything in
one place.
So, my questions to you all are:

- what do you think of this strategy?
Click to expand...

Not much.
- If this strategy has already been discussed before, then what is it
called?
(I am calling it AJAJS for the time being (not AJAJ which is JSON
oriented)).
- Where can I find more information about this?
Click to expand...

Google for "thin client", "dumb terminal", "mainframe computers", etc.
- Are there already existing frameworks based on this?
Click to expand...

Probably, but that doesn't make it a good idea.
- Do you think that browsers will continue to support eval(), and not
depreciate
it in the future for security reasons?
Click to expand...

As for depreciation, it's already been written off for general use,
but it isn't likely to be deprecated as it is occasionally useful.
 
T

timsamshuijzen

Thank you all for your comments. They are most usefull. I will use
this in evaluating the current architecture. Maybe I will eventually
choose to make the client a bit "thicker", I am not sure yet. It
depends on the limitations I will encounter during development. For
the time being I like the idea of the thin client, and that the server
"knows" what the client is doing.
As for database connections, at the moment the database connections
are handled by my server app, and the results are returned as a set of
JS instructions that show the results in the browser. No problems
there.

And for those commenting on "Content-type text/javascript", yes I
indeed use Prototype (which I did not show in the HTML code of my
first post). It was quite a useless piece of information I gave there
that is not related to this subject. (BTW. In the meantime I have
switched back to a simple eval(). )

Cheers,

Tim
 
P

Peter Michaux

Thank you all for your comments. They are most usefull. I will use
this in evaluating the current architecture. Maybe I will eventually
choose to make the client a bit "thicker", I am not sure yet. It
depends on the limitations I will encounter during development. For
the time being I like the idea of the thin client, and that the server
"knows" what the client is doing.
As for database connections, at the moment the database connections
are handled by my server app, and the results are returned as a set of
JS instructions that show the results in the browser. No problems
there.

And for those commenting on "Content-type text/javascript", yes I
indeed use Prototype (which I did not show in the HTML code of my
first post). It was quite a useless piece of information I gave there
that is not related to this subject. (BTW. In the meantime I have
switched back to a simple eval(). )
Click to expand...

It doesn't matter if you do the eval() or Prototype does the eval().
It is the same eval(). What matters is you get Prototype out of your
program all together. Read the comp.lang.javascript archives for many
reasons why Prototype is regarded as poor quality and will lead to
headaches.

Peter
 
T

timsamshuijzen

...What matters is you get Prototype out of your
program all together. Read the comp.lang.javascript archives for many
reasons why Prototype is regarded as poor quality and will lead to
headaches.
Click to expand...

I understand from many posts that Prototype.js is not the preferred
library. I would however like to make use of some kind of (basic)
library (for DOM/Ajax/Events) to save me a lot of boring work in
making functions that work in most browsers. It is a shame that many
people here say that they have not found a very good library for
general use. Do I understand correctly that Yahoo!'s YUI is the better
choice (if any)? Thanks in advance for any advice.

Tim
 
D

David Mark

I understand from many posts that Prototype.js is not the preferred
library. I would however like to make use of some kind of (basic)
library (for DOM/Ajax/Events) to save me a lot of boring work in
making functions that work in most browsers. It is a shame that many
Click to expand...

I am currently working on just that. More like DOM || Events || Ajax,
etc. as applications don't always need all three.
people here say that they have not found a very good library for
general use. Do I understand correctly that Yahoo!'s YUI is the better
choice (if any)? Thanks in advance for any advice.
Click to expand...

Better in what way? I haven't looked too deeply into it, but it seems
to be better code than Prototype, jQuery and the like (which isn't
saying much.) However, it looks like overkill for basic Web
applications.
 
T

timsamshuijzen

I got busy today and wrote my own library for DOM || Events || Ajax.
quirksmode.org was a very useful reference while making this. Writing
the functionality for the events was the most work (passing on "object
scope" by means of binding, etc.) and it eventually turned out nice
and compact. This version makes it much easier to remove/detach the
events than with Prototype. I am quite pleased with the result and it
was a very educational experience. My app now runs without any other
libraries and I aim to keep it that way (except for maybe a WYSIWYG
editor). The next sub-project will be to make a GUI lib.
If anyone is interested in the code for the event stuff, just let me
know and I will post it here.

Thanks again for the good advice.

Tim
 
D

David Mark

I got busy today and wrote my own library for DOM || Events || Ajax.
Click to expand...

Good idea.
quirksmode.org was a very useful reference while making this.
Click to expand...

Yes, that site is very helpful.

Writing
the functionality for the events was the most work (passing on "object
scope" by means of binding, etc.) and it eventually turned out nice
and compact. This version makes it much easier to remove/detach the
events than with Prototype. I am quite pleased with the result and it
Click to expand...

The trouble with event processing in most of the libs out there is
inefficiency. This is most easily observed when using features built
atop them like drag and drop.
was a very educational experience. My app now runs without any other
libraries and I aim to keep it that way (except for maybe a WYSIWYG
Click to expand...

I've looked at lots of WYSIWYG editor scripts and couldn't recommend a
single one.
editor). The next sub-project will be to make a GUI lib.
Click to expand...

The biggest pain in writing a framework for widgets is positioning.
The second biggest is sizing. The quirksmode site has a lot of good
information on these subjects, but it is just raw data. Drawing
meaningful conclusions and implementing reliable feature tests is a
time-consuming and often agonizing process.
 
P

Peter Michaux

I understand from many posts that Prototype.js is not the preferred
library. I would however like to make use of some kind of (basic)
library (for DOM/Ajax/Events) to save me a lot of boring work in
making functions that work in most browsers. It is a shame that many
people here say that they have not found a very good library for
general use. Do I understand correctly that Yahoo!'s YUI is the better
choice (if any)? Thanks in advance for any advice.
Click to expand...

I started with the YUI libraries and tried to fix at least everything
that was wrong/less than optimal in my eyes.

http://forkjavascript.org

Peter
 
T

timsamshuijzen

The biggest pain in writing a framework for widgets is positioning.
The second biggest is sizing.
Click to expand...

I am not experiencing any difficulties here yet. This is probably
because I am not writing any general widgets that can be used
anywhere. My widgets are used in my app environment where all elements
are positioned absolute. My sizing, resizing, and drag routines are
working fine, no pain yet. Or maybe you are referring to some
difficulties that I have not yet encountered.

I started with the YUI libraries and tried to fix at least everything
that was wrong/less than optimal in my eyes.

http://forkjavascript.org

Peter
Click to expand...

I had a look at your code - great stuff! I had a look at your event
routines to check whether my code is up to scratch (I am new to JS). I
actually found your code "quite" similar to mine, which serves as a
confirmation to me that I am on the right track. If I would have
looked at your code previously then it would have saved me quite some
work yesterday ;-) On the other had, in my opinion it is good to have
written such stuff totally from scratch so that one fully understands
the issues
involved.

For those interested, here is my (stripped) version of a simple event
handler:
(Comments, questions and suggestions are welcome)

var TVSEvent = {
Handlers: [],
IndexOfHandler: function(aHandler) {
var hidx = -1;
for(var i = 0, length = this.Handlers.length; i < length; i++) {
var hob = this.Handlers;
if((hob.Handler == aHandler) || (hob.DOMHandler == aHandler)) {
hidx = i;
break;
}
}
return hidx;
},
Add: function(aNode, aType, aHandler, aScope) {
var domh = aHandler;
if(arguments.length >= 4) {
domh = function() {
return aHandler.apply(aScope, arguments);
}
}
this.Handlers[this.Handlers.length] = {
Handler: aHandler,
DOMHandler: domh
}
if(aNode.addEventListener) {
aNode.addEventListener(aType, domh, false);
} else if(aNode.attachEvent) {
aNode.attachEvent('on' + aType, domh);
}
return domh;
},
Remove: function(aNode, aType, aHandler) {
var domh = aHandler;
var eidx = this.IndexOfHandler(domh);
if(eidx >= 0) {
domh = this.Handlers[eidx].DOMHandler;
this.Handlers.splice(eidx, 1);
}
if(aNode.removeEventListener) {
aNode.removeEventListener(aType, domh, false);
} else if(aNode.detachEvent) {
aNode.detachEvent('on' + aType, domh);
}
}
}
 
P

Peter Michaux

I am not experiencing any difficulties here yet. This is probably
because I am not writing any general widgets that can be used
anywhere. My widgets are used in my app environment where all elements
are positioned absolute. My sizing, resizing, and drag routines are
working fine, no pain yet. Or maybe you are referring to some
difficulties that I have not yet encountered.



I had a look at your code - great stuff! I had a look at your event
routines to check whether my code is up to scratch (I am new to JS). I
actually found your code "quite" similar to mine, which serves as a
confirmation to me that I am on the right track. If I would have
looked at your code previously then it would have saved me quite some
work yesterday ;-) On the other had, in my opinion it is good to have
written such stuff totally from scratch so that one fully understands
the issues
involved.
Click to expand...

Yes it is good to know all the issues involved.

For those interested, here is my (stripped) version of a simple event
handler:
(Comments, questions and suggestions are welcome)

var TVSEvent = {
Handlers: [],
IndexOfHandler: function(aHandler) {
var hidx = -1;
for(var i = 0, length = this.Handlers.length; i < length; i++) {
var hob = this.Handlers;
if((hob.Handler == aHandler) || (hob.DOMHandler == aHandler)) {
hidx = i;
break;
}
}
return hidx;
},
Add: function(aNode, aType, aHandler, aScope) {
var domh = aHandler;
if(arguments.length >= 4) {
domh = function() {
return aHandler.apply(aScope, arguments);
}
}
this.Handlers[this.Handlers.length] = {
Handler: aHandler,
DOMHandler: domh
}
if(aNode.addEventListener) {
aNode.addEventListener(aType, domh, false);
} else if(aNode.attachEvent) {
aNode.attachEvent('on' + aType, domh);
}
return domh;
},
Remove: function(aNode, aType, aHandler) {
var domh = aHandler;
var eidx = this.IndexOfHandler(domh);
if(eidx >= 0) {
domh = this.Handlers[eidx].DOMHandler;
this.Handlers.splice(eidx, 1);
}
if(aNode.removeEventListener) {
aNode.removeEventListener(aType, domh, false);
} else if(aNode.detachEvent) {
aNode.detachEvent('on' + aType, domh);
}
}

}
Click to expand...


It looks like you don't need to "prevent default" for click and double
click events in Safari. That restriction removes a mighty ugly
workaround I've included in my code.

Peter
 
R

Richard Maher

Hi David,
You shouldn't query the server unless you need data from the server.
The presentation logic should be downloaded once and run on the
client. : : :
Why would you want your business rules mixed up in your presentation
layer. Whether you mean logically or physically in one place, this
makes no sense to me. : : :
Not nearly as impressive as it would be with the presentation logic
running on the client.
: : :
results, and

Don't take this the wrong way, but what decade was this in?
Click to expand...

I agree with all of the above but to be fair to the OP hasn't technology
such as AJAX, in some ways, turned the clock back and created a hybrid by
merging the web and client/server paradigms? There are people, certainly
within this group, who'll contend that if it doesn't have a SUBMIT button
then it's not a browser application. Others, myself included, can see
browsers as the run-time environment for a genre of "new" lightweight
client/server applications.

Anyway FWIW here is how I'd do it (HTTP is great for serving up web-pages
and images, but is it really the best tool in the box for a secure,
high-performance, middleware communications back-bone? The browser *is* the
GUI, but is a Web-Server really an Application Server?)

http://manson.vistech.net/t3$examples/demo_client_web.html

All of the HTML, Javascript, and Java Applet sources can be viewed at: -

http://manson.vistech.net/t3$examples/

To see the example sucessfully you will need:-

1) Javascript enabled
2) Java Applets enabled
3) Can't be behind a Firewall that forbids all unknown outgoing connections
(otherwise open-up 5255)
4) Must be running SUN's JRE 1.4.2_13 or later (1.6 is advised)
5) Must be running Internet Explorer (6 or later) or Firefox (Haven't tested
other browsers) I'm told it works with Safari Version 2.0.4 (419.3) Java
Plug-in 1.5.0 Using JRE version 1.5.0_07 Java HotSpot(TM) Client VM.

All things being equal you should then be prompted (via Java modal dialogue
box) for:-

Username: TIER3_DEMO
Password: QUEUE

Here's some of the functionality-catwalk highlights from the example: -

1) Full, one-time, context-specific, VMS User Authentication. No Cookies,
Session IDs, Password Caching or generic Work-Station or Browser
credentials! When you load the demo_client_web.html page into your browser,
a Java Applet is automatically activated that prompts the user for their VMS
Username and Password via a modal dialogue box. If authorization fails, the
"Access Denied" page will be displayed and VMS Intrusion Detection (in
accordance with the policy set out by your System Manager) will be enforced,
and Login-Failures is incremented in SYSUAF. Alternatively, if authorization
is successful (and you left the "Display Logon Confirmation" box ticked)
then a Welcome dialog box will be displayed detailing last login times and
the number of unsuccessful login attempts (if any). Login-Failures is now
set to zero and last non-interactive login time is set to the current time.

If you refresh this page, or move to a different page, then the server
connection is broken and you must be re-authorised before continuing to
access the Demo Queue Manager application.

2) A Hot-Abort button! After you have pressed the "Get Job Info" button
you'll notice that the "Abort Request" button becomes active and turns red.
(Actually you probably won't notice 'cos this query completes too quickly
:) You can edit the DEMO_UARS.COB code and change the value of the
DEBUG_DELAY field if you want to see your 3GL Interrupt routine in action.)
In this case the cancel-flag I've set in the AST routine is picked up in the
mainline code, resulting in the graceful termination of the loop that
controls "next queue" (or "next row") retrieval.

Also, if you look at the getResponse() function in query_lookup.html, you
will see how the chan.setTimeout() method has been deployed to provide an
erstwhile "blocking" socket Read with the ability to surrender the
event-thread for things like processing the Abort button and ticking over
the clock. (all of this, and much more, "infrastructure-code" is already
there and doesn't have to be re-invented)

3) Predictive text on the Queue Name field so that all matching VMS queues
are retrieved on-demand as the user types. As is now common-place with many
websites, a drop down select list of matching options is automatically
retrieved from the server and made available for the user to select from.

4) Result-set drill-down. Many database queries return a result-set of rows
for the user to scan through and possibly drill-down into for more detail.
I've provided a reasonably generic example of this, where all matching Job
Entries have been populated into a dynamic HTML select list. Once again the
user was able to see the select-list grow, the scroll-bar diminish, and
"Jobs Found" field tick over in real-time, whilst continually being
empowered (by the Abort button) to curtail the results at any time!

If you click on an entry in the Select List then the <frame> changes and the
entry_details.html page appears. See the parent.entry_details.getReady()
call in queue_lookup.html to see how the handover to the new frame takes
place. (Also see goBack() in entry_details.html to see how simply that
operation is reversed.)

The user is now free to move forward, back, first, last, refresh, and delete
queue entries, or return to the previous frame. (Thanks to the deployment of
the VMS Persona functionality, the user is only permitted to see those queue
entries that the Username they signed in under is permitted to see. They can
also *only* delete those entries that this username is allowed to delete.)

5) Floating <div>s. You'll see that any queue names are highlighted in bold
and italics; if you mouseover any of these fields when they are not blank
then the current status information for that queue will be retrieved from
the server and displayed in a quasi-popup DIV.

6) Local Result-Set Sort. If you click on the "header" or "first" row in the
Select List of queues, you will get a popup prompting you for a sort key. If
you select one, the contents of the Select List are sorted in the chosen
order. (Try enter "*" for the Queue Name and then clicking "Get Job Info" to
get some data worth sorting)

Regards Richard Maher

PS. The server code can be in any 3GL but, for this example, I chose COBOL;
"What century are we in" :)
 
D

David Mark

Hi David,

[snip]


I agree with all of the above but to be fair to the OP hasn't technology
such as AJAX, in some ways, turned the clock back and created a hybrid by
merging the web and client/server paradigms? There are people, certainly
within this group, who'll contend that if it doesn't have a SUBMIT button
then it's not a browser application. Others, myself
Click to expand...

I'm not sure I follow, but a form without a submit button is a bad
idea.

included, can see
browsers as the run-time environment for a genre of "new" lightweight
client/server applications.
Click to expand...

Yes, but light is relative. The OP proposal is too light, wasting the
capabilities of the browser and PC.
Anyway FWIW here is how I'd do it (HTTP is great for serving up web-pages
and images, but is it really the best tool in the box for a secure,
high-performance, middleware communications back-bone? The browser *is* the
GUI, but is a Web-Server really an Application Server?)
Click to expand...

The Web server is just a conveyance between the presentation and
middleware layers.
http://manson.vistech.net/t3$examples/demo_client_web.html
Click to expand...

That didn't work too hot for me in IE7. I got a message saying the
Java runtime environment couldn't be loaded (and little else.) I
don't think your app caused the error, but it didn't recover from it
very gracefully. In other words, it degraded to a virtually blank and
unusable page.
All of the HTML, Javascript, and Java Applet sources can be viewed at: -

http://manson.vistech.net/t3$examples/

To see the example sucessfully you will need:-

1) Javascript enabled
Check.

2) Java Applets enabled
Check.

3) Can't be behind a Firewall that forbids all unknown outgoing connections
Check.

(otherwise open-up 5255)
4) Must be running SUN's JRE 1.4.2_13 or later (1.6 is advised)
Click to expand...

No idea.
5) Must be running Internet Explorer (6 or later) or Firefox (Haven't tested
other browsers) I'm told it works with Safari Version 2.0.4 (419.3) Java
Plug-in 1.5.0 Using JRE version 1.5.0_07 Java HotSpot(TM) Client VM.

All things being equal you should then be prompted (via Java modal dialogue
box) for:-

Username: TIER3_DEMO
Password: QUEUE
Click to expand...

Never got this far.
Here's some of the functionality-catwalk highlights from the example: -

1) Full, one-time, context-specific, VMS User Authentication. No Cookies,
Session IDs, Password Caching or generic Work-Station or Browser
credentials! When you load the demo_client_web.html page into your browser,
a Java Applet is automatically activated that prompts the user for their VMS
Username and Password via a modal dialogue box. If authorization fails, the
"Access Denied" page will be displayed and VMS Intrusion Detection (in
accordance with the policy set out by your System Manager) will be enforced,
and Login-Failures is incremented in SYSUAF. Alternatively, if authorization
is successful (and you left the "Display Logon Confirmation" box ticked)
then a Welcome dialog box will be displayed detailing last login times and
the number of unsuccessful login attempts (if any). Login-Failures is now
set to zero and last non-interactive login time is set to the current time.

If you refresh this page, or move to a different page, then the server
connection is broken and you must be re-authorised before continuing to
access the Demo Queue Manager application.
Click to expand...

Right. I take it it's one application per page.

[snip]

Clearly Ajax isn't appropriate this application, so Java is required.
But what sort of practical Web application would you build with this?
I guess it would make sense if you need remote access to a mainframe.
Regards Richard Maher

PS. The server code can be in any 3GL but, for this example, I chose COBOL;
Click to expand...

Since I didn't see the example, I really can't comment on it, other
than to say that COBOL is an odd choice.

Thanks for sharing.
 
P

Peter Michaux

On Sep 29, 7:42 pm, "Richard Maher" <[email protected]>

I'm not sure I follow, but a form without a submit button is a bad
idea.
Click to expand...

Are you sure it is *always* a bad idea?
included, can see


Yes, but light is relative. The OP proposal is too light, wasting the
capabilities of the browser and PC.
Click to expand...

Ironically, "too" light is also relative.

I'm not sure how you can make such categorical statements with such
confidence. Different situations require different approaches and to
throw away options a priori seems like a less-than-optimal choice.

Peter
 
R

Richard Maher

Hi David,
I'm not sure I follow, but a form without a submit button is a bad
idea.
Click to expand...

Not if you never submit anything.
Yes, but light is relative. The OP proposal is too light, wasting the
capabilities of the browser and PC.
Click to expand...

I would agree with you here, but others may be happy with it.
The Web server is just a conveyance between the presentation and
middleware layers.
Click to expand...

Yes it is convenient and ubiquitous - and (I contend) demonstrably a square
peg in the middleware hole.
No idea.
Click to expand...

As Microsoft does not support a JVM for recent versions of Windows you need
to install a copy of SUN's JRE which can be downloaded from
http://java.sun.com/javase/downloads/index.jsp

To see what (if any) version you've currently got installed you should look
for "Java Plug-In" in your Control Panel.
Right. I take it it's one application per page.
Click to expand...

Currently I use Framesets and load new page(s) into an off-screen and then
"grow" it when it's ready. Having said that, it would be extremely easy to
have the Socket survive page transitions but I haven't had the time to test
whether that Socket could then be the subject of a Socket-Hijacking attack
as much as Session-Hijacking is a gaping hole in other architectures.
Therefore I currently tear it down via the Applet's (CornuCopiae.java)
destroy() method which calls the Socket's (Tier3Socket.java) close() method.
But what sort of practical Web application would you build with this?
Click to expand...

Any and all! OK, it may not be for your normal shopping-trolley web-app or
usual Web-Browser look and feel, but just think of rolling out new versions
of an organizations internal application(s) without having to upgrade the
software on the client PCs. Pretty much all "known user" applications such
as branch-office to head-office, bank customer access, or travel agent to
wholesaler etc etc
I guess it would make sense if you need remote access to a mainframe.
Click to expand...

Exactly! High-performance, secure, context-rich client access to your
mainframe resources.
than to say that COBOL is an odd choice.
Click to expand...

As I said, it could be any 3GL that can produce a Shareable Image/DLL.
Thanks for sharing.
Click to expand...

Thanks for giving it a go! I hope you get the time to download the JRE and
give it another go. IMHO, It's definitely worth the few minutes effort and
having a recent JVM on your box is always handy!

Cheers Richard Maher

David Mark said:
Hi David,

[snip]


I agree with all of the above but to be fair to the OP hasn't technology
such as AJAX, in some ways, turned the clock back and created a hybrid by
merging the web and client/server paradigms? There are people, certainly
within this group, who'll contend that if it doesn't have a SUBMIT button
then it's not a browser application. Others, myself
Click to expand...

I'm not sure I follow, but a form without a submit button is a bad
idea.

included, can see
browsers as the run-time environment for a genre of "new" lightweight
client/server applications.
Click to expand...

Yes, but light is relative. The OP proposal is too light, wasting the
capabilities of the browser and PC.
Anyway FWIW here is how I'd do it (HTTP is great for serving up web-pages
and images, but is it really the best tool in the box for a secure,
high-performance, middleware communications back-bone? The browser *is* the
GUI, but is a Web-Server really an Application Server?)
Click to expand...

The Web server is just a conveyance between the presentation and
middleware layers.
http://manson.vistech.net/t3$examples/demo_client_web.html
Click to expand...

That didn't work too hot for me in IE7. I got a message saying the
Java runtime environment couldn't be loaded (and little else.) I
don't think your app caused the error, but it didn't recover from it
very gracefully. In other words, it degraded to a virtually blank and
unusable page.
All of the HTML, Javascript, and Java Applet sources can be viewed at: -

http://manson.vistech.net/t3$examples/

To see the example sucessfully you will need:-

1) Javascript enabled
Check.

2) Java Applets enabled
Check.

3) Can't be behind a Firewall that forbids all unknown outgoing
Click to expand...
connections
Check.

(otherwise open-up 5255)
4) Must be running SUN's JRE 1.4.2_13 or later (1.6 is advised)
Click to expand...

No idea.
5) Must be running Internet Explorer (6 or later) or Firefox (Haven't tested
other browsers) I'm told it works with Safari Version 2.0.4 (419.3) Java
Plug-in 1.5.0 Using JRE version 1.5.0_07 Java HotSpot(TM) Client VM.

All things being equal you should then be prompted (via Java modal dialogue
box) for:-

Username: TIER3_DEMO
Password: QUEUE
Click to expand...

Never got this far.
Here's some of the functionality-catwalk highlights from the example: -

1) Full, one-time, context-specific, VMS User Authentication. No Cookies,
Session IDs, Password Caching or generic Work-Station or Browser
credentials! When you load the demo_client_web.html page into your browser,
a Java Applet is automatically activated that prompts the user for their VMS
Username and Password via a modal dialogue box. If authorization fails, the
"Access Denied" page will be displayed and VMS Intrusion Detection (in
accordance with the policy set out by your System Manager) will be enforced,
and Login-Failures is incremented in SYSUAF. Alternatively, if authorization
is successful (and you left the "Display Logon Confirmation" box ticked)
then a Welcome dialog box will be displayed detailing last login times and
the number of unsuccessful login attempts (if any). Login-Failures is now
set to zero and last non-interactive login time is set to the current time.

If you refresh this page, or move to a different page, then the server
connection is broken and you must be re-authorised before continuing to
access the Demo Queue Manager application.
Click to expand...

Right. I take it it's one application per page.

[snip]

Clearly Ajax isn't appropriate this application, so Java is required.
But what sort of practical Web application would you build with this?
I guess it would make sense if you need remote access to a mainframe.
Regards Richard Maher

PS. The server code can be in any 3GL but, for this example, I chose
Click to expand...
COBOL;

Since I didn't see the example, I really can't comment on it, other
than to say that COBOL is an odd choice.

Thanks for sharing.
Click to expand...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Using XMLHttpRequest without 'eval' 11
XMLHttpRequest 2
Mobile App ideas - worksheet emailer 1
Python client/server that reads HTML body from server 1
XPath, XMLHttpRequest and parsing DOM 4
Simple web framework - improvements to makefile 0
Desku - 1 Codebase for Desktop, Mobile and Web Applications 0
Docking electron desktop app above browsers and other applications. 7

Members online

No members online now.
Total: 65 (members: 1, guests: 64)
Robots: 400

Forum statistics

Threads
473,982
Messages
2,570,185
Members
46,736
Latest member
AdolphBig6

Latest Threads

Top