On 4/12/07, Jerome Louvel <[EMAIL PROTECTED]> wrote: [...]
What is essential is that your core domain model is well defined and reused by all your view resources. This core domain model can also be distributed and implemented as RESTful resource if you can afford this flexibility.
FWIW, I think people use performance as an excuse to not model their systems this way to begin with. Indeed, the flexibility can help improve performance.
> I've been thinking a lot about this too, and I came to the > conclusion that > the best way to put a face on a restfull app is the have the > client -not > the server- assemble the view. > The simplest (an ugliest) way is to use frames; a better solution is > to make Ajax calls to the server to retrieve individual > resources, and > insert the returned html (or xml, json, etc) in the page. > It also scales better if the application is stateless (no > need to retrieve the > profile each time we display a post). > Of course, this is valid only for relatively complex > application(e.g. a webmail > client). But if your application is restul and your UI > moderately complex, it > calls for a single-page UI (a la GWT) as opposed as the > standard multi-page > design. My concern with those approaches (AJAX) is that they somewhat break the hyperlink design of the Web, and the ability to bookmark each state of your application.
Well, our application (krugle.com) is a pretty hardcore AJAX application. In terms of Vincent's points, AJAX is a perfectly reasonable solution (but has other tradeoffs). It's certainly possible to support both a clean, pure page approach as well as an AJAX client. This is where having a multiple views approach can really payoff big (especially when you think about also having a public api :-). Supporting bookmarkable URLs in AJAX applications is more of a UI issue than a technical one. Back button support is a much more painful topic. :-) Take care, John
