URI design question
Not really a Dancer-question per se, but you all are really, really smart, hence... So, I've taken this whole REST thing to heart. My approach is that the web application itself is a client now, just like a command-line program might be a client, to the data store. So, when the web page loads, even the very first time, it is like an empty form. On load, an ajax query is fired to GET the records that are then filled in. Consider a simple books catalog (make believe app). 1. User goes to [http://myapp.com] 2. A web page loads. It has all the "chrome" (the logos, buttons, etc.), but no books. On load, a call is made to [http://myapp.com/books] which sends back a JSON object with all the books, and the web page comes alive. Except, the address bar in the browser still says [http://myapp.com]. Ok. no matter. 3. The books are tagged. So, the user clicks on one of the tags, say "Thrillers," and an ajax query is fired to [http://myapp.com/books/tag/thrillers]. Once again, the correct data are received and the web page is filled in with the results. Except, the address bar in the browser still says [http://myapp.com]. You get the idea. Since all interaction is via ajax, the browser never refreshes completely. So, the user has no visual indication as to where (s)he is on the web site. Which also leads to a problem -- there is no way to send a link to anyone. In other words, is it possible to change the address in the browser without refreshing the browser? Any other thoughts on such an application design? Puneet.
Yes, you use fragments on the end of the url, like: http://myapp.com/#books You can change it all you want and it doesn't do a reload of the page. Check sites like digg.com, click their "next page" button and you will see it in action. On Tue, May 24, 2011 at 7:50 PM, Mr. Puneet Kishor <punk.kish@gmail.com> wrote:
Not really a Dancer-question per se, but you all are really, really smart, hence...
So, I've taken this whole REST thing to heart. My approach is that the web application itself is a client now, just like a command-line program might be a client, to the data store. So, when the web page loads, even the very first time, it is like an empty form. On load, an ajax query is fired to GET the records that are then filled in. Consider a simple books catalog (make believe app).
1. User goes to [http://myapp.com]
2. A web page loads. It has all the "chrome" (the logos, buttons, etc.), but no books. On load, a call is made to [http://myapp.com/books] which sends back a JSON object with all the books, and the web page comes alive. Except, the address bar in the browser still says [http://myapp.com]. Ok. no matter.
3. The books are tagged. So, the user clicks on one of the tags, say "Thrillers," and an ajax query is fired to [http://myapp.com/books/tag/thrillers]. Once again, the correct data are received and the web page is filled in with the results. Except, the address bar in the browser still says [http://myapp.com].
You get the idea. Since all interaction is via ajax, the browser never refreshes completely. So, the user has no visual indication as to where (s)he is on the web site. Which also leads to a problem -- there is no way to send a link to anyone.
In other words, is it possible to change the address in the browser without refreshing the browser? Any other thoughts on such an application design?
Puneet.
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Wednesday 25 May 2011 04:24:11 Brian E. Lozier wrote:
Yes, you use fragments on the end of the url, like:
You can change it all you want and it doesn't do a reload of the page. Check sites like digg.com, click their "next page" button and you will see it in action.
IMO, that's a bit of a hack, abusing named anchors which are supposed to simply target a specific area of a given page, not cause different content to be loaded. e.g. http://myapp.com/#foo and http://myapp.com/#bar should serve up the same content, but the browser should scroll to the appropriate anchor. Maybe I'm just being old-school (damn kids, get off my lawn) -- David Precious ("bigpresh") http://www.preshweb.co.uk/ "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)
On Wed, May 25, 2011 at 3:51 AM, David Precious <davidp@preshweb.co.uk> wrote:
On Wednesday 25 May 2011 04:24:11 Brian E. Lozier wrote:
Yes, you use fragments on the end of the url, like:
You can change it all you want and it doesn't do a reload of the page. Check sites like digg.com, click their "next page" button and you will see it in action.
IMO, that's a bit of a hack, abusing named anchors which are supposed to simply target a specific area of a given page, not cause different content to be loaded.
e.g. http://myapp.com/#foo and http://myapp.com/#bar should serve up the same content, but the browser should scroll to the appropriate anchor.
Well the OP didn't ask my opinion on whether it was a good idea. I dislike pages that load the shell then use a bunch of ajax calls to load all the different content areas. It results in many more http requests (which have significant overhead) and abusing anchors isn't my favorite either. The argument the other way is that the initial page loads more slowly but as you stay on it and click around the internal parts load faster. I don't know of another way to change the URL bar but not load the full page again.
Maybe I'm just being old-school (damn kids, get off my lawn)
-- David Precious ("bigpresh") http://www.preshweb.co.uk/
"Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz) _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Tue, May 24, 2011 at 10:50 PM, Mr. Puneet Kishor <punk.kish@gmail.com> wrote:
Not really a Dancer-question per se, but you all are really, really smart, hence...
So, I've taken this whole REST thing to heart. My approach is that the web application itself is a client now, just like a command-line program might be a client, to the data store. So, when the web page loads, even the very first time, it is like an empty form. On load, an ajax query is fired to GET the records that are then filled in. Consider a simple books catalog (make believe app).
1. User goes to [http://myapp.com]
2. A web page loads. It has all the "chrome" (the logos, buttons, etc.), but no books. On load, a call is made to [http://myapp.com/books] which sends back a JSON object with all the books, and the web page comes alive. Except, the address bar in the browser still says [http://myapp.com]. Ok. no matter.
3. The books are tagged. So, the user clicks on one of the tags, say "Thrillers," and an ajax query is fired to [http://myapp.com/books/tag/thrillers]. Once again, the correct data are received and the web page is filled in with the results. Except, the address bar in the browser still says [http://myapp.com].
You get the idea. Since all interaction is via ajax, the browser never refreshes completely. So, the user has no visual indication as to where (s)he is on the web site. Which also leads to a problem -- there is no way to send a link to anyone.
In other words, is it possible to change the address in the browser without refreshing the browser? Any other thoughts on such an application design?
If you want to be really cool, you can implement the neat effect that for example github uses to traverse the source code hierarchy. When you click on a folder, the source code listing is updated, the url is updated, but there is no page reload happening. You can see a demo here: https://github.com/blog/760-the-tree-slider And here is some more info: http://diveintohtml5.org/history.html https://github.com/defunkt/jquery-pjax/ -Naveed
Puneet.
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
REST The rest of the message doesn't read like that. I'll pretend you wrote "HTTP API" instead.
Any other thoughts on such an application design? In addition to what Brian said, Google built a convention around hash fragments to make AJAXy resources crawlable. It's a hack to accomodate people who didn't know better about the drawbacks and are now stuck with their horrible design. I call it a hack because AJAX by itself, unlike other Web tech we have seen so far, does not degrade gracefully; see and puke for yourself: <http://code.google.com/web/ajaxcrawling/>
Since you are still in the design phase, design your interaction properly with *progressive enhancement*. Write semantic markup and forms that work in a text browser. Then apply styles. Then apply JS that modifies the behaviour of an existing document to load partial content with AJAX. Employ pushState so that the URL changes the same way like it would for a user agent without JS. I can recommend jQuery BBQ to handle these bits.
On May 25, 2011, at 2:47 AM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote:
REST The rest of the message doesn't read like that. I'll pretend you wrote "HTTP API" instead.
Care to explain? Most likely you are correct, but I would like to understand why I wrote REST and thought I was talking REST but actually ended up talking HTTP API? From what I understand about REST -- every "item" that is to be retrieved via a URI is a resource (the R in REST). Every URI results in a unique resource, and every resource has one and only one URI. Hence, the URI can be thought of as a name of the resource, the really, truly unique resource identifier. The only interface to the world is the URI (the "name" of the resource), and a handful of verbs, namely GET, PUT, POST and DELETE, in the world of HTTP. Am I talking nonsense above? And, is there a disconnect between what I am thinking I am doing and what I am actually doing?
Any other thoughts on such an application design? In addition to what Brian said, Google built a convention around hash fragments to make AJAXy resources crawlable. It's a hack to accomodate people who didn't know better about the drawbacks and are now stuck with their horrible design. I call it a hack because AJAX by itself, unlike other Web tech we have seen so far, does not degrade gracefully; see and puke for yourself: <http://code.google.com/web/ajaxcrawling/>
I like this bit <a href="ajax.htm?foo=32" onClick="navigate('ajax.html#foo=32'); return false">foo 32</a> I didn't know I could do the above, and that seems like a good design feature. That said, I have the following clients -- (1) the web users whose only interface to my data and application is the web interface; (2) a program, such as a scientific application, that wants access to my data via a command line, so it can do it own work, say, modeling. Or, even a user who just wants to download the data for further use elsewhere; and now (something I really hand't thought of until your email) (3) the darned web crawler. Actually, I had sort-of thought of the web-crawler because I asked about permalinks. Of course, there is the question -- do/should my data be exposed to the web crawler? It may make sense for certain kinds of data, but what about highly discrete, small data? Say, weather readings -- I have a historical climate dataset for the US that, if I were to count each reading separately (in other words, each bit of data that would be retrieval via a unique name, or a URI), it would be upward of 120 billion (yes, no typos there... 120 Billion). Is there any point in pretending it is all a static web, and letting Google have at it?
Since you are still in the design phase, design your interaction properly with *progressive enhancement*. Write semantic markup and forms that work in a text browser. Then apply styles. Then apply JS that modifies the behaviour of an existing document to load partial content with AJAX. Employ pushState so that the URL changes the same way like it would for a user agent without JS. I can recommend jQuery BBQ to handle these bits.
I am gonna learn about pushState today, and jquery-pjax. What is jQuery BBQ?
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
participants (5)
-
Brian E. Lozier -
David Precious -
Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 -
Mr. Puneet Kishor -
Naveed Massjouni