Need to find a javascript grid

[Kate]

Hi,
we are now developing complex business application using Ajax
framework. Could anyone point me to the editable javascript grid
control which supports XML loading. Good javascript API would be a
plus. And rather important thing - sometimes we need to represent
hierarchically structured data, so tree view is a must. In most grid
controls I looked through this last thing was missed.
Thanks.

[Thomas 'PointedEars' Lahn]

Kate wrote:

we are now developing complex business application using Ajax
framework.
There is no such thing as "Ajax framework": "AJAX" is but a recently
emerged buzzword for "making use of an XMLHttpRequest object":
<http://en.wikipedia.org/wiki/AJAX>

Relying solely on such a *host object* in a business application
is unreliable, risky and incompetent at best.
Could anyone point me to the editable javascript grid
control which supports XML loading.
No. Go find or write it yourselves.
Good javascript API would be a plus.
What do you think a "javascript API" would be, taking into account
that you are looking for an "editable javascript grid control"?
Do you even have a single clue about the language and its intended
fields of use?
And rather important thing - sometimes we need to represent
hierarchically structured data, so tree view is a must.
Post something new, please.
In most grid controls I looked through this last thing was missed.

So? Unless you provide a not working approach that can be commented
on, I am afraid you have to pay for the solution either way.
PointedEars

[Richard Cornford]

Thomas 'PointedEars' Lahn wrote:

Kate wrote:

we are now developing complex business application
using Ajax framework.
There is no such thing as "Ajax framework": "AJAX" is but
a recently emerged buzzword for "making use of an
XMLHttpRequest object": http://en.wikipedia.org/wiki/AJAX

Ajax does appear to be acquiring a meaning that is no more than the use
of XMLHTTPRequests, and so being reduced to a meaningless buzzword. The
'A' at the beginning standing for Asynchronous is probably the most
interesting (and potentially challenging) aspect of the notion, and the
aspect that seems to be most widely ignored. We have, for example, code
posted here purporting to be an "AJAX" object with a built in facility
for making synchronous requests as well as asynchronous requests
(obviously redundant in an Ajax system that is really asynchronous).

Of course asynchronousness is not an unusual, or unexpected, aspect of
scripting event driven web browsers, but normally the source of
asynchronous activity is the user and there is only one of them. The
heavy reliance on small, short calls to the back-end that is proposed by
Ajax (as a replacement for a more normal page-replacing
submission-response process) introduces a second source of asynchronous
activity, and it becomes a problem to be responding to that activity in
a way that doesn't interfere with what the user is doing at the time.

It is this co-ordination aspect of Ajax that seems to need the most
attention, and I fear will not be found in an off-the-shelf library (at
least not for a while). Currently all of the 'Ajax' libraries I have
seen are concentrating on the organisation of the acquisition,
deployment and employment of the XHMHTTPRequest objects, and some have
thrown in some handling for the XLM data they are expecting to be
transmitting. They are all too low-level to really qualify as
implementing a "framework".
Relying solely on such a *host object* in a business
application is unreliable, risky and incompetent at best.

<snip>

I think that should probably be qualified as "public business
application" (i.e. something related to e-commerce/selling, general
customer services and so on) as probably the majority of "business web
applications" are those used by businesses internally in the restricted
environments of Intranets, where requiring a script and XMLHTTPRequest
enabled browser is not so much of an issue (especially as it can be done
in a known "security zone").

But in a public context, there have been plenty of demonstrations of the
use of XMLHTTPRequests in a non-dependent way, such as Jim's example of
short-circuiting a form submission with a background request when the
facility is available, and falling back to the normal HTML behaviour
when it is not.

Richard.

[Thomas 'PointedEars' Lahn]

"Richard Cornford" schrieb:

Thomas 'PointedEars' Lahn wrote:

Relying solely on such a *host object* in a business
application is unreliable, risky and incompetent at best. <snip>

I think that should probably be qualified as "public business
application" (i.e. something related to e-commerce/selling, general
customer services and so on) as probably the majority of "business
web applications" are those used by businesses internally in the
restricted environments of Intranets, where requiring a script and
XMLHTTPRequest enabled browser is not so much of an issue
(especially as it can be done in a known "security zone").

Well, it is still a host object based on proprietary technology and
nobody can say for sure how long that will be available. Intranets
tend to have a slower upgrade cycle than public networks, but they
nevertheless change.
But in a public context, there have been plenty of demonstrations of
the use of XMLHTTPRequests in a non-dependent way, such as Jim's
example of short-circuiting a form submission with a background
request when the facility is available, and falling back to the
normal HTML behaviour when it is not.

That's why I wrote `solely'. I, too, find nothing wrong to benefit
from additional features, but it is potentially dangerous and thus
unwise to depend on them.
PointedEars

[Lasse Reichstein Nielsen]

"Thomas 'PointedEars' Lahn" <Po*********@web.de> writes:

Well, it is still a host object based on proprietary technology and
nobody can say for sure how long that will be available.

Nobody knows how long browsers with support for HTML and DOM 2 will be
available either. It's not the standard that guarantees availability,
but the usefullness of the feature to the end users.

I'll wager that XMLHTTPRequest survives HTML and that it will be
standardized/specification'ized within two or three years (although
maybe not by the W3C).

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Martin Honnen]

Lasse Reichstein Nielsen wrote:

I'll wager that XMLHTTPRequest survives HTML and that it will be
standardized/specification'ized within two or three years (although
maybe not by the W3C).

Work is already done on that:
<http://www.whatwg.org/specs/web-apps/current-work/#scripted-http>

--

Martin Honnen
http://JavaScript.FAQTs.com/

[Thomas 'PointedEars' Lahn]

Lasse Reichstein Nielsen wrote:

"Thomas 'PointedEars' Lahn" <Po*********@web.de> writes:

Well, it is still a host object based on proprietary technology and
nobody can say for sure how long that will be available.
Nobody knows how long browsers with support for HTML and DOM 2 will be
available either. It's not the standard that guarantees availability,
but the usefullness of the feature to the end users.

Somehow I knew someone would argue that way :) But keep in mind that the
former are features with a long history and so are not only standardized
but widely similarly implemented, while XMLHttpRequest is, compared to
that, a relative young technology and it shows (e.g. on the Opera example)
that implementations of it are currently rather volatile: M$ provides it
as ActiveX object i.e. depends on another proprietary technology that is
also subject to change, while the Mozilla Foundation implements it directly
in the Gecko DOM and only the Gods of the North know how Opera implements
it ;-)
I'll wager that XMLHTTPRequest survives HTML
Since it uses XML as its targeted data format, so much is for sure.
On the other hand, I don't think that HTML is going to be extinct
within the next 5 years. (You may quote me being wrong if it's no
longer there before ;-))
and that it will be standardized/specification'ized within
two or three years (although maybe not by the W3C).

I can only hope so, and what Martin pointed to looks promising. However,
what is implemented then and how useful and stable those implementations
will be in reality is, as you stated correctly, a completely different
issue.
PointedEars