|
|
| (One intermediate revision by the same user not shown) |
| Line 1: |
Line 1: |
| − | {{glossary}}A [[w:single-page application|single-page application]] ('''SPA'''), also known as '''single-page interface''' ('''SPI'''), is a web application that fits on a single web page. In an SPA, either all necessary code – HTML, JavaScript, and CSS – is retrieved with a single page load, or partial changes are performed loading new code on demand from web servers, usually driven by user actions.
| + | #redirect [[JavaScript#Single-page applications]] |
| − | | |
| − | The page does not automatically reload during user interaction with the application, nor does control transfer to another page. Necessary updates to the page display may or may not involve interaction with a server. The term single-page application was coined by [[w:Steve Yen|Steve Yen]] in 2005, though the concept was discussed at least as early as 2003.
| |
| − | | |
| − | == Hash fragments ==
| |
| − | A central concept making single-page applications possible is the idea of "hash fragments" which is the part of the URL appearing after the first hash character. Everything after the hash represents addressing within the document, whereas everything before the hash is outside the page and requires a server to fetch the document. This allows applications to have their current state fully reflected within the URL so it can be bookmarked - this is one of the foundation principles of the web, that any state the application is in, for example a report or query result, can be bookmarked or sent to others as a URL. So the Single Page Application model is the best of both worlds - it has the dynamic feel of a desktop application having instant responsiveness without page reloads, but also has the important URL reflection quality of the web.
| |
| − | | |
| − | The most natural way of mapping application interface elements to functionality in the system model is to make the URL portion after the hash continue on in the form of path elements separated by slashes - hence the name "hash fragments".
| |
| − | | |
| − | In the OrganicDesign [[software architecture]] we plan to make the entire path after the hash map directly to a path in the [[unified ontology]] so that the whole p2p network would be accessible via the following kind of URL format.
| |
| − | :http://localhost/#/path/into/unified/ontology/
| |
| − | This could also start with a normal domain name if the peer instance is running on a server connected to the web, in that case an optional exclamation mark could also be included which indicates that the paths should be crawlable by search engines, for example:
| |
| − | :http://foobar.com/#!/path/into/unified/ontology/
| |
| − | *[http://www.quirkey.com/blog/2011/02/10/ish/ Quirky.com on hash fragments]
| |
| − | *[http://code.google.com/web/ajaxcrawling/docs/getting-started.html Making AJAX Applications Crawlable]
| |
| − | | |
| − | == Frameworks ==
| |
| − | *[http://www.bennadel.com/projects/cormvc-jquery-framework.htm corMVC]
| |
| − | *[http://blog.stevensanderson.com/2012/08/01/rich-javascript-applications-the-seven-frameworks-throne-of-js-2012/ Rich JavaScript Applications – the Seven Frameworks]
| |
| − | | |
| − | == Existing SPAs ==
| |
| − | *[[TiddlyWiki5]]
| |
| − | *[http://www.bennadel.com/resources/projects/cormvc/demo/index.htm#/contacts corMVC Demo]
| |
| − | *[[w:TiddlyWiki|TiddlyWiki]]
| |
| − | *[http://www.thomasweibel.ch/sudoku/ Sudoku]
| |
| − | | |
| − | == See also ==
| |
| − | *[[Wikipedia:Single-page application]]
| |
| − | *[http://devedge-temp.mozilla.org/viewsource/2003/inner-browsing/index_en.html Inner-Browsing] ''- Extending Web Browsing the Navigation Paradigm''
| |
| − | *[[The Module pattern]]
| |
| − | *[[Namecoin SPA]]
| |
| − | [[Category:Software]][[Category:JavaScript]]
| |
