mirror of
https://github.com/bigskysoftware/hypermedia-systems.git
synced 2025-12-07 00:03:06 -05:00
edits, e.g., consistency
This commit is contained in:
parent
d6e46d122b
commit
5d78cd5147
@ -43,7 +43,7 @@ system of the web.
|
|||||||
To explain what a hypermedia-driven application looks like, and to contrast it with the popular SPA approach of today,
|
To explain what a hypermedia-driven application looks like, and to contrast it with the popular SPA approach of today,
|
||||||
we need to first explore the entire _hypermedia system_ of the web, beyond just discussing HTML. We need to look at the
|
we need to first explore the entire _hypermedia system_ of the web, beyond just discussing HTML. We need to look at the
|
||||||
_network architecture_ of the original web, including how a web server delivers a hypermedia API, and how to effectively
|
_network architecture_ of the original web, including how a web server delivers a hypermedia API, and how to effectively
|
||||||
use the hypermedia features available in the hypermedia _client_ (e.g. the browser).
|
use the hypermedia features available in the hypermedia _client_ (e.g., the browser).
|
||||||
|
|
||||||
Each of these are important aspects of building an effective hypermedia-driven application, and it is the entire
|
Each of these are important aspects of building an effective hypermedia-driven application, and it is the entire
|
||||||
_hypermedia system_ that comes together to make hypermedia such a powerful architecture.
|
_hypermedia system_ that comes together to make hypermedia such a powerful architecture.
|
||||||
|
|||||||
@ -65,8 +65,8 @@ hypertexts such as HTML, the Hypertext Markup Language, or HXML, a hypertext us
|
|||||||
system.
|
system.
|
||||||
|
|
||||||
Hypertexts like HTML function alongside other technologies crucial for making an entire hypermedia system work: network
|
Hypertexts like HTML function alongside other technologies crucial for making an entire hypermedia system work: network
|
||||||
protocols like HTTP, other media types such as images, videos, hypermedia servers (i.e. servers providing hypermedia APIs),
|
protocols like HTTP, other media types such as images, videos, hypermedia servers (i.e., servers providing hypermedia APIs),
|
||||||
sophisticated hypermedia clients (e.g. web browsers), and so on.
|
sophisticated hypermedia clients (e.g., web browsers), and so on.
|
||||||
|
|
||||||
Because of this, we prefer the broader term _hypermedia systems_ when describing the underlying architecture of
|
Because of this, we prefer the broader term _hypermedia systems_ when describing the underlying architecture of
|
||||||
applications built using hypertext, to emphasize the system architecture over the particular hypermedia being used.
|
applications built using hypertext, to emphasize the system architecture over the particular hypermedia being used.
|
||||||
@ -144,7 +144,7 @@ The system that Berners-Lee, Fielding and many others had created revolved aroun
|
|||||||
hypermedia, used to publish (at first) academic documents. These documents were linked together via anchor tags which
|
hypermedia, used to publish (at first) academic documents. These documents were linked together via anchor tags which
|
||||||
created _hyperlinks_ between them, allowing users to quickly navigate between documents.
|
created _hyperlinks_ between them, allowing users to quickly navigate between documents.
|
||||||
|
|
||||||
When HTML 2.0 was released, it introduced the notion of the `form` tag, joining the anchor tag (i.e. hyperlink) as a
|
When HTML 2.0 was released, it introduced the notion of the `form` tag, joining the anchor tag (i.e., hyperlink) as a
|
||||||
second hypermedia control. The introduction of the form tag made building _applications_ on the web viable by providing
|
second hypermedia control. The introduction of the form tag made building _applications_ on the web viable by providing
|
||||||
a mechanism for _updating_ resources, rather than just reading them.
|
a mechanism for _updating_ resources, rather than just reading them.
|
||||||
|
|
||||||
|
|||||||
@ -228,7 +228,7 @@ HTTP breaks response codes up into various categories:
|
|||||||
Redirection responses indicating that the request should be sent to some other URL.
|
Redirection responses indicating that the request should be sent to some other URL.
|
||||||
|
|
||||||
`400`-`499`::
|
`400`-`499`::
|
||||||
Client error responses indicating that the client made some sort of bad request (e.g. asking for something that didn't
|
Client error responses indicating that the client made some sort of bad request (e.g., asking for something that didn't
|
||||||
exist in the case of `404` errors).
|
exist in the case of `404` errors).
|
||||||
|
|
||||||
`500`-`599`::
|
`500`-`599`::
|
||||||
|
|||||||
@ -89,7 +89,7 @@ with a route.
|
|||||||
Let's create our first route definition, a simple "`Hello Flask`" route. In the following python code you will see the
|
Let's create our first route definition, a simple "`Hello Flask`" route. In the following python code you will see the
|
||||||
`@app` symbol. This is the flask decorator that allows us to set up our routes. Don't worry too much about
|
`@app` symbol. This is the flask decorator that allows us to set up our routes. Don't worry too much about
|
||||||
how decorators work in Python, just know that this feature allows us to map a given _path_ to a particular function
|
how decorators work in Python, just know that this feature allows us to map a given _path_ to a particular function
|
||||||
(i.e. handler). The Flask application, when started, will take HTTP requests and look up the matching handler and
|
(i.e., handler). The Flask application, when started, will take HTTP requests and look up the matching handler and
|
||||||
invoke it.
|
invoke it.
|
||||||
|
|
||||||
.A simple "`Hello World`" route
|
.A simple "`Hello World`" route
|
||||||
@ -561,7 +561,7 @@ our handler logic will get, even when we look at adding more sophisticated htmx-
|
|||||||
|
|
||||||
The next piece of functionality we will implement is the detail page for a Contact. The user will navigate to this
|
The next piece of functionality we will implement is the detail page for a Contact. The user will navigate to this
|
||||||
page by clicking the "`View`" link in one of the rows in the list of contacts. This will take them to the path
|
page by clicking the "`View`" link in one of the rows in the list of contacts. This will take them to the path
|
||||||
`/contact/<contact id>` (e.g. `/contacts/42`).
|
`/contact/<contact id>` (e.g., `/contacts/42`).
|
||||||
|
|
||||||
This is a common pattern in web development: contacts are treated as resources and the URLs around these
|
This is a common pattern in web development: contacts are treated as resources and the URLs around these
|
||||||
resources are organized in a coherent manner.
|
resources are organized in a coherent manner.
|
||||||
|
|||||||
@ -738,16 +738,16 @@ The `hx-include` attribute and, in fact, most attributes that take a CSS selecto
|
|||||||
These allow you to specify a CSS selector _relative_ to the element it is declared on. Here are some examples:
|
These allow you to specify a CSS selector _relative_ to the element it is declared on. Here are some examples:
|
||||||
|
|
||||||
`closest`::
|
`closest`::
|
||||||
Find the closest parent element matching the given selector, e.g. `closest form`.
|
Find the closest parent element matching the given selector, e.g., `closest form`.
|
||||||
|
|
||||||
`next`::
|
`next`::
|
||||||
Find the next element (scanning forward) matching the given selector, e.g. `next input`.
|
Find the next element (scanning forward) matching the given selector, e.g., `next input`.
|
||||||
|
|
||||||
`previous`::
|
`previous`::
|
||||||
Find the previous element (scanning backwards) matching the given selector, e.g. `previous input`.
|
Find the previous element (scanning backwards) matching the given selector, e.g., `previous input`.
|
||||||
|
|
||||||
`find`::
|
`find`::
|
||||||
Find the next element within this element matching the given selector, e.g. `find input`.
|
Find the next element within this element matching the given selector, e.g., `find input`.
|
||||||
|
|
||||||
`this`::
|
`this`::
|
||||||
The current element.
|
The current element.
|
||||||
|
|||||||
@ -663,16 +663,16 @@ an extension to normal CSS. Htmx supports prefixes that will find targets _rela
|
|||||||
.Relative Positional Expressions in Htmx
|
.Relative Positional Expressions in Htmx
|
||||||
****
|
****
|
||||||
`next`::
|
`next`::
|
||||||
Scan forward in the DOM for the next matching element, e.g. `next .error`
|
Scan forward in the DOM for the next matching element, e.g., `next .error`
|
||||||
|
|
||||||
`previous`::
|
`previous`::
|
||||||
Scan backwards in the DOM for the closest previous matching element, e.g. `previous .alert`
|
Scan backwards in the DOM for the closest previous matching element, e.g., `previous .alert`
|
||||||
|
|
||||||
`closest`::
|
`closest`::
|
||||||
Scan the parents of this element for matching element, e.g. `closest table`
|
Scan the parents of this element for matching element, e.g., `closest table`
|
||||||
|
|
||||||
`find`::
|
`find`::
|
||||||
Scan the children of this element for matching element, e.g. `find span`
|
Scan the children of this element for matching element, e.g., `find span`
|
||||||
|
|
||||||
`this`::
|
`this`::
|
||||||
the current element is the target (default)
|
the current element is the target (default)
|
||||||
|
|||||||
@ -201,7 +201,7 @@ So we need some way to determine exactly which of these two different types of r
|
|||||||
made, in order to know exactly which content we want to render.
|
made, in order to know exactly which content we want to render.
|
||||||
|
|
||||||
It turns out that htmx helps us distinguish between these two cases by including a number of HTTP _Request Headers_ when
|
It turns out that htmx helps us distinguish between these two cases by including a number of HTTP _Request Headers_ when
|
||||||
it makes requests. Request Headers are a feature of HTTP, allowing clients (e.g. web browsers) to include name/value pairs
|
it makes requests. Request Headers are a feature of HTTP, allowing clients (e.g., web browsers) to include name/value pairs
|
||||||
of metadata associated with requests to help the server understand what the client is requesting.
|
of metadata associated with requests to help the server understand what the client is requesting.
|
||||||
|
|
||||||
Here is an example of (some of) the headers the FireFox browser issues when requesting `https://manning.com`:
|
Here is an example of (some of) the headers the FireFox browser issues when requesting `https://manning.com`:
|
||||||
@ -406,7 +406,7 @@ application.
|
|||||||
One subtle aspect of the approach we are taking here, using headers to determine the content of what we return, is
|
One subtle aspect of the approach we are taking here, using headers to determine the content of what we return, is
|
||||||
a feature baked into HTTP: caching. In our request handler, we are now returning different content depending on the
|
a feature baked into HTTP: caching. In our request handler, we are now returning different content depending on the
|
||||||
value of the `HX-Trigger` header. If we were to use HTTP Caching, we might get into a situation where someone makes
|
value of the `HX-Trigger` header. If we were to use HTTP Caching, we might get into a situation where someone makes
|
||||||
a _non-htmx_ request (e.g. refreshing a page) and yet the _htmx_ content is returned from the HTTP cache, resulting
|
a _non-htmx_ request (e.g., refreshing a page) and yet the _htmx_ content is returned from the HTTP cache, resulting
|
||||||
in a partial page of content for the user.
|
in a partial page of content for the user.
|
||||||
|
|
||||||
The solution to this problem is to use the HTTP Response `Vary` header and call out the htmx headers that you are using
|
The solution to this problem is to use the HTTP Response `Vary` header and call out the htmx headers that you are using
|
||||||
@ -500,7 +500,7 @@ the element from view, while at the same time not disrupting the layout of the p
|
|||||||
|
|
||||||
When an htmx request is triggered that points to this indicator, another class, `htmx-request` is added to the indicator
|
When an htmx request is triggered that points to this indicator, another class, `htmx-request` is added to the indicator
|
||||||
which transitions its opacity to 1. So you can use just about anything as an indicator, and it will be hidden by default. Then, when a request is in flight, it will be shown. This is all done via standard CSS classes, allowing you to control
|
which transitions its opacity to 1. So you can use just about anything as an indicator, and it will be hidden by default. Then, when a request is in flight, it will be shown. This is all done via standard CSS classes, allowing you to control
|
||||||
the transitions and even the mechanism by which the indicator is shown (e.g. you might use `display` rather than
|
the transitions and even the mechanism by which the indicator is shown (e.g., you might use `display` rather than
|
||||||
`opacity`).
|
`opacity`).
|
||||||
|
|
||||||
.Use Request Indicators!
|
.Use Request Indicators!
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user