Open AndySky21 opened 9 years ago
mozumder
commented
9 years ago The HREF and MREF come from completely separate URLS, and the HREF resource retrieval should already be implemented server-side. The MREF is for JSON or XML API resources, and the HREF is for HTML.
BTW a proper implementation of this on the browser would have pushState for both HREF and MREF.
AndySky21
commented
9 years ago a proper implementation of this on the browser would have pushState for both HREF and MREF
As far as I understand, MREF is not meant to appear in the address bar, and therefore it doesn't constitute a history entry. If this hasn't been said, I would suggest it to be so. An api.mywebsite.com/article2 address would only refer to the data, and there's no way to discover the resource URI from that. Unless your project implies that authors include an interface property in loaded data, referring to the canonical URI for the full page. This would not only push the project quite far from its original scheme, but would also apperar quite impractical when data are to be used for different resouces.
HREF attributes are for resource location, and therefore they would benefit from native pushState method (remember that the purpose of pushState is just to create a history entry without affecting page load).
HREF resource retrieval should already be implemented server-side
You mean that it is autors' responsibility to do so.
If an URI is entered in the form of www.mywebsite.com/folder/article2.html, then the request will be interpreted by the server to browse the directory structure of the domain, look for the file called "article2.html" inside the directory called "folder", then send it to the client. If no "folder" directory or no "article" file inside it is found, then a 404 response code is sent.
In your context, image that the page has URI www.mywebsite.com/folder/article.html. No specific page files exist, as you can't ask authors to both write a dynamic page file for loading content and a specific page file for every single content. If you did so, autors would use <iframe>s and that'd be all.
So, no /folder/article2.html file exists. How can your markup language notify the server to send anything related to that URI? Simply it can't, unless you conceive a server-side markup processing. Now you have 2 possibilities:
/folder/article2.html
Then you need server-side silent redirect. This means putting a folder instruction as high as you can in the directory structure (ideally, inside the root). In LINUX servers, you can do it with an .htaccess file with the following syntax:
RewriteEngine On
RewriteBase /
RewriteRule ^folder/article(\d+)\.html$ /folder/article.ext?res=article\1
or (if you want to play really hard)
RewriteEngine On
RewriteBase /
RewriteRule ^folder/article(\d+)\.html$ /folder/article.ext/article\1
In these cases when a user requests the URI above, s/he will be silently redirected to
www.mywebsite.com/folder/article.ext?res=article2
or
www.mywebsite.com/folder/article.ext/article2
(this second case uses PATH_INFO. I'm not fully sure it can be accessed on Windows server, and it must be enabled on UNIX hosting through php.ini)
Notice that I wrote article.ext, not article.html or article.php. This brings us to:
Case 2: force authors to use, or translate users' request to, querystring/pathinfo URI
What happens now depends on what .ext is, which in turn depends on where querystring/pathinfo instruction is to be elaborated.api.mywebsite.com/article2 and finally pass data to view layer.$_GET array in PHP) and include different initial data (e.g. from a database with MYSQLI functions)Benefits and issues of different cases:
I know that this was really long, but I wanted to express my concerns about this aspect of the model, so that it can be elaborated properly. Bear in mind that one of the liabilities of old frameset model, in addition not to be declarative, was that it didn't keep track of navigation. Native MVC, or HMML, has to take care of this or it will be suitable only for browser games.
You should notify authors about a particular, though it is quite straightforward and everybody would notice it. In a mailing list message you also stated that this structure will implement a sort of native pushState so that URI in address bar is updated without loading a new Web page. This means that, by building pages this way, all the resource retrieval (the mechanism through which fetching a resource URI a client can request and receive the specified resource) is to be done server-side, either with
.htaccessfiles (or Windows server equivalent) or through server-side scripting. The latter would require a little knowledge of server-side scripting (PHP or Apache, depending on whether.htaccessis used or not), as well as different URI in the example. Instead of<a href="article.html">you should use<a href="?article">(it's a minor note, though).