|
|
Posted by bkardell@gmail.com on 04/12/07 05:13
> 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?
Navigation:
[Reply to this message]
|