DUML

[bkardell]

DUML (Document Update Markup Language) is a new, simple decalrative
approach to AJAX which allows the server to send markup back to the
client and have it interpreted in order to update the DOM tree.

It has a companion project called IAML (Interpreted Application Markup
Language) which also provides application based markup for typical GUI
compoents akin to XUML, XAML or FLEX.

The entire codebase that makes both possible is <60k, uncompressed.

Please read and give us some feedback - it's just gone open source and
it's currently being used successfully in numerous applications at the
University of Phoenix.

http://www.duml.org
http://www.duml.org/wiki

 

[Richard Formby]

(e-mail address removed) wrote

[a bunch of stuff about something I first thought meant DUMb htmL ]

Then I look at:

http://www.duml.org

Why do I need to spin my mouse wheel through several revolutions to make
your DUMbLy small text big enough to even see, let alone read?

And when I do wind up the font size your left hand menu escapes, invisibly,
out of its box.

What, for &deity's sake, is wrong with the font size
<superstrong>I</superstrong> have chosen for *my* browsing enjoyment?

 

[Andy Dingley]

DUML (Document Update Markup Language) is a new, simple decalrative
approach to AJAX which allows the server to send markup back to the
client and have it interpreted in order to update the DOM tree.

I really hate this. It couples content (server-AJAX client
communications) with presentation (HTML DOM) in a horrible manner. 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.

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).

This is the sort of ugly server-push technology (anyone remember
Marimba?) that belongs back in the late-90s and before AJAX.

 

[bkardell]

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

 

[Andy Dingley]

In a model-view-controller architecture, N-tier design,

Be careful when conflating N-tier with MVC. You can produce some
braind-dead pseudo-MVC that way.

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.

If you're using AJAX, why are you duplicating a "view" onto the
server? This is my basic criticism of DUML - it's a server-side
rendition of a view that doesn't (and shouldn't) exist until it hits
the client.

Abstract SOA architectures should only provide a model. They can't do
this in practice, so SOA-based interactive applications in particular
find themselves implementing a controller too. They certainly
shouldn't be implementing the view though, that sits as close to the
client as possible. If you have AJAX, then you instantiate the view on
the client. If you only have a dumb HTML client, then you might have
to push view-generation back to the server (that's OK too). What you
should avoid is having AJAX available yet getting no more benefit from
it than access to a server-geneated view. What's _really_ bad is DUML,
the idea that some client-DOM-tweaking language has any justification
for being anywhere near the server. That's even a retrograde step back
from 1991 HTML.

 

[shimmerism]

What's _really_ bad isDUML, <sic>
the idea that some client-DOM-tweaking language has any justification
for being anywhere near the server.

Can you provide a cogent argument for why you believe this?

 

[eric.schleicher]

Be careful when conflating N-tier with MVC. You can produce some
braind-dead pseudo-MVC that way.

Is DUML an n-tier implementation? It seems that could be part of one,
but that's all backend (server) engineering. Straight Ajax and hefty
client javascript view controller logic does not an n-tier make. In
most solutions I've seen, the closest description that comes to mind
is not even tiered, and bears more resemblance to italian pasta. It's
seems DUML+IAML together fit very nicely within MVC and n-tier.

-----

If you're using AJAX, why are you duplicating a "view" onto the
server? This is my basic criticism ofDUML- it's a server-side
rendition of a view that doesn't (and shouldn't) exist until it hits
the client.

I think that there is a very compelling argument that most if not all
current AJAX applications are guilty of the "duplication". Pushing
the view controller out to the client is OK, but the rubber hits the
road when complex business requirments compromise the ablity of the
view controller to be isolated on the client. Invariably, the end
result has shipped the business logic out to the client, where it
clearly doesn't belong. This is an egregious violation of n-Tier
design, AJAX or not. The end result are applications with gobs of non-
view related logic residing on the client, where debugging is a
challenge, and the bittle nature of DOM is exascerbated by no clear
delineation between view controller and business logic since most
developers are just excited to get it work, let alone have it conform
to any respectable design pattern.

--------

Abstract SOA architectures should only provide a model. They can't do
this in practice, so SOA-based interactive applications in particular
find themselves implementing a controller too. They certainly
shouldn't be implementing the view though, that sits as close to the
client as possible.

Why? One of us must not understand what SOA is and where it's best
consumed in an application context. It's always been my understanding
that SOA is best consumed by the model controller. and then the view
controller determines how it's presented. Am I missing something?

If you have AJAX, then you instantiate the view on
the client. If you only have a dumb HTML client, then you might have
to push view-generation back to the server (that's OK too). What you
should avoid is having AJAX available yet getting no more benefit from
it than access to a server-geneated view.

Really? There are incredibly synergies realized from having the model
and view controller both on the server. The AJAX providing "Just" the
view generation is a strength. You end up with light weight clients,
a proper development environment, and well formed MVC and n-tier
ability for free.

What's _really_ bad isDUML,
the idea that some client-DOM-tweaking language has any justification
for being anywhere near the server. That's even a retrograde step back
from 1991 HTML.

It's my understanding that in DUML, the DOM "tweaking" still happens
on the client, but based on instructions from a server, how is that
any different from shipping all that logic out to the client, where
debugging is a huge PITA.

-Eric

 

[bkardell]

Be careful when conflating N-tier with MVC. You can produce some

braind-dead pseudo-MVC that way.

I don't necessarily think that I am conflating them if you read the
rest of the paragraph and take it in context. The thing that N-tier
and MVC share is the clear seperation of presentation, data and logic
- the difference is in communication and in my opinion largely
theoretical and not really worth discussing here since even in N-tier,
the presentation tier needs to deal with drawing some kind of data
(model). I don't mean to minimize anything - just want to focus the
conversation and not go off on a tangent. If you disagree, please let
me know why you think that this is so critical a point and we can talk
some more.

If you're using AJAX, why are you duplicating a "view" onto the
server?

Not duplicating - let me be extremely clear on this point: There is no
duplication in DUML. Models/views (in the form of markup) and
controllers exist on the server, only a proxy/interpreter exist on the
client. In the model that you are advocating, a much more gross
violation is likely of duplicating (or creating additional) layers of
logic and model. In the DUML model all actual modification of the
tree is done via the interpreter on the client, but the logic that
says what should be modified comes from the server. The instantiation
of the view (the tree) is what exists on the client - as it always has
been: Contrary to popular belief markup != tree. Markup is code, tree
is instance. Markup describes tree. View logic writes markup.

I realize that the initial impression is that this would seem to
indicate that you have to have some kind of simulated tree on the
server to keep track of what is going on, but in practice this
couldn't be further from the truth and I can virtually guarantee that
the alternatives are doing every bit of work on the server that most
applications currently using DUML are - and then some (as well as
much, much more on the client). When you think of HTML you think of
documents that contain thousands of nodes. When you think about AJAX,
you think about all of the single node manipulation that you have to
do to make it happen. While you have that ability in DUML as well,
being able to replicate all of these complicated node manipulations as
simple markup invariably leads to simple, elegant design that does not
require such. Even the structure of the language itself (its fail-
fast nature and the ability to condition manipulations) helps prevent
this kind of scenario.

This is my basic criticism ofDUML- it's a server-side
rendition of a view that doesn't (and shouldn't) exist until it hits
the client.

It doesn't exist until it hits the client (see above), but I don't
think that you stated that quite how you meant it so let me clarrify:
Essentially you want the Web browser to work like a fat-client program
that is installed whenever you go to the page... Is that it? I know
that that might sound argumentative or condescending and that is not
my intent - it just seems to be the simplest way to describe it... If
that is the case - why not just write a fat client in any number of
technologies with auto update - almost any of which would be
considerably more secure, faster and more robust than the Web browser?

Abstract SOA architectures should only provide a model. They can't do
this in practice, so SOA-based interactive applications in particular
find themselves implementing a controller too.

Why can they not do this? I have personally worked on a team which
implemented SOA in precisely that way. Maybe I am misunderstanding
what you mean by the "this" that they can't do... Can you explain?

They certainly
shouldn't be implementing the view though, that sits as close to the
client as possible. If you have AJAX, then you instantiate the view on
the client. If you only have a dumb HTML client, then you might have
to push view-generation back to the server (that's OK too). What you
should avoid is having AJAX available yet getting no more benefit from
it than access to a server-geneated view. What's _really_ bad isDUML,
the idea that some client-DOM-tweaking language has any justification
for being anywhere near the server. That's even a retrograde step back
from 1991 HTML.

This is the second time that you have made the statement that this is
a retrograde step from "even 1991 HTML" (or something like it) and
stating that somehow you get more 'benefit' from the alternative. I
have two comments about this. 1) HTML, at least well implemented
HTML, has changed remarkably little since the 90's - and so has the
browser. This is the technology. It is based on documents and based
on trees and the only reason we ever developed Web applications with
it in the first place is because it provides a thin, universal client
which requires 0-install and allows businesses to write and maintain
the whole thing on the server - including the simple, markup based UI
- using whatever technologies please them today. If that's not what
you want... If you want the 'benefits' of a fat client - again - why
not use a more rational technology for the job. 2) Please - PLEASE
explain the benefit of the alternative. That it makes our thin client
fatter? That it adds lot and lots of complexity? That it moves logic
into the Web browser where it's insecure, harder to develop, test and
debug, has limited memory resources, easily leaks, often requires
security hacks (ie. script hack) to develop something 'good', etc.
etc.? Or is it just really about this idea that somehow you can then
'easily' develop a new SOA-based client in whatever technology you
want very quickly - Because apparently we disgree on several points
there: a) that you can not/do not get the same from a DUML approach (I
say you can because SOA can be consumed on the server where it makes a
lot of sense) and that - b) Whether what you seem to infer about the
clean/quick client implementation bit is actually true (I would say
that in fact it is quite complicated, over-engineered, time consuming,
error prone, etc).

DUML restores and respects all of those reasons that we went to the
browser in the first place (see above) and does so with very simple
and intuitive mechanisms.

 

[bkardell]

Be careful when conflating N-tier with MVC. You can produce some

braind-dead pseudo-MVC that way.

I don't necessarily think that I am conflating them if you read the
rest of the paragraph and take it in context. The thing that N-tier
and MVC share is the clear seperation of presentation, data and logic
- the difference is in communication and in my opinion largely
theoretical and not really worth discussing here since even in N-tier,
the presentation tier needs to deal with drawing some kind of data
(model). I don't mean to minimize anything - just want to focus the
conversation and not go off on a tangent. If you disagree, please let
me know why you think that this is so critical a point and we can talk
some more.

If you're using AJAX, why are you duplicating a "view" onto the
server?

Not duplicating - let me be extremely clear on this point: There is no
duplication in DUML. Models/views (in the form of markup) and
controllers exist on the server, only a proxy/interpreter exist on the
client. In the model that you are advocating, a much more gross
violation is likely of duplicating (or creating additional) layers of
logic and model. In the DUML model all actual modification of the
tree is done via the interpreter on the client, but the logic that
says what should be modified comes from the server. The instantiation
of the view (the tree) is what exists on the client - as it always has
been: Contrary to popular belief markup != tree. Markup is code, tree
is instance. Markup describes tree. View logic writes markup.

I realize that the initial impression is that this would seem to
indicate that you have to have some kind of simulated tree on the
server to keep track of what is going on, but in practice this
couldn't be further from the truth and I can virtually guarantee that
the alternatives are doing every bit of work on the server that most
applications currently using DUML are - and then some (as well as
much, much more on the client). When you think of HTML you think of
documents that contain thousands of nodes. When you think about AJAX,
you think about all of the single node manipulation that you have to
do to make it happen. While you have that ability in DUML as well,
being able to replicate all of these complicated node manipulations as
simple markup invariably leads to simple, elegant design that does not
require such. Even the structure of the language itself (its fail-
fast nature and the ability to condition manipulations) helps prevent
this kind of scenario.

This is my basic criticism ofDUML- it's a server-side
rendition of a view that doesn't (and shouldn't) exist until it hits
the client.

It doesn't exist until it hits the client (see above), but I don't
think that you stated that quite how you meant it so let me clarrify:
Essentially you want the Web browser to work like a fat-client program
that is installed whenever you go to the page... Is that it? I know
that that might sound argumentative or condescending and that is not
my intent - it just seems to be the simplest way to describe it... If
that is the case - why not just write a fat client in any number of
technologies with auto update - almost any of which would be
considerably more secure, faster and more robust than the Web browser?

Abstract SOA architectures should only provide a model. They can't do
this in practice, so SOA-based interactive applications in particular
find themselves implementing a controller too.

Why can they not do this? I have personally worked on a team which
implemented SOA in precisely that way. Maybe I am misunderstanding
what you mean by the "this" that they can't do... Can you explain?

They certainly
shouldn't be implementing the view though, that sits as close to the
client as possible. If you have AJAX, then you instantiate the view on
the client. If you only have a dumb HTML client, then you might have
to push view-generation back to the server (that's OK too). What you
should avoid is having AJAX available yet getting no more benefit from
it than access to a server-geneated view. What's _really_ bad isDUML,
the idea that some client-DOM-tweaking language has any justification
for being anywhere near the server. That's even a retrograde step back
from 1991 HTML.

This is the second time that you have made the statement that this is
a retrograde step from "even 1991 HTML" (or something like it) and
stating that somehow you get more 'benefit' from the alternative. I
have two comments about this. 1) HTML, at least well implemented
HTML, has changed remarkably little since the 90's - and so has the
browser. This is the technology. It is based on documents and based
on trees and the only reason we ever developed Web applications with
it in the first place is because it provides a thin, universal client
which requires 0-install and allows businesses to write and maintain
the whole thing on the server - including the simple, markup based UI
- using whatever technologies please them today. If that's not what
you want... If you want the 'benefits' of a fat client - again - why
not use a more rational technology for the job. 2) Please - PLEASE
explain the benefit of the alternative. That it makes our thin client
fatter? That it adds lot and lots of complexity? That it moves logic
into the Web browser where it's insecure, harder to develop, test and
debug, has limited memory resources, easily leaks, often requires
security hacks (ie. script hack) to develop something 'good', etc.
etc.? Or is it just really about this idea that somehow you can then
'easily' develop a new SOA-based client in whatever technology you
want very quickly - Because apparently we disgree on several points
there: a) that you can not/do not get the same from a DUML approach (I
say you can because SOA can be consumed on the server where it makes a
lot of sense) and that - b) Whether what you seem to infer about the
clean/quick client implementation bit is actually true (I would say
that in fact it is quite complicated, over-engineered, time consuming,
error prone, etc).

DUML restores and respects all of those reasons that we went to the
browser in the first place (see above) and does so with very simple
and intuitive mechanisms.

 

[Andy Dingley]

Can you provide a cogent argument for why you believe this?

It's excessive coupling between the server and the client's DOM. Why
should the server even know what structure the client's DOM looks
like? Are we then to force all clients to implement matching DOMs and
user controls? If the server offers a simple abstract document format
in some minimal format (classic non-3.2 HTML) then at least we've
decoupled this much.

Ideally (and well-architected AJAX is a good step towards it) we move
beyond this to an even less document-centric and more data-centric
transport format. We certainly don't go in DUML's direction, where
intimate details of how the client _implements_ its controls has to be
built into the document (and so also the server).

 

[bkardell]

Be careful when conflating N-tier with MVC. You can produce some

braind-dead pseudo-MVC that way.

I don't necessarily think that I am conflating them if you read the
rest of the paragraph and take it in context. The thing that N-tier
and MVC share is the clear seperation of presentation, data and logic
- the difference is in communication and in my opinion largely
theoretical and not really worth discussing here since even in N-tier,
the presentation tier needs to deal with drawing some kind of data
(model). I don't mean to minimize anything - just want to focus the
conversation and not go off on a tangent. If you disagree, please let
me know why you think that this is so critical a point and we can talk
some more.

If you're using AJAX, why are you duplicating a "view" onto the
server?

Not duplicating - let me be extremely clear on this point: There is no
duplication in DUML. Models/views (in the form of markup) and
controllers exist on the server, only a proxy/interpreter exist on the
client. In the model that you are advocating, a much more gross
violation is likely of duplicating (or creating additional) layers of
logic and model. In the DUML model all actual modification of the
tree is done via the interpreter on the client, but the logic that
says what should be modified comes from the server. The instantiation
of the view (the tree) is what exists on the client - as it always has
been: Contrary to popular belief markup != tree. Markup is code, tree
is instance. Markup describes tree. View logic writes markup.

I realize that the initial impression is that this would seem to
indicate that you have to have some kind of simulated tree on the
server to keep track of what is going on, but in practice this
couldn't be further from the truth and I can virtually guarantee that
the alternatives are doing every bit of work on the server that most
applications currently using DUML are - and then some (as well as
much, much more on the client). When you think of HTML you think of
documents that contain thousands of nodes. When you think about AJAX,
you think about all of the single node manipulation that you have to
do to make it happen. While you have that ability in DUML as well,
being able to replicate all of these complicated node manipulations as
simple markup invariably leads to simple, elegant design that does not
require such. Even the structure of the language itself (its fail-
fast nature and the ability to condition manipulations) helps prevent
this kind of scenario.

This is my basic criticism ofDUML- it's a server-side
rendition of a view that doesn't (and shouldn't) exist until it hits
the client.

It doesn't exist until it hits the client (see above), but I don't
think that you stated that quite how you meant it so let me clarrify:
Essentially you want the Web browser to work like a fat-client program
that is installed whenever you go to the page... Is that it? I know
that that might sound argumentative or condescending and that is not
my intent - it just seems to be the simplest way to describe it... If
that is the case - why not just write a fat client in any number of
technologies with auto update - almost any of which would be
considerably more secure, faster and more robust than the Web browser?

Abstract SOA architectures should only provide a model. They can't do
this in practice, so SOA-based interactive applications in particular
find themselves implementing a controller too.

Why can they not do this? I have personally worked on a team which
implemented SOA in precisely that way. Maybe I am misunderstanding
what you mean by the "this" that they can't do... Can you explain?

They certainly
shouldn't be implementing the view though, that sits as close to the
client as possible. If you have AJAX, then you instantiate the view on
the client. If you only have a dumb HTML client, then you might have
to push view-generation back to the server (that's OK too). What you
should avoid is having AJAX available yet getting no more benefit from
it than access to a server-geneated view. What's _really_ bad isDUML,
the idea that some client-DOM-tweaking language has any justification
for being anywhere near the server. That's even a retrograde step back
from 1991 HTML.

This is the second time that you have made the statement that this is
a retrograde step from "even 1991 HTML" (or something like it) and
stating that somehow you get more 'benefit' from the alternative. I
have two comments about this. 1) HTML, at least well implemented
HTML, has changed remarkably little since the 90's - and so has the
browser. This is the technology. It is based on documents and based
on trees and the only reason we ever developed Web applications with
it in the first place is because it provides a thin, universal client
which requires 0-install and allows businesses to write and maintain
the whole thing on the server - including the simple, markup based UI
- using whatever technologies please them today. If that's not what
you want... If you want the 'benefits' of a fat client - again - why
not use a more rational technology for the job. 2) Please - PLEASE
explain the benefit of the alternative. That it makes our thin client
fatter? That it adds lot and lots of complexity? That it moves logic
into the Web browser where it's insecure, harder to develop, test and
debug, has limited memory resources, easily leaks, often requires
security hacks (ie. script hack) to develop something 'good', etc.
etc.? Or is it just really about this idea that somehow you can then
'easily' develop a new SOA-based client in whatever technology you
want very quickly - Because apparently we disgree on several points
there: a) that you can not/do not get the same from a DUML approach (I
say you can because SOA can be consumed on the server where it makes a
lot of sense) and that - b) Whether what you seem to infer about the
clean/quick client implementation bit is actually true (I would say
that in fact it is quite complicated, over-engineered, time consuming,
error prone, etc).

DUML restores and respects all of those reasons that we went to the
browser in the first place (see above) and does so with very simple
and intuitive mechanisms.

 

[bkardell]

Be careful when conflating N-tier with MVC. You can produce some

braind-dead pseudo-MVC that way.

I don't necessarily think that I am conflating them if you read the
rest of the paragraph and take it in context. The thing that N-tier
and MVC share is the clear seperation of presentation, data and logic
- the difference is in communication and in my opinion largely
theoretical and not really worth discussing here since even in N-tier,
the presentation tier needs to deal with drawing some kind of data
(model). I don't mean to minimize anything - just want to focus the
conversation and not go off on a tangent. If you disagree, please let
me know why you think that this is so critical a point and we can talk
some more.

If you're using AJAX, why are you duplicating a "view" onto the
server?

Not duplicating - let me be extremely clear on this point: There is no
duplication in DUML. Models/views (in the form of markup) and
controllers exist on the server, only a proxy/interpreter exist on the
client. In the model that you are advocating, a much more gross
violation is likely of duplicating (or creating additional) layers of
logic and model. In the DUML model all actual modification of the
tree is done via the interpreter on the client, but the logic that
says what should be modified comes from the server. The instantiation
of the view (the tree) is what exists on the client - as it always has
been: Contrary to popular belief markup != tree. Markup is code, tree
is instance. Markup describes tree. View logic writes markup.

I realize that the initial impression is that this would seem to
indicate that you have to have some kind of simulated tree on the
server to keep track of what is going on, but in practice this
couldn't be further from the truth and I can virtually guarantee that
the alternatives are doing every bit of work on the server that most
applications currently using DUML are - and then some (as well as
much, much more on the client). When you think of HTML you think of
documents that contain thousands of nodes. When you think about AJAX,
you think about all of the single node manipulation that you have to
do to make it happen. While you have that ability in DUML as well,
being able to replicate all of these complicated node manipulations as
simple markup invariably leads to simple, elegant design that does not
require such. Even the structure of the language itself (its fail-
fast nature and the ability to condition manipulations) helps prevent
this kind of scenario.

This is my basic criticism ofDUML- it's a server-side
rendition of a view that doesn't (and shouldn't) exist until it hits
the client.

It doesn't exist until it hits the client (see above), but I don't
think that you stated that quite how you meant it so let me clarrify:
Essentially you want the Web browser to work like a fat-client program
that is installed whenever you go to the page... Is that it? I know
that that might sound argumentative or condescending and that is not
my intent - it just seems to be the simplest way to describe it... If
that is the case - why not just write a fat client in any number of
technologies with auto update - almost any of which would be
considerably more secure, faster and more robust than the Web browser?

Abstract SOA architectures should only provide a model. They can't do
this in practice, so SOA-based interactive applications in particular
find themselves implementing a controller too.

Why can they not do this? I have personally worked on a team which
implemented SOA in precisely that way. Maybe I am misunderstanding
what you mean by the "this" that they can't do... Can you explain?

They certainly
shouldn't be implementing the view though, that sits as close to the
client as possible. If you have AJAX, then you instantiate the view on
the client. If you only have a dumb HTML client, then you might have
to push view-generation back to the server (that's OK too). What you
should avoid is having AJAX available yet getting no more benefit from
it than access to a server-geneated view. What's _really_ bad isDUML,
the idea that some client-DOM-tweaking language has any justification
for being anywhere near the server. That's even a retrograde step back
from 1991 HTML.

This is the second time that you have made the statement that this is
a retrograde step from "even 1991 HTML" (or something like it) and
stating that somehow you get more 'benefit' from the alternative. I
have two comments about this. 1) HTML, at least well implemented
HTML, has changed remarkably little since the 90's - and so has the
browser. This is the technology. It is based on documents and based
on trees and the only reason we ever developed Web applications with
it in the first place is because it provides a thin, universal client
which requires 0-install and allows businesses to write and maintain
the whole thing on the server - including the simple, markup based UI
- using whatever technologies please them today. If that's not what
you want... If you want the 'benefits' of a fat client - again - why
not use a more rational technology for the job. 2) Please - PLEASE
explain the benefit of the alternative. That it makes our thin client
fatter? That it adds lot and lots of complexity? That it moves logic
into the Web browser where it's insecure, harder to develop, test and
debug, has limited memory resources, easily leaks, often requires
security hacks (ie. script hack) to develop something 'good', etc.
etc.? Or is it just really about this idea that somehow you can then
'easily' develop a new SOA-based client in whatever technology you
want very quickly - Because apparently we disgree on several points
there: a) that you can not/do not get the same from a DUML approach (I
say you can because SOA can be consumed on the server where it makes a
lot of sense) and that - b) Whether what you seem to infer about the
clean/quick client implementation bit is actually true (I would say
that in fact it is quite complicated, over-engineered, time consuming,
error prone, etc).

DUML restores and respects all of those reasons that we went to the
browser in the first place (see above) and does so with very simple
and intuitive mechanisms.

 

[bkardell]

Ideally (and well-architected AJAX is a good step towards it) we move

beyond this to an even less document-centric and more data-centric
transport format. We certainly don't go inDUML'sdirection, where
intimate details of how the client _implements_ its controls has to be
built into the document (and so also the server).

Ok - let's talk about your opinion of 'well-architected ajax'... Let
me pose a question. Let's say, for example, that 1 part of your
application contains a wizard of sorts. 10 questions - each possible
answer to a question has 10 follow-up questions and each of those
possible answers has a follow-up question with 10 possible answers.
In the end there is a single result based on your combination of
answers to question a, b and c. Of course - each question and answer
should be somehow configurable in case our business change - as should
their view. In the case of duml, you might start out with a form with
one question and the possible answers. The UI follows the traditional
model and simply submits the form (although asynchronously with a
single, simple line). On the server, we can do whatever we want in
terms of how to generate what comes next: Could be any question we
want, displayed any way that we want, with any variable number of
possible answers. We might provide access to that data on the server
via SOA - or maybe not - SOA isn't the end-all, be all answer.
Sometimes a Web application is just a Web application. But we might -
we have that option. And we can consume that service in any manner
available and appropriate via an abstract naming interface: Perhaps
the implementation is an EJB, perhaps it's a POJO, perhaps SOAP
controlled by a .net server - it really doesn't matter because _thats_
where N-tier pays off. There might even be an error - it really
doesn't matter because there are lots and lots of well-defined
architectures that already exist for this kind of thing - the only
difference being that we dont have to regenerate an entire document.
The result might be "append this question now" or it might be "display
an error" or it might be "execute such and such script". Each one of
these fragments is stored off in a file somewhere (just like you would
in lots of frameworks like tiles or even old style includes) so that
they can be decorated by HTML or DUML instructions to create RESTful
scenarios where appropriate. In the end, these things can use XML,
XSL, rules engines, struts, springs, .net stuff, whatever you want.
It's very, very simple and intutive - despite the fact that the
potential net results are 100's of possible node-manipulations defined
according configurable rules.

Explain a similarly high level account of how your 'good' ajax
patterns would handle this?