@@ -273,21 +273,21 @@ The parameters to any of the above macros have consistent meanings:
273
273
field. The keys to the map represent the values that will be POSTed back from the form
274
274
and bound to the command object. Map objects stored against the keys are the labels
275
275
displayed on the form to the user and may be different from the corresponding values
276
- posted back by the form. Usually such a map is supplied as reference data by the
277
- controller. Any Map implementation can be used depending on required behavior. For
278
- strictly sorted maps, a `SortedMap` such as a `TreeMap` with a suitable Comparator may
279
- be used and for arbitrary Maps that should return values in insertion order, use a
280
- `LinkedHashMap` or a `LinkedMap` from commons-collections.
281
- * separator: where multiple options are available as discreet elements (radio buttons or
282
- checkboxes), the sequence of characters used to separate each one in the list (ie
283
- " <br>" ).
284
- * attributes: an additional string of arbitrary tags or text to be included within the
285
- HTML tag itself. This string is echoed literally by the macro. For example, in a
286
- textarea field you may supply attributes as 'rows="5" cols="60"' or you could pass
287
- style information such as 'style="border:1px solid silver"'.
288
- * classOrStyle: for the showErrors macro, the name of the CSS class that the span tag
289
- wrapping each error will use . If no information is supplied (or the value is empty)
290
- then the errors will be wrapped in <b></b> tags.
276
+ posted back by the form. Usually, such a map is supplied as reference data by the
277
+ controller. You can use any `Map` implementation, depending on required behavior.
278
+ For strictly sorted maps, you can use a `SortedMap` ( such as a `TreeMap`) with a
279
+ suitable `Comparator` and, for arbitrary Maps that should return values in insertion
280
+ order, use a `LinkedHashMap` or a `LinkedMap` from ` commons-collections` .
281
+ * ` separator`: Where multiple options are available as discreet elements (radio buttons
282
+ or checkboxes), the sequence of characters used to separate each one in the list
283
+ (such as ` <br>` ).
284
+ * ` attributes`: An additional string of arbitrary tags or text to be included within
285
+ the HTML tag itself. This string is echoed literally by the macro. For example, in a
286
+ ` textarea` field, you may supply attributes (such as 'rows="5" cols="60"'), or you
287
+ could pass style information such as 'style="border:1px solid silver"'.
288
+ * ` classOrStyle`: For the ` showErrors` macro, the name of the CSS class that the ` span`
289
+ element that wraps each error uses . If no information is supplied (or the value is
290
+ empty), the errors are wrapped in ` <b></b>` tags.
291
291
292
292
Examples of the macros are outlined below some in FTL and some in VTL. Where usage
293
293
differences exist between the two languages, they are explained in the notes.
@@ -750,12 +750,12 @@ The Spring Framework has a built-in integration for using Spring MVC with JSP an
750
750
[[mvc-view-jsp-resolver]]
751
751
=== View resolvers
752
752
753
- When developing with JSPs you can declare a `InternalResourceViewResolver` or a
753
+ When developing with JSPs, you can declare a `InternalResourceViewResolver` or a
754
754
`ResourceBundleViewResolver` bean.
755
755
756
756
`ResourceBundleViewResolver` relies on a properties file to define the view names
757
- mapped to a class and a URL. With a `ResourceBundleViewResolver` you
758
- can mix different types of views using only one resolver. Here is an example:
757
+ mapped to a class and a URL. With a `ResourceBundleViewResolver`, you can mix
758
+ different types of views by using only one resolver, as the following example shows :
759
759
760
760
[source,xml,indent=0]
761
761
[subs="verbatim,quotes"]
@@ -765,17 +765,17 @@ can mix different types of views using only one resolver. Here is an example:
765
765
<property name="basename" value="views"/>
766
766
</bean>
767
767
768
- # And a sample properties file is uses (views.properties in WEB-INF/classes):
768
+ # And a sample properties file is used (views.properties in WEB-INF/classes):
769
769
welcome.(class)=org.springframework.web.servlet.view.JstlView
770
770
welcome.url=/WEB-INF/jsp/welcome.jsp
771
771
772
772
productList.(class)=org.springframework.web.servlet.view.JstlView
773
773
productList.url=/WEB-INF/jsp/productlist.jsp
774
774
----
775
775
776
- `InternalResourceBundleViewResolver ` can also be used for JSPs. As a best practice, we
777
- strongly encourage placing your JSP files in a directory under the `'WEB-INF'`
778
- directory so there can be no direct access by clients.
776
+ `InternalResourceViewResolver ` can also be used for JSPs. As a best practice, we strongly
777
+ encourage placing your JSP files in a directory under the `'WEB-INF'` directory so there
778
+ can be no direct access by clients.
779
779
780
780
[source,xml,indent=0]
781
781
[subs="verbatim,quotes"]
@@ -792,8 +792,8 @@ directory so there can be no direct access by clients.
792
792
[[mvc-view-jsp-jstl]]
793
793
=== JSPs versus JSTL
794
794
795
- When using the Java Standard Tag Library you must use a special view class, the
796
- `JstlView`, as JSTL needs some preparation before things such as the I18N features will
795
+ When using the JSP Standard Tag Library (JSTL) you must use a special view class, the
796
+ `JstlView`, as JSTL needs some preparation before things such as the I18N features can
797
797
work.
798
798
799
799
@@ -1504,7 +1504,7 @@ or see the tag library description.
1504
1504
A key principle of REST is the use of the Uniform Interface. This means that all
1505
1505
resources (URLs) can be manipulated using the same four HTTP methods: GET, PUT, POST,
1506
1506
and DELETE. For each method, the HTTP specification defines the exact semantics. For
1507
- instance, a GET should always be a safe operation, meaning that is has no side effects,
1507
+ instance, a GET should always be a safe operation, meaning that it has no side effects,
1508
1508
and a PUT or DELETE should be idempotent, meaning that you can repeat these operations
1509
1509
over and over again, but the end result should be the same. While HTTP defines these
1510
1510
four methods, HTML only supports two: GET and POST. Fortunately, there are two possible
@@ -1516,9 +1516,8 @@ web framework (not just Spring MVC). Simply add this filter to your web.xml, and
1516
1516
with a hidden _method parameter will be converted into the corresponding HTTP method
1517
1517
request.
1518
1518
1519
- To support HTTP method conversion the Spring MVC form tag was updated to support setting
1520
- the HTTP method. For example, the following snippet taken from the updated Petclinic
1521
- sample
1519
+ To support HTTP method conversion, the Spring MVC form tag was updated to support setting
1520
+ the HTTP method. For example, the following snippet comes from the Pet Clinic sample:
1522
1521
1523
1522
[source,xml,indent=0]
1524
1523
[subs="verbatim,quotes"]
@@ -1528,9 +1527,9 @@ sample
1528
1527
</form:form>
1529
1528
----
1530
1529
1531
- This will actually perform an HTTP POST, with the 'real' DELETE method hidden behind a
1532
- request parameter, to be picked up by the `HiddenHttpMethodFilter`, as defined in
1533
- web.xml:
1530
+ The preceding example performs an HTTP POST, with the 'real' DELETE method hidden behind
1531
+ a request parameter. It is picked up by the `HiddenHttpMethodFilter`, which is defined in
1532
+ web.xml, as the following example shows :
1534
1533
1535
1534
[source,java,indent=0]
1536
1535
[subs="verbatim,quotes"]
@@ -1714,17 +1713,18 @@ implementations. Check out the Tiles documentation for details on how to use
1714
1713
1715
1714
Specify `SimpleSpringPreparerFactory` to autowire ViewPreparer instances based on
1716
1715
specified preparer classes, applying Spring's container callbacks as well as applying
1717
- configured Spring BeanPostProcessors. If Spring's context-wide annotation-config has
1718
- been activated, annotations in ViewPreparer classes will be automatically detected and
1719
- applied. Note that this expects preparer __classes__ in the Tiles definition files, just
1720
- like the default `PreparerFactory` does.
1716
+ configured Spring BeanPostProcessors. If Spring's context-wide annotation configuration has
1717
+ been activated, annotations in ` ViewPreparer` classes are automatically detected and
1718
+ applied. Note that this expects preparer classes in the Tiles definition files, as
1719
+ the default `PreparerFactory` does.
1721
1720
1722
1721
Specify `SpringBeanPreparerFactory` to operate on specified preparer __names__ instead
1723
1722
of classes, obtaining the corresponding Spring bean from the DispatcherServlet's
1724
1723
application context. The full bean creation process will be in the control of the Spring
1725
1724
application context in this case, allowing for the use of explicit dependency injection
1726
- configuration, scoped beans etc. Note that you need to define one Spring bean definition
1727
- per preparer name (as used in your Tiles definitions).
1725
+ configuration, scoped beans, and so on. Note that you need to define one Spring bean definition
1726
+ for each preparer name (as used in your Tiles definitions). The following example shows
1727
+ how to define a `SpringBeanPreparerFactory` property on a `TilesConfigurer` bean:
1728
1728
1729
1729
[source,xml,indent=0]
1730
1730
[subs="verbatim,quotes"]
@@ -1787,7 +1787,7 @@ Similar requirements apply for implementing `AbstractRssFeedView`, as shown belo
1787
1787
[source,java,indent=0]
1788
1788
[subs="verbatim,quotes"]
1789
1789
----
1790
- public class SampleContentAtomView extends AbstractRssFeedView {
1790
+ public class SampleContentRssView extends AbstractRssFeedView {
1791
1791
1792
1792
@Override
1793
1793
protected void buildFeedMetadata(Map<String, Object> model,
@@ -1828,16 +1828,13 @@ dynamically from the model data. The document is the view and will be streamed f
1828
1828
server with the correct content type to (hopefully) enable the client PC to run their
1829
1829
spreadsheet or PDF viewer application in response.
1830
1830
1831
- In order to use Excel views, you need to add the Apache POI library to your classpath,
1832
- and for PDF generation preferably the OpenPDF library.
1831
+ In order to use Excel views, you need to add the Apache POI library to your classpath.
1832
+ For PDF generation, you need to add ( preferably) the OpenPDF library.
1833
1833
1834
- [NOTE]
1835
- ====
1836
- Use the latest versions of the underlying document generation libraries if possible.
1837
- In particular, we strongly recommend OpenPDF (e.g. OpenPDF 1.0.5) instead of the
1838
- outdated original iText 2.1.7 since it is actively maintained and fixes an important
1839
- vulnerability for untrusted PDF content.
1840
- ====
1834
+ NOTE: You should use the latest versions of the underlying document-generation libraries,
1835
+ if possible. In particular, we strongly recommend OpenPDF (for example, OpenPDF 1.0.5)
1836
+ instead of the outdated original iText 2.1.7, since OpenPDF is actively maintained and
1837
+ fixes an important vulnerability for untrusted PDF content.
1841
1838
1842
1839
1843
1840
@@ -1896,11 +1893,11 @@ an external definition (by name) or as a `View` instance from the handler method
1896
1893
1897
1894
The `MappingJackson2JsonView` uses the Jackson library's `ObjectMapper` to render the response
1898
1895
content as JSON. By default, the entire contents of the model map (with the exception of
1899
- framework-specific classes) will be encoded as JSON. For cases where the contents of the
1900
- map need to be filtered, users may specify a specific set of model attributes to encode
1901
- via the `modelKeys` property. The `extractValueFromSingleKeyModel` property may also be
1902
- used to have the value in single-key models extracted and serialized directly rather than
1903
- as a map of model attributes.
1896
+ framework-specific classes) are encoded as JSON. For cases where the contents of the
1897
+ map need to be filtered, you can specify a specific set of model attributes to encode
1898
+ by using the `modelKeys` property. You can also use the `extractValueFromSingleKeyModel`
1899
+ property to have the value in single-key models extracted and serialized directly rather
1900
+ than as a map of model attributes.
1904
1901
1905
1902
JSON mapping can be customized as needed through the use of Jackson's provided
1906
1903
annotations. When further control is needed, a custom `ObjectMapper` can be injected
@@ -1918,11 +1915,11 @@ Spring Framework 5.1, <<mvc-cors,CORS>> should be used instead.
1918
1915
=== Jackson-based XML views
1919
1916
[.small]#<<web-reactive.adoc#webflux-view-httpmessagewriter,Same in Spring WebFlux>>#
1920
1917
1921
- The `MappingJackson2XmlView` uses the
1922
- https://github.com/FasterXML/jackson-dataformat-xml[Jackson XML extension]'s `XmlMapper`
1923
- to render the response content as XML. If the model contains multiples entries, the
1924
- object to be serialized should be set explicitly using the `modelKey` bean property.
1925
- If the model contains a single entry, it will be serialized automatically.
1918
+ `MappingJackson2XmlView` uses the
1919
+ https://github.com/FasterXML/jackson-dataformat-xml[Jackson XML extension's] `XmlMapper`
1920
+ to render the response content as XML. If the model contains multiple entries, you should
1921
+ explicitly set the object to be serialized by using the `modelKey` bean property. If the
1922
+ model contains a single entry, it is serialized automatically.
1926
1923
1927
1924
XML mapping can be customized as needed through the use of JAXB or Jackson's provided
1928
1925
annotations. When further control is needed, a custom `XmlMapper` can be injected
@@ -1935,13 +1932,12 @@ serializers/deserializers need to be provided for specific types.
1935
1932
[[mvc-view-xml-marshalling]]
1936
1933
== XML marshalling
1937
1934
1938
- The `MarshallingView` uses an XML `Marshaller` defined in the `org.springframework.oxm`
1939
- package to render the response content as XML. The object to be marshalled can be set
1940
- explicitly using `` MarshallingView`` 's `modelKey` bean property. Alternatively, the view
1941
- will iterate over all model properties and marshal the first type that is supported
1935
+ The `MarshallingView` uses an XML `Marshaller` ( defined in the `org.springframework.oxm`
1936
+ package) to render the response content as XML. You can explicitly set the object to be
1937
+ marshalled by using a ` MarshallingView` instance 's `modelKey` bean property. Alternatively,
1938
+ the view iterates over all model properties and marshals the first type that is supported
1942
1939
by the `Marshaller`. For more information on the functionality in the
1943
- `org.springframework.oxm` package refer to the chapter
1944
- <<data-access.adoc#oxm,Marshalling XML using O/X Mappers>>.
1940
+ `org.springframework.oxm` package, see <<data-access.adoc#oxm,Marshalling XML using O/X Mappers>>.
1945
1941
1946
1942
1947
1943
0 commit comments