-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
General grammar and style fixes in the book #4679
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 3 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -126,7 +126,7 @@ is primarily an HTML file that uses a template-like PHP syntax: | |
</body> | ||
</html> | ||
|
||
By convention, the file that contains all of the application logic - ``index.php`` - | ||
By convention, the file that contains all the application logic - ``index.php`` - | ||
is known as a "controller". The term :term:`controller` is a word you'll hear | ||
a lot, regardless of the language or framework you use. It refers simply | ||
to the area of *your* code that processes user input and prepares the response. | ||
|
@@ -177,7 +177,7 @@ of the application are isolated in a new file called ``model.php``: | |
|
||
.. tip:: | ||
|
||
The filename ``model.php`` is used because the logic and data access of | ||
The file name ``model.php`` is used because the logic and data access of | ||
an application is traditionally known as the "model" layer. In a well-organized | ||
application, the majority of the code representing your "business logic" | ||
should live in the model (as opposed to living in a controller). And unlike | ||
|
@@ -244,7 +244,7 @@ the layout: | |
|
||
<?php include 'layout.php' ?> | ||
|
||
You've now introduced a methodology that allows for the reuse of the | ||
You've now introduced a methodology that allows reusing the | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the new one sounds a bit awkward, but this might be better than both:
The word methodology (I almost definitely wrote that) seems a bit unnecessarily "boring" and technical :). |
||
layout. Unfortunately, to accomplish this, you're forced to use a few ugly | ||
PHP functions (``ob_start()``, ``ob_get_clean()``) in the template. Symfony | ||
uses a Templating component that allows this to be accomplished cleanly | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -236,7 +236,7 @@ Here is a list of the main options: | |
(default: ``60``). This setting is overridden by the ``stale-if-error`` HTTP | ||
``Cache-Control`` extension (see RFC 5861). | ||
|
||
If ``debug`` is ``true``, Symfony automatically adds a ``X-Symfony-Cache`` | ||
If ``debug`` is ``true``, Symfony automatically adds an ``X-Symfony-Cache`` | ||
header to the response containing useful information about cache hits and | ||
misses. | ||
|
||
|
@@ -427,7 +427,7 @@ on a cache to store and return "fresh" responses. | |
model of the specification dominates your work. Unfortunately, the actual | ||
specification document - `RFC 2616`_ - can be difficult to read. | ||
|
||
There is an on-going effort (`HTTP Bis`_) to rewrite the RFC 2616. It does | ||
There is an ongoing effort (`HTTP Bis`_) to rewrite the RFC 2616. It does | ||
not describe a new version of HTTP, but mostly clarifies the original HTTP | ||
specification. The organization is also improved as the specification | ||
is split into seven parts; everything related to HTTP caching can be | ||
|
@@ -482,7 +482,7 @@ The resulting HTTP header will look like this: | |
timezone as required by the specification. | ||
|
||
Note that in HTTP versions before 1.1 the origin server wasn't required to | ||
send the ``Date`` header. Consequently the cache (e.g. the browser) might | ||
send the ``Date`` header. Consequently, the cache (e.g. the browser) might | ||
need to rely on the local clock to evaluate the ``Expires`` header making | ||
the lifetime calculation vulnerable to clock skew. Another limitation | ||
of the ``Expires`` header is that the specification states that "HTTP/1.1 | ||
|
@@ -529,7 +529,7 @@ stale. | |
|
||
The validation model addresses this issue. Under this model, the cache continues | ||
to store responses. The difference is that, for each request, the cache asks | ||
the application whether or not the cached response is still valid. If the | ||
the application whether the cached response is still valid. If the | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Some of the "or not"'s removed in this PR make sense, because they don't really add anything. But I think this one does - it highlights that we're looking for an positive or negative message distinctly. We could alternatively use something like this (though I don't have a problem with the "or not" - but if you know that this is not easily understandable by non-native speakers or perhaps just wrong grammatically, let me know):
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. From a linguistic point of view, the addition of the "or not" is neither logically nor grammatically required. I think it's often used conversationally for emphasis. But I would totally go with your alternative ;) |
||
cache *is* still valid, your application should return a 304 status code | ||
and no content. This tells the cache that it's ok to return the cached response. | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think
filename
is actually better - both are apparently valid, but one word yields many more Google results.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO, the difference here lays on the logical subject:
But to make it short, the term "filename" is - as you wrote - more common, and nobody cares about this tiny difference, so I'll change it back.