[thelist] idea behind ajax: clear non-presentation-only-logic on server end

[Zhang Weiwu]

Bad email subject though. I cannot think of a better subject line (bad
English writing skill)

Is it me or a lot of people thought about the same thing too? I have been
developing web application for 3 years and I very often get messed up with
"PHP generated HTML with PHP generated javascript" and ends up getting
fighting 4 different escape methods and security check. This is none sense.
I am afraid I cannot describe the pain during working on messing code (bad
English) but after one time time I developed with XML data island the
structure is so clear that I immediatly fall in love with it. Later I
realized ajax can get the XML data dynamically, which is even better.

I thus think, why not just use plain static HTML for the whole web
application?  Why we bother to generate HTML and fight the messing php code
and debug on even uglier generated HTML code to find the even messy
javascript bug? We can, design a lot of HTML pages, after the page loaded,
the javascript lives in the page loads the dynamic parts in the html from
server (using XML), puts them in the right place in HTML.

E.g. a page for editing contact person information used to be extremely
messy, with the features like adding more then one phone number,
automatically generate full name and maintaining multi language versions of
the contact's name, inlcuding the photo and some feature to syntax check the
telephone number, also the interface translation.... This page ends up very
difficult to debug.  I would like to think if I can separate this problem to
two parts, this page is easier.  One part is the client side, we simply use
a pure HTML static file, the javascript generate a XML request to ask the
server for all translations of all the interface language, gets the result
and keep them either in the user interface or in javascript variables. Then
it fetches all the fields values, construct the user interface, fetch the
schema, a.k.a what fields to display, what is the type of the fields (most
are input fields but boolean valus like 'is_married' should be constructed
with two radio buttons, date type field should be constructed with
jscalendar widget), after the user interface constructed, fetch current
value from DB by xml.request and pop the value to the interface, when user
make modification, feed back the modification to the server and if error
happen ('person with this studentID already exist!'), fetch the error
message from server and alert the user.  There is no 'save' button needed
for such kind of interface.

This way at least we have these benifit:
1) both server and client are faster. For the client it make use of cached
HTML file, saving the time requesting a full HTML page from server. The
server do not need to generate html with another language;
2) the code is clean and easy to debug on client side;
3) the communication can be logged and checked on server end, making less
use of 'alert' statement debugging in javascript;
4) the user get feed back immediately (for syntax error in telephone
numbers, conflicts and suggestions like "you maybe entering the same person
twice")
5) the major benifit is this breaks the problem to two parts, now the client
side and server side can be considered separate project, as long as the
output response XML is correct from the server, most work are done on the
client side. Thus we do not need to construct "UI layer" on the server side,
much simpler for handling server scripting.

The draw back? I cannot think of any, but I think this idea must have been
thought many a times, only I didn't google it out. Besides, actually the
system goes back to the "Client/Server" module, there might be some drawback
in Client/Server module too.

How do you think of this? Can you point me some link to people originally
think getting webapplication working this way?

--
Zhang Weiwu