DML and xmlhttp

[Fabri]

I wonder if someone wrote some code to manipulate data (insert, update,
delete) using xmlhttp and AJAX approach and standardized some procedures.

I mean, for example, standard way to manipulate data with PHP or
VBScript (most common) are a form with a action page that process POST
or GET and so on...

It is cool to do this all via xmlhttp.

I developed some code but nothing standard...I was thinking about
object-oriented approach...

Any contribute appreciated.

Best regards.

 

[VK]

I wonder if someone wrote some code to manipulate data (insert, update,

delete) using xmlhttp and AJAX approach and standardized some procedures.

So far nothing to talk about:
IE doesn't really need it as it has it's own fully implemented data
binding model,
and Gesko clones are getting too messy and unstable on it, specially if
you're trying to cover other less-capable browsers.
I think that XML/XSLT scheme would be more stable and universal for
really universal data binding.

I developed some code but nothing standard...I was thinking about
object-oriented approach...

Any contribute appreciated.

Pull it out to here! (unless copyrighted)
Local profis (I'm not pretending to include myself in this selected
group) are always starving for fresh meat

 

[Thomas 'PointedEars' Lahn]

So far nothing to talk about:

So far you again know almost nothing and pose as being competent, thereby
providing utterly false advice and confusing the hell out of other newbies.
Why don't you just keep your fingers still?

IE doesn't really need it as it has it's own fully implemented data
binding model,

You probably mean its own, proprietary and (therefore) incompatible data
model of XML data islands.

and Gesko clones are getting too messy and unstable on it, specially if
you're trying to cover other less-capable browsers.

Utter nonsense.

1. It's Gecko.

2. They are not Gecko clones, they are using the Netscape Gecko
layout engine, IOW: they are based on it; a completely different thing.

3. Gecko-based UAs support XMLHttpRequest through the native Gecko DOM
while IE-based UAs require not-disabled ActiveX support for it which
introduces several other, mostly security issues there.

4. Your "logic" is, as much too often, erroneous. When trying to cover
your "less-capable browsers", the way Gecko-based browsers handle
XMLHttpRequest (and they handle it well, you are just too incompetent
to see that) bears exactly NO meaning.

I think that XML/XSLT scheme would be more stable and universal for
really universal data binding.

You have not even begun to understand what XML and XSLT are, nor have
you understood the requirements of the OP. He wants to manipulate a
DATABASE! XML can be only another representation of this and XSLT a
way to modify that representation if needed.

Check <http://www.ajaxtoolbox.com/> in any case.

No, don't. The person who recommends it and the people there have not even
recognized that AJAX is just a new wrong (because XML HTTP requests do not
need to be _A_synchronous) commercial buzzword of an older technique being
around and used by more competent people since several years.

Local profis (I'm not pretending to include myself in this selected
group)

Yes, you do pretend you are a professional or even a non-layman regarding
the matters discussed. Go away!


PointedEars

 

[VK]

Go away!

Another bad day, Tommy? Take a glass of milk and go to bed earlier
today.

To OP:
XML/XSLT scheme I mentioned before consists of three components:
1. Page template with persistent parts (like title, copyright, about
etc.) and script
2. Page style table (equiv to CSS)
3. XML data file

Joined together on the client-side they produce one ready to use page.
The trick is that you don't need any special actions for data
allocation: it's all defined on the page template. Using rather
primitive scripting you can just switch from one XML source to another
(from separate files or served from a server script). Kind of
"zero-maintenance" page. This technique was long time kind of a taboo
for the same reason that Microsoft Data Island: "other cannot support
it". But now I see no reason to not use it. Other "others" support it
too... mainly...

Other approach is Microsoft Data Island. It's amasin *what* actually IE
had to propose for a longest time (since 5.x). But of course it will
never be supported by FF / W3C.
I have a data island implementation I had to do this summer. My
customer did not want to pay for the extra cross-browser coverage :-(
and I did not feel like doing that on my own time expences
So I did this store solution and I called it Helen (which stays from
the Greece myth but also sounds close to "Hell on them"). Absolutely
nothing ingenius: just all data island/behavior collected, cleaned and
connected. If you're interested, I can give you a link.

The third approach would be I guess Sarissa - like programs. I cannot
say too much on it because I never managed to run the provided test
cases but maybe I just pressed the wrong buttons. You may get more
lucky:
<http://sarissa.sourceforge.net/doc/overview-summary.html>

And what code did you write?

 

[Matt Kruse]

No, don't. The person who recommends it and the people there have
not even recognized that AJAX is just a new wrong (because XML HTTP
requests do not need to be _A_synchronous) commercial buzzword of an
older technique being around and used by more competent people since
several years.

So your points are:

1) XML Http Requests do not need to be asynchronous
2) AJAX is a commercial buzzword
3) The technique is old and has been used for years

How do any of those facts (all of which are mind-numbingly obvious) relate
to the AJAX library which I wrote?
Especially since,

1) My library supports both sync and async requests
2) I even use the word "buzzword" on my "about" page
3) Also in the about page, I note that I'd been using iframes for remote
scripting before the term "ajax" was even introduced.

What exactly is your gripe with someone recommending such a site, or others?

 

[Michael Winter]

I wonder if someone wrote some code to manipulate data (insert, update,
delete) using xmlhttp and AJAX approach and standardized some procedures.

I'm worried by this suggestion.

The XMLHttpRequest object is obviously a client-side mechanism. In order
for it to be used to manipulate a database directly, the first step
would be to open up the database server to the Internet. Even if the
database user used has extremely limited permissions, you're practically
/begging/ every script kiddie[1] on the planet to break into your
database. If the database user has any of insert, update, or delete
permissions, they don't even need to bother making an effort.

I mean, for example, standard way to manipulate data with PHP or
VBScript (most common) are a form with a action page that process POST
or GET and so on...

If you just want to use XMLHttpRequest as an alternative to a form, then
I don't see why any standard approach would need to be developed. At
most, transmitting data for the POST request could be standardized
(particularly RFC2388), but that's rather unrelated to the specific
topic of database manipulation.

If you're just trying to avoid page refreshes when performing
server-side operations, then use a form to trigger the update, but have
the server return a 204 No Content response. Careful, though. Sending a
response is better as it allows to user to understand that something
actually happened.

[snip]

Mike


[1] <http://en.wikipedia.org/wiki/Script_kiddie>