|
|
Posted by bkardell@gmail.com on 04/10/07 20:43
>I really hate this.
Ok... Let's talk about why - this is a great place to debate.
>It couples content (server-AJAX client
>communications) with presentation (HTML DOM) in a horrible manner.
I disagree: In a model-view-controller architecture, N-tier design,
templating systems like asp,jsp,php,velocity (etc) provide the
"view". The view is HTML which is interpreted by your browser to form
a tree. When you get right down to it - the tree is all you have in
the Web browser - there's nothing else. The tree therefore _is_ the
view and providing updates to the tree is intuitive, simple, follows
all of the traditional seperations of responsibility and retains all
of the benefits that we originally thought were so great about Web-
based applications in the first place.
>If you work with AJAX today then you soon recognise the existence of good
>AJAX patterns (client-side application of appropriate presentation to
>a pure-content AJAX document) and bad AJAX patterns ('90s-style HTML
>supplied in dribbles). This DUML is clearly in the later group.
Again, I disagree. If you work with AJAX today, you will notice that
it is a confoundingly complex solution to two very simple problems: 1)
HTML does not provide markup for components in the same way that
windowing frameworks provide 'controls' like trees, accordions, menus,
etc. Therefore it is up to someone to emulate all of those things via
nodes in a tree + JavaScript to create documents that are dynamic in
presentation (IAML is the simple solution to that one). - 2) Documents
(which is all a browser can consume) are static, but we really want
them to be dynamic in _content_ (DUML is the simple solution to that
one). Good engineering is, by its definition, simple. Something that
is well engineered provides simplicity to something that was formerly
complex. Every evolution in techology has historically proven this to
be true: C was originally considered a "high level language" - but
today developers in general consider it to be "too low level" to
develop most applications in. Ajax applications like the ones you are
describing are essentially fat clients because in order to be "well-
written" and maintainable they have to be highly engineered with lots
of Object oriented JavaScript. These applications invariably wind up
containing a whole model-view-controller (including what comes down to
business logic) on the client machine. This is confounded by the fact
that the various payload formats that you communicate back and forth
with are essentially very simplified data transfer objects - not the
ones that you generally work with in terms of making logical
descisions or updating the tree with (at least not if you are really
following good engineering practices). Thus - essentially you wind up
with a JavaScript based mini model-view-controller which often
duplicates and obfuscates the server's models and views. Your design
has to deal with creating requests by either pure JavaScript or (more
likely) pulling back and forth out of the tree, serializing that data
in the form of making a request and sending some kind of generic
payload (XML/JSON/ETC) which are built with very simple constructs
(arrays, maps, strings) and then deserializing them on the server,
interpreting those into real objects which you can use intelligently
and then reversing the whole process. And why? To update the tree?
Adding several orders of magnitude worth of complexity, breaking logic
across tiers, creating security problems and tranaction management
nightmares in JavaScript, etc in the name of 'good design' seems to
actually counter the argument that you are trying to make (that 'good
ajax patterns' like the ones described here are better engineered than
the proposed solution).
>As a server application, I don't _want_ to know anything about any
>sort of client-side feature like a DOM. I'm looking at SOA here,
>where the _client_ has control over the server and the transactions.
>The server's task is just to respond with what it's asked for, as a
>suitably entitled client demands it. It's not the server's task to
>assemble "an application" out of all these fragments. This gives a very clean and simple
>server implementation and it also allows a lot of client-side flexibility as to how
>sophisticated the app wishes to be (often tailored according to local interface abilities).
I think that you are missing some key aspects of both SOA and N-tier
design here. First, Service oriented architecture is not limited to
XML - in fact - good service oriented architure provides the most
appropriate level interface to the requesting client. If the best I
can give you is the universal SOAP or XML-RPC service, then that is
what you will get. However, if you are Java and I am Java - you
should get a Java>Java connection but never know the difference
(except possibly speed) because you are dealing with the service, not
the actual implemenation. The Web browser is not an appropriate place
to be consuming SOA services because you are drawing the N-tier
diagram incorrectly. The tier that provides XML services is not the
same Web/View tier - in fact - an application server that generates
views would _use_ those services (and in this case, hopefully most of
the time use the native-to-native implementation). It is _precisely_
the Web/View server's task to assemble an application out of these
fragments - it is _not_ the SOA tier's task. You can base any number
of clients on the SOA tier, but what you are talking about here is a
_specific_ client and the implementation of the specific client is
HTML: So why worry about all of that complexity on the client?
>This is the sort of ugly server-push technology (anyone remember
>Marimba?) that belongs back in the late-90s and before AJAX.
Thanks :)
Navigation:
[Reply to this message]
|