Another option (was Re: AJAJS - thin client web app using mainly XMLHTTPRequest and eval())

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
it makes
the whole development experience much like my original profession:
building
client/server desktop applications.

Don't take this the wrong way, but what decade was this in?

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" :-)

"David Mark" <dmark.cinsoft@xxxxxxxxx> wrote in message
news:1190847359.085150.110400@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Sep 26, 10:21 am, timsamshuij...@xxxxxxxxx wrote:
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

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.

That's an odd approach for a Web-based application.

It is totally JS/Ajax driven, and there are totally no page fetches/
reloads

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>

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

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

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.

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.

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

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

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

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.

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.

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).

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?

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?

Google for "thin client", "dumb terminal", "mainframe computers", etc.

- Are there already existing frameworks based on this?

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?

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.



.