Web design architecture (reliance on JavaScript)

[Abdullah Kauchali]

Hi folks,

(Need comments if you have done something like this before. Any response
would be greatly appreciated.)

We've recently been prototyping the idea of completely avoiding the server
building the eventual/final HTML for the browsers. So far we've got this:

1. Create separate ASP pages that talk to the COM business components (say:
businessproc.asp);
2. These ASP pages do a predefined number of non-visual business "actions"
(e.g your CRUDs);
3. The businessproc.asp page is embedded (?) into a user-interface HTML
page (ui.htm) as an hidden iframe;
4. The business actions of the hidden iframe'd businessproc.asp are
triggered via JavaScript (there is a "runner" javascript function on the
businessproc.asp page that acts as a receiving point which also does a form
post triggering the correct "action");
5. The results of the businessproc.asp are then PUSHED into the parent
UI.HTM page once the business action is complete (once businessproc.asp
returns);
6. The receiving functions of this post-back on the UI.HTM page then
"paint" the appropriate controls. (Cycle complete)

Has anyone done this before? (Any links etc) What are the general caveats
of this approach?

Many thanks in advance,

Regards

Abdullah

[Michael D. Kersey]

Abdullah Kauchali wrote:

Hi folks,
(Need comments if you have done something like this before. Any response
would be greatly appreciated.)
We've recently been prototyping the idea of completely avoiding the server
building the eventual/final HTML for the browsers. So far we've got this:
1. Create separate ASP pages that talk to the COM business components (say:
businessproc.asp);
2. These ASP pages do a predefined number of non-visual business "actions"
(e.g your CRUDs);
3. The businessproc.asp page is embedded (?) into a user-interface HTML
page (ui.htm) as an hidden iframe;
4. The business actions of the hidden iframe'd businessproc.asp are
triggered via JavaScript (there is a "runner" javascript function on the
businessproc.asp page that acts as a receiving point which also does a form
post triggering the correct "action");
5. The results of the businessproc.asp are then PUSHED into the parent
UI.HTM page once the business action is complete (once businessproc.asp
returns);
6. The receiving functions of this post-back on the UI.HTM page then
"paint" the appropriate controls. (Cycle complete)
Has anyone done this before? (Any links etc) What are the general caveats
of this approach?
Many thanks in advance,
Regards
Abdullah

It is well studied and widely used; see some links at
http://www.google.com/search?hl=en&l...me&btnG=Search
and
http://www.google.com/groups?hl=en&l...sh&btnG=Search

A discussion & experience:
http://builder.com.com/5100-6371-1044774.html

There are entire frameworks based on such an architecture: e.g., the
mapping company ESRI ( http://www.esri.com/ )uses such an approach for
their WWW map display software.

Downsides:
- startup can be abysmal: see esp. the above builder.com.com URL,
- you can't bookmark in frames, etc., see
http://www.allmyfaqs.com/faq.pl?Prob...h_using_frames for a list of
complaints specific to frames,
- IIRC IFRAME _was_ proprietary to Microsoft but was incorporated into
HTML 4, so you might also want to check browser compatibility.

On a completely different note: if your ASP pages do little more than
call COM components, you might be better off accessing the database
directly from the ASP pages. Reason is the cost of component creation
and data marshalling between ASP page and COM component is high.
Microsoft's Nile benchmarks showed pure ASP pages outperforming ASP
+COM+ under heavy load.

Good Luck,
Michael D. Kersey