Re: Question to all about visual webapps and Restlet
Very interesting discussion indeed. I've been experimenting with building visual REST applications – I used href="http://www.frevvo.com";>frevvo and http://www.restlet.org";>Restlet (I work for frevvo). I've posted a couple of blog articles about my experiences and I'm definitely interested in knowing how other people are building visual web applications with REST. You can find much more including diagrams, examples and source code at: http://www.frevvo.com/blog/?p=26";>Visual REST apps: Part 1 http://www.frevvo.com/blog/?p=32";>Visual REST apps: Part 2 I tend to think in terms of View Resource (forms) that compose Entity Resources (documents). The View Resource can update existing entities, create new ones, store locally or update remotely – all in a uniform RESTful manner. IMO, it's a very powerful and flexible way to interact with the web and create REST applications that handle complex visual elements without compromising REST principles. I'd be very interested in your thoughts. Thx, -Ashish Matthieu Hug wrote: Vincent yahoo.ca> writes: Hi Matthieu, Hello Vincent You'll find comments within the text below. Best regards, Basically I've a rich client application (Flex) accessing Ah, but it's quite a different story, as the final (visual) representation is assembled on the client, not on the server. Absolutly. I considered each resource as being kind of a "virtual web page", with one URI and one (or several if required) "layouts" (representations). The application accesses the required resources, and assembles them for display. So if one page displays A and B, and another page displays A, B, and C, A knows it has two layouts (a/B and A/B/C). If you later add D to the page, you'll add a third layout for A. Is that correct? "layout" is really misleading, sorry about that: it was meant to relate to restlet's representation (the way the resource is viewed by the client), not to the display within the client. All resources are represented as atom feeds: so the representation (which I wrongly called "layout") in restlet sense is this atom feed; then the client displays it as it wishes. So A does not know (and shouldn't IMHO) it can be dispayed with B or with B/C. If D is added later, and it is independent from A and it is only a client issue. An important point is that each resource includes links to all other resources it is logically linked to: the client has absolutly NO knowledge of the links between resources, it virtually navigates between them as needed. If A is linked to A and B, when the client accesses A it receives its representation, including a link to B and a link to C; Let say these resources are independent one of another (For instance if A is a weather report, B a news feed, and C your profile). Who is responsible for linking them together? Does A know it's linked to B and C, or are these associations established at a higher level? If resources are independent there're not linked together. The link must be meaningful in a business sense. There could definitly be a higher level resource that associates independent resources. For instance, let's say that your example relates to a personal mashup, something like google personal page or netvibes. Then you could consider that C contains links to B and A (the user chose B and A among a series of mashups, and its part of his profile), but A and B are not linked together (another user could use A without B). In that case C would stand for the higher level resource. A's representation contains a link to B and C, which means the client has to GET and C, and pass their representation to the template in order to generate the page. So, do B and C's representations contain links to A? The client indeed navigates through the resources and the links provided in their representation exactly like a human would navigate through web pages: it has no other knowledge than the links provided by resources (no resource can be accessed if it is not linked by a previously loaded resource). Then it is not mandatory to have symmetric links. Resources are really analoguous to web pages: many pages have links to Amazon, but Amazon does not have symmetric links to all of them. However until now symmetric links proved to be useful to navigate between resources of the application. -vincent.
Re: Question to all about visual webapps and Restlet
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
Re: Question to all about visual webapps and Restlet
On 4/11/07, Vincent <[EMAIL PROTECTED]> wrote: [...] > I think it's helpful to think in terms of fundamental, "base" > resources and composite, "view" resources. > [...] > For other cases, I think it makes more sense to have the facets more > or less completely disjoint. The human useful, composite views may > make a lot more sense to the user if they have their own naming > hierarchy, etc. and just use the various, lower-level resources as > services, if you will, that are managed separately. Are you saying views should be first-class resources. and GET 'lower-level' resources to assemble the page? If yes, what's the need for the lower-level resources? The ForumView resource would just retrieve the object it needs from the DB (profile and post in Jeff's example), inject them in the template and return the template's result. If the lower level resources are all completely captive to a single server then there's arguably no benefit. However, it makes things a lot easier to horizontally and vertically partition and otherwise scale the system. For example, what happens when the lower level resource starts dominating the run-time? If it's already a clearly defined and easily identified resource then it should be trivially easy to move it to another server. Hope this helps, John
Re: Question to all about visual webapps and Restlet
Hi Jerome, > > > > But maybe the page you return to depends on the result of the > > operation. It's not a decision the client can make. > > Ok, in this case your "/orange/editor" resource can issue a redirect to the > target URI dynamically generated. I guess the problem is that when you design a restful application you start modeling your domain model into resources. When you need to plug in a web interface on top of this, you realize that you need a whole new set of resources (page, editor, etc). I think the post that started this thread was about what those resources should look like. I still don't have a clear answer. My client is a swing app; therefore, I'm only concerned with my domain resources. Same thing with a GWT-type UI. It'd be to have the proverbial pet shop application ported to the Restlet framework. How about running a poll to find out what presentation layer people use with their restlet app? [] dotnet/swing/swing [] flex [] html - pages assembled on the server(jsp, velocity, etc.) [] html - pages assembled on the client (one-page apps a la GWT) > > Would not that be like saying: > >/document/123;font=large > >/document/123;font=small > > > > identify 2 resources? > > Exactly, each time you change the URI, even to simply add a query parameter, > you create a different identifier. This new identifier correspond to a > different target resource! Why would you diffentiate > "/document/123;font=large" from "/document/123/large"? From the REST/HTTP > point of view, two different URIs identify two different resources. Point taken. -Vincent.
Re: Question to all about visual webapps and Restlet
Vincent yahoo.ca> writes: > > Hi Matthieu, Hello Vincent You'll find comments within the text below. Best regards, > > > Basically I've a rich client application (Flex) accessing > > Ah, but it's quite a different story, as the final (visual) representation is > assembled on the client, not on the server. > Absolutly. > > I considered each resource as > > being kind of a "virtual web page", with one URI and one (or several if > > required) "layouts" (representations). The application accesses the > > required > > resources, and assembles them for display. > > So if one page displays A and B, and another page displays A, B, and C, > A knows it has two layouts (a/B and A/B/C). If you later add D to the page, > you'll add a third layout for A. Is that correct? > "layout" is really misleading, sorry about that: it was meant to relate to restlet's representation (the way the resource is viewed by the client), not to the display within the client. All resources are represented as atom feeds: so the representation (which I wrongly called "layout") in restlet sense is this atom feed; then the client displays it as it wishes. So A does not know (and shouldn't IMHO) it can be dispayed with B or with B/C. If D is added later, and it is independent from A and it is only a client issue. > > > > An important point is that each resource includes links to all other > > resources it is logically linked to: the client has absolutly NO > > knowledge of the links between resources, it virtually navigates between > >them as needed. If A is linked to A and B, when the client accesses A it > > receives its representation, including a link to B and a link to C; > > Let say these resources are independent one of another (For instance if > A is a weather report, B a news feed, and C your profile). Who is responsible > for linking them together? Does A know it's linked to B and C, or are these > associations established at a higher level? > If resources are independent there're not linked together. The link must be meaningful in a business sense. There could definitly be a higher level resource that associates independent resources. For instance, let's say that your example relates to a personal mashup, something like google personal page or netvibes. Then you could consider that C contains links to B and A (the user chose B and A among a series of mashups, and its part of his profile), but A and B are not linked together (another user could use A without B). In that case C would stand for the higher level resource. > A's representation contains a link to B and C, which means the client has > to GET and C, and pass their representation to the template in order to > generate the page. So, do B and C's representations contain links to A? > The client indeed navigates through the resources and the links provided in their representation exactly like a human would navigate through web pages: it has no other knowledge than the links provided by resources (no resource can be accessed if it is not linked by a previously loaded resource). Then it is not mandatory to have symmetric links. Resources are really analoguous to web pages: many pages have links to Amazon, but Amazon does not have symmetric links to all of them. However until now symmetric links proved to be useful to navigate between resources of the application. > -vincent. > >
RE: Question to all about visual webapps and Restlet
Hi Vincent, > > You add a query parameter with an URI to return to after edition: > > > > /orange/editor?return=/main?orange=picture&apple=text > > But maybe the page you return to depends on the result of the > operation. It's not a decision the client can make. Ok, in this case your "/orange/editor" resource can issue a redirect to the target URI dynamically generated. > > The orange never includes the apples, only the main page > resource does > > include both of them. To make sure we are on the same page, > do you agree > > that the following URIs identify different resources? > > - "/main" > > - "/main?orange=picture" > > - "/main?orange=picture&apple=text" > > - "/main?orange=picture&apple=picture" > > Actually, I don't. To me they all identify the main page, in > different states. > Would not that be like saying: >/document/123;font=large >/document/123;font=small > > identify 2 resources? Exactly, each time you change the URI, even to simply add a query parameter, you create a different identifier. This new identifier correspond to a different target resource! Why would you diffentiate "/document/123;font=large" from "/document/123/large"? From the REST/HTTP point of view, two different URIs identify two different resources. Now, at the Restlet level, you can perfectly reuse the same Resource subclass for all similar target resources, but each instance of the class will be corresponding to a different target resource. Best regards, Jerome
Re: Question to all about visual webapps and Restlet
Jerome, > You add a query parameter with an URI to return to after edition: > > /orange/editor?return=/main?orange=picture&apple=text > But maybe the page you return to depends on the result of the operation. It's not a decision the client can make. > The orange never includes the apples, only the main page resource does > include both of them. To make sure we are on the same page, do you agree > that the following URIs identify different resources? > - "/main" > - "/main?orange=picture" > - "/main?orange=picture&apple=text" > - "/main?orange=picture&apple=picture" Actually, I don't. To me they all identify the main page, in different states. Would not that be like saying: /document/123;font=large /document/123;font=small identify 2 resources? -vincent.
RE: Question to all about visual webapps and Restlet
Hi Vincent, > > No it wouldn't make sense. You would instead directly > modify the Orange > > resource, either directly from the browser or via some > edition pages (to > > allow multi-page edition for example). > > But then how you return to the main page after you've > modified the orange? You add a query parameter with an URI to return to after edition: /orange/editor?return=/main?orange=picture&apple=text > Now we're saying that the orange needs not be aware > of the apple (the links are managed at a higher level > (the main page)); Yes, unless there was a natural link between oranges and apples, which is not the case here. > So what does the PUT operation return? A description of the orange? > It's not what we need. a > /main?orange=picture&apple=text uri? But how does the orange > know it has to include the apple? The orange never includes the apples, only the main page resource does include both of them. To make sure we are on the same page, do you agree that the following URIs identify different resources? - "/main" - "/main?orange=picture" - "/main?orange=picture&apple=text" - "/main?orange=picture&apple=picture" Best regards, Jerome
Re: Question to all about visual webapps and Restlet
Hi Matthieu, > Basically I've a rich client application (Flex) accessing Ah, but it's quite a different story, as the final (visual) representation is assembled on the client, not on the server. > I considered each resource as > being kind of a "virtual web page", with one URI and one (or several if > required) "layouts" (representations). The application accesses the required > resources, and assembles them for display. So if one page displays A and B, and another page displays A, B, and C, A knows it has two layouts (a/B and A/B/C). If you later add D to the page, you'll add a third layout for A. Is that correct? > > An important point is that each resource includes links to all other > resources it is logically linked to: the client has absolutly NO > knowledge of the links between resources, it virtually navigates between >them as needed. If A is linked to A and B, when the client accesses A it > receives its representation, including a link to B and a link to C; Let say these resources are independent one of another (For instance if A is a weather report, B a news feed, and C your profile). Who is responsible for linking them together? Does A know it's linked to B and C, or are these associations established at a higher level? A's representation contains a link to B and C, which means the client has to GET and C, and pass their representation to the template in order to generate the page. So, do B and C's representations contain links to A? -vincent.
Re: Question to all about visual webapps and Restlet
Hi Jerome, > Why not, the URI design is important too, I would probably do: > For the apple: /main?orange=picture&apple=text > For the orange: /main?orange=text&apple=picture > > > What if we want to modify the orange? Do we PUT the mainPage, > > passing it the Orange info? > > No it wouldn't make sense. You would instead directly modify the Orange > resource, either directly from the browser or via some edition pages (to > allow multi-page edition for example). But then how you return to the main page after you've modified the orange? Now we're saying that the orange needs not be aware of the apple (the links are managed at a higher level (the main page)); So what does the PUT operation return? A description of the orange? It's not what we need. a /main?orange=picture&apple=text uri? But how does the orange know it has to include the apple? -vincent.
Re: Question to all about visual webapps and Restlet
Jerome Louvel noelios.com> writes: > > > Vincent, > > > Sorry if I wasn't clear. Let me try again. > > > > You display 2 resources on one page: > > > > 1) your profile. By default, the Profile section display your > > name, but it include a More link that let's you display your > > name, your email, the number of posts you've made, etc. > > > > 2) the forum > > When you click on a forum thread, the Forum resource must pull the > > Profile resource out of the DB in order to redisplay the page. > > > > When you click on the More link (in the Profile section), the > > Profile resource must pull out the Forum info out of the DB to > > be able to retrieve the page. > > > > So, you're introducing a dependency between these two resources. > > > > If you later decide to display the weather report on that > > page, both the > > Profile and Forum resources will have to be made aware of the > > WeatherReport > > resource in order to display the page. And so on. > > > > If you say that the Profile and WeatherReport resources are > > part of the > > representation of the Forum resource, you must also admit that the > > Forum is part of the Profile's (or WeatherReport's) representation. > > > > I think this creates an unmanageable graph. > > I wouldn't say that a resource is part of a representation, rather that a > representation can be a composite representation, agregating several > representations into a larger one. > > In a typical object-oriented model, you will frequently have such > cross-references in your domain model, there is nothing wrong about that. What is wrong is to violate the abstraction layer your created with your OO model. A car has a rear mirror and four wheels (among other things), but the wheels do not need to reference the mirror. We started this discussion by saying that is a page displays resource A and resource B, resource B is part of the 'contextual information' of resource A, and -therefore- A should reference B in order to create a reference of itself. Now, the agreement seems to be that the resource is the page, and we might or might not model A and B as resources, depending on whether we need to access them individually. > Nothing forces your to model everything as resources, you could rely on a > set of EJB Entities or on POJOs persisted in db4o for examples. They would > handle this cross-references naturally. Even if you model everything as > resources, you can also model hyperlinks between all resources. Sorry, I > don't see what is unmanageable here... What is unmanageable is if you create cross-reference between all resources on a page. When you add the resource, you have to modifies the other ones so that they reference this one too. Of course, is we're modeling the page (the container) as a resource, the complexity no longer exists. -vincent. -vincent.
Re: Question to all about visual webapps and Restlet
Jeff Walter gmail.com> writes: > > Hey All,Little philosophical/architectural question here... Hello Interesting question; I'll try to provide a possible answer by sketching the way I build my application. Basically I've a rich client application (Flex) accessing (create, modify, view) various resources on the server. These resources are exactly all the "objects" that can be manipulated within the application. I considered each resource as being kind of a "virtual web page", with one URI and one (or several if required) "layouts" (representations). The application accesses the required resources, and assembles them for display. To be a little more specific, my resources' representation currently rely on atom (which is indeed a generic resource format, blogs being only a specific and restrained use; other formats may be used, rss, custom xml, etc): when the client GETs a resource, it receives an atom feed, and it applies to it a display template, corresponding to the way that resource's representation should be presented to the user in the current context of the application (eg the application is made of interacting zones, each one displaying a template populated by a resource's representation). An important point is that each resource includes links to all other resources it is logically linked to: the client has absolutly NO knowledge of the links between resources, it virtually navigates between them as needed. If A is linked to A and B, when the client accesses A it receives its representation, including a link to B and a link to C; then if the client wants to access B it uses that link (equivalent to a human "clicking" on a link). The navigation logic (links) is part of the resources (=controller), each resource is published to the application/browser using a representation format, the application/browser aggregates a meaningful and "pretty" display of several resources representation. Example: think of iTunes. Your songs and playlist are resources, as well as authors, music types, albums, etc, all linked together. iTMS online content is also a set of similar resources. All of them are represented in a XML format specific to Apple; iTunes is responsible for displaying several resources at the same time, allowing navigation between navigation, switching views, etc. I hope this makes sense. Regards
RE: Question to all about visual webapps and Restlet
Vincent, > So, say we have a page that displays a picture of an apple > and a picture > of an orange. > When we click on either picture, we want to replace it by the text > representation of the selected fruit (we we want to keep displaying > the picture of the other fruit). OK. In the REST/HTTP sense there is only one composite representation here (the page) and one resource (the composite resource represented by the page). But it is also interesting to try to decompose your composite resource/representation, especially if you can display your Orange and Apple resources separately. > We have 3 resources: MainPage, Apple, Orange. Apple and > Orange are what > you call 'low-level' resources'; the Mainpage resource is the highest > abstraction. More or less, it is really a design choice. If you let the user view an Apple resource independently, then is becomes higher-level too. Maybe you will want to have a view resource called ApplePage instead, to keep a strict separation between core reusable resources and view/page resources. > To display the main page you GET /mainPage > What are the apppe's and orange's URI's like? > > For the apple: /mainPage?orange=picture&apple=text > For the orange: /mainPage?orange=text&apple=picture > > Is that what you had in mind? Why not, the URI design is important too, I would probably do: For the apple: /main?orange=picture&apple=text For the orange: /main?orange=text&apple=picture > What if we want to modify the orange? Do we PUT the mainPage, > passing it the Orange info? No it wouldn't make sense. You would instead directly modify the Orange resource, either directly from the browser or via some edition pages (to allow multi-page edition for example). Best regards, Jerome
RE: Question to all about visual webapps and Restlet
Vincent, > Sorry if I wasn't clear. Let me try again. > > You display 2 resources on one page: > > 1) your profile. By default, the Profile section display your > name, but it include a More link that let's you display your > name, your email, the number of posts you've made, etc. > > 2) the forum > When you click on a forum thread, the Forum resource must pull the > Profile resource out of the DB in order to redisplay the page. > > When you click on the More link (in the Profile section), the > Profile resource must pull out the Forum info out of the DB to > be able to retrieve the page. > > So, you're introducing a dependency between these two resources. > > If you later decide to display the weather report on that > page, both the > Profile and Forum resources will have to be made aware of the > WeatherReport > resource in order to display the page. And so on. > > If you say that the Profile and WeatherReport resources are > part of the > representation of the Forum resource, you must also admit that the > Forum is part of the Profile's (or WeatherReport's) representation. > > I think this creates an unmanageable graph. I wouldn't say that a resource is part of a representation, rather that a representation can be a composite representation, agregating several representations into a larger one. In a typical object-oriented model, you will frequently have such cross-references in your domain model, there is nothing wrong about that. Nothing forces your to model everything as resources, you could rely on a set of EJB Entities or on POJOs persisted in db4o for examples. They would handle this cross-references naturally. Even if you model everything as resources, you can also model hyperlinks between all resources. Sorry, I don't see what is unmanageable here... Best regards, Jerome
Re: Question to all about visual webapps and Restlet
> I agree and would add that those lower-level resources (or core resources) > could be modelled and exposed as either: > - persistent POJOs (db4o, EJB3, etc.) > - RESTful resources (via a separate Restlet application for example) > > In the second case, you could even think about a two-layer approach, where > on Web Component would remotely access to an internal Core/Business > Component. This way, your Core Component could be shared between several > 'view' applications/components. So, say we have a page that displays a picture of an apple and a picture of an orange. When we click on either picture, we want to replace it by the text representation of the selected fruit (we we want to keep displaying the picture of the other fruit). We have 3 resources: MainPage, Apple, Orange. Apple and Orange are what you call 'low-level' resources'; the Mainpage resource is the highest abstraction. To display the main page you GET /mainPage What are the apppe's and orange's URI's like? For the apple: /mainPage?orange=picture&apple=text For the orange: /mainPage?orange=text&apple=picture Is that what you had in mind? What if we want to modify the orange? Do we PUT the mainPage, passing it the Orange info? -vincent.
Re: Question to all about visual webapps and Restlet
Hi Jerome, > > > So you're forcing one resource to be aware of other resources > > just because of > > the way your user interface in designed. If you switch to > > HTML frames, you no > > longer need these dependencies because each frame displays > > only one resource > > (the content frame, the profile frame, the navigation frame, etc.). > > Yes, in this case the resource is a "view resource". The addition of frames > wouldn't break the design, the Web representation would just remove the > contextual information (sidebar, etc.) and we would add new dedicated > resources for the other frames. > > > And what about cross references? If you click on a post in > > one of the thread, > > the 'post' resource must know about the 'profile' resource > > because it's > > part of its 'contextual information'. Now let's say you have > > a 'More' link in > > the profile section to display more of your profile info. In > > order to redisplay > > the page, the 'profile' resource will have to know about the > > 'post' resource > > too (because when you GET /profile/123;details, you need to > > include the > > current post). Imagine the graph (and the resulting > > maintenance nightmare) if > > you have 5 resources displayed on one page. > > I'm not sure to follow you precisely, but for sure a Web page is a > representation of a single target resource. It doesn't matter how many > sub-resources or domain objects were used to build this representation. > Sorry if I wasn't clear. Let me try again. You display 2 resources on one page: 1) your profile. By default, the Profile section display your name, but it include a More link that let's you display your name, your email, the number of posts you've made, etc. 2) the forum When you click on a forum thread, the Forum resource must pull the Profile resource out of the DB in order to redisplay the page. When you click on the More link (in the Profile section), the Profile resource must pull out the Forum info out of the DB to be able to retrieve the page. So, you're introducing a dependency between these two resources. If you later decide to display the weather report on that page, both the Profile and Forum resources will have to be made aware of the WeatherReport resource in order to display the page. And so on. If you say that the Profile and WeatherReport resources are part of the representation of the Forum resource, you must also admit that the Forum is part of the Profile's (or WeatherReport's) representation. I think this creates an unmanageable graph. -vincent.
RE: Question to all about visual webapps and Restlet
Hi Vincent, > So you're forcing one resource to be aware of other resources > just because of > the way your user interface in designed. If you switch to > HTML frames, you no > longer need these dependencies because each frame displays > only one resource > (the content frame, the profile frame, the navigation frame, etc.). Yes, in this case the resource is a "view resource". The addition of frames wouldn't break the design, the Web representation would just remove the contextual information (sidebar, etc.) and we would add new dedicated resources for the other frames. > And what about cross references? If you click on a post in > one of the thread, > the 'post' resource must know about the 'profile' resource > because it's > part of its 'contextual information'. Now let's say you have > a 'More' link in > the profile section to display more of your profile info. In > order to redisplay > the page, the 'profile' resource will have to know about the > 'post' resource > too (because when you GET /profile/123;details, you need to > include the > current post). Imagine the graph (and the resulting > maintenance nightmare) if > you have 5 resources displayed on one page. I'm not sure to follow you precisely, but for sure a Web page is a representation of a single target resource. It doesn't matter how many sub-resources or domain objects were used to build this representation. > And what if the same resource can be displayed in several > type of views? Take > this forum, for instance: > When you a click on a thread, the post is displayed in the > bottom part of the > screen. You can also click on the direct-link and have the > post displayed on a > new page (without the threads). gmane uses frames to achieve > this, but how would > you do it without frames? Include the view in the url? > > GET > http://article.gmane.org/gmane.comp.java.restlet/1871;view=threaded > GET http://article.gmane.org/gmane.comp.java.restlet/1871;view=single > > Or you could decide that what you're viewing is the form, and > the uri becomes: > GET http://article.gmane.org/gmane.comp.java.restlet?activeView=1871 > > The danger with this approach is that it forces you to think > in terms of pages > (the forum, the main page, etc.) instead of resources. Or > more exactly: > your pages become your resources. Exactly, and their is nothing fundamentaly wrong with this. What is important is that you don't create unnecessary "page" resources. As soon as you add a "?page=2" query parameter, you identify a resource that is separate from the one identified by "?page=3". There is nothing you can do against this. 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. > 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. Best regards, Jerome
RE: Question to all about visual webapps and Restlet
Hi John, [...] > I think it's helpful to think in terms of fundamental, "base" > resources and composite, "view" resources. An analogy is the > difference between "tables" and "views" in a relational database such > as Oracle. I agree, this is a useful analogy. > As you noted, in your example, it could be modelled where the same URL > is used but the two facets are distinguished by whether the caller > asks for the base (e.g., application/xml) or a human version (e.g., > xhtml). > > For other cases, I think it makes more sense to have the facets more > or less completely disjoint. The human useful, composite views may > make a lot more sense to the user if they have their own naming > hierarchy, etc. and just use the various, lower-level resources as > services, if you will, that are managed separately. I agree and would add that those lower-level resources (or core resources) could be modelled and exposed as either: - persistent POJOs (db4o, EJB3, etc.) - RESTful resources (via a separate Restlet application for example) In the second case, you could even think about a two-layer approach, where on Web Component would remotely access to an internal Core/Business Component. This way, your Core Component could be shared between several 'view' applications/components. Best regards, Jerome
Re: Question to all about visual webapps and Restlet
John, > I think it's helpful to think in terms of fundamental, "base" > resources and composite, "view" resources. > [...] > For other cases, I think it makes more sense to have the facets more > or less completely disjoint. The human useful, composite views may > make a lot more sense to the user if they have their own naming > hierarchy, etc. and just use the various, lower-level resources as > services, if you will, that are managed separately. Are you saying views should be first-class resources. and GET 'lower-level' resources to assemble the page? If yes, what's the need for the lower-level resources? The ForumView resource would just retrieve the object it needs from the DB (profile and post in Jeff's example), inject them in the template and return the template's result. -vincent.
Re: Question to all about visual webapps and Restlet
Jerome, > To me, it seems fine if the Web representation of the resource "thread > number 3 of the help forum" contains navigation data and other contextual > help. This is just how you "represent" your resource on a Web page. The same > resource could expose a more focus XML representation for programmatic > clients. > > Now, in term of coding, your ThreadResource class should have access to all > the domain objects (POJOs) required to return the Web representation: > Thread, User, Connections, etc. So you're forcing one resource to be aware of other resources just because of the way your user interface in designed. If you switch to HTML frames, you no longer need these dependencies because each frame displays only one resource (the content frame, the profile frame, the navigation frame, etc.). And what about cross references? If you click on a post in one of the thread, the 'post' resource must know about the 'profile' resource because it's part of its 'contextual information'. Now let's say you have a 'More' link in the profile section to display more of your profile info. In order to redisplay the page, the 'profile' resource will have to know about the 'post' resource too (because when you GET /profile/123;details, you need to include the current post). Imagine the graph (and the resulting maintenance nightmare) if you have 5 resources displayed on one page. And what if the same resource can be displayed in several type of views? Take this forum, for instance: When you a click on a thread, the post is displayed in the bottom part of the screen. You can also click on the direct-link and have the post displayed on a new page (without the threads). gmane uses frames to achieve this, but how would you do it without frames? Include the view in the url? GET http://article.gmane.org/gmane.comp.java.restlet/1871;view=threaded GET http://article.gmane.org/gmane.comp.java.restlet/1871;view=single Or you could decide that what you're viewing is the form, and the uri becomes: GET http://article.gmane.org/gmane.comp.java.restlet?activeView=1871 The danger with this approach is that it forces you to think in terms of pages (the forum, the main page, etc.) instead of resources. Or more exactly: your pages become your resources. 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. -vincent
Re: Question to all about visual webapps and Restlet
On 4/10/07, Jeff Walter <[EMAIL PROTECTED]> wrote: [...] I'd like to know how many other people are using Restlet to build visual web applications, and how they feel about aggregating resource data on their pages? What do you mean by "visual" web applications? I'm going to presume that you mean "for consumption by humans" as opposed to use as e.g. a programmatically accessible "API". Let's take a simple example: We have a Resource for a thread on a forum: http://somesite.org/forums/helpforum/threads/3 On this page, we display the thread Resource, but we also want to show in a sidebar, lets say other online users browsing the help forum, and the latest 3 posts to the help forum (the actual data is unimportant, but the fact that the data is not a part of the single thread Resource is). In Restlet, accessing this URL would load up a Thread Resource and pick its HTML representation (let's say using a Freemarker template). To display the extraneous data in the sidebar, the Thread resource is going to have to access other Resources information to then pass to the template. Additionally, if this forum requires that a user be logged-in to participate in discussions, the header on the page might contain a "logout" link if the user is logged in (or "login" link if they weren't already logged-in). Having "extraneous" information on a web page is pretty common requirement, but it seems to not "feel right" to me in terms of Resource implementation in Restlet. How do people feel about Resources loading the extra Resource data to feed to the templates? Is this just par for the course and necessary? Are there best practices people like to employ to accomplish this without feeling like you are defeating the nice separation of Resources the framework creates for you? I think it's helpful to think in terms of fundamental, "base" resources and composite, "view" resources. An analogy is the difference between "tables" and "views" in a relational database such as Oracle. As you noted, in your example, it could be modelled where the same URL is used but the two facets are distinguished by whether the caller asks for the base (e.g., application/xml) or a human version (e.g., xhtml). For other cases, I think it makes more sense to have the facets more or less completely disjoint. The human useful, composite views may make a lot more sense to the user if they have their own naming hierarchy, etc. and just use the various, lower-level resources as services, if you will, that are managed separately. Hope this helps, John
RE: Question to all about visual webapps and Restlet
Hi Jeff, This is an interesting question and I'm also curious to see how others handle this case. To me, it seems fine if the Web representation of the resource "thread number 3 of the help forum" contains navigation data and other contextual help. This is just how you "represent" your resource on a Web page. The same resource could expose a more focus XML representation for programmatic clients. Now, in term of coding, your ThreadResource class should have access to all the domain objects (POJOs) required to return the Web representation: Thread, User, Connections, etc. Best regards, Jerome > -Message d'origine- > De : Jeff Walter [mailto:[EMAIL PROTECTED] > Envoyé : mercredi 11 avril 2007 06:19 > À : discuss@restlet.tigris.org > Objet : Question to all about visual webapps and Restlet > > Hey All, > > Little philosophical/architectural question here... > > I'd like to know how many other people are using Restlet to > build visual web applications, and how they feel about > aggregating resource data on their pages? > > Let's take a simple example: > > We have a Resource for a thread on a forum: > http://somesite.org/forums/helpforum/threads/3 > > On this page, we display the thread Resource, but we also > want to show in a sidebar, lets say other online users > browsing the help forum, and the latest 3 posts to the help > forum (the actual data is unimportant, but the fact that the > data is not a part of the single thread Resource is). > > In Restlet, accessing this URL would load up a Thread > Resource and pick its HTML representation (let's say using a > Freemarker template). To display the extraneous data in the > sidebar, the Thread resource is going to have to access other > Resources information to then pass to the template. > Additionally, if this forum requires that a user be logged-in > to participate in discussions, the header on the page might > contain a "logout" link if the user is logged in (or "login" > link if they weren't already logged-in). > > Having "extraneous" information on a web page is pretty > common requirement, but it seems to not "feel right" to me in > terms of Resource implementation in Restlet. How do people > feel about Resources loading the extra Resource data to feed > to the templates? Is this just par for the course and > necessary? Are there best practices people like to employ to > accomplish this without feeling like you are defeating the > nice separation of Resources the framework creates for you? > > Any thoughts would be appreciated... just wanted to hear some > ideas/start a discussion. > > Thanks! > > Jeff > > > >
Question to all about visual webapps and Restlet
Hey All, Little philosophical/architectural question here... I'd like to know how many other people are using Restlet to build visual web applications, and how they feel about aggregating resource data on their pages? Let's take a simple example: We have a Resource for a thread on a forum: http://somesite.org/forums/helpforum/threads/3 On this page, we display the thread Resource, but we also want to show in a sidebar, lets say other online users browsing the help forum, and the latest 3 posts to the help forum (the actual data is unimportant, but the fact that the data is not a part of the single thread Resource is). In Restlet, accessing this URL would load up a Thread Resource and pick its HTML representation (let's say using a Freemarker template). To display the extraneous data in the sidebar, the Thread resource is going to have to access other Resources information to then pass to the template. Additionally, if this forum requires that a user be logged-in to participate in discussions, the header on the page might contain a "logout" link if the user is logged in (or "login" link if they weren't already logged-in). Having "extraneous" information on a web page is pretty common requirement, but it seems to not "feel right" to me in terms of Resource implementation in Restlet. How do people feel about Resources loading the extra Resource data to feed to the templates? Is this just par for the course and necessary? Are there best practices people like to employ to accomplish this without feeling like you are defeating the nice separation of Resources the framework creates for you? Any thoughts would be appreciated... just wanted to hear some ideas/start a discussion. Thanks! Jeff
