@@ -37460,25 +37460,22 @@ chapter.
37460
37460
[[portlet-introduction]]
37461
37461
=== Introduction
37462
37462
37463
- .JSR-168 The Java Portlet Specification
37463
+ .JSR-286 The Java Portlet Specification
37464
37464
****
37465
- For more general information about portlet development, please review a whitepaper from
37466
- Oracle entitled
37467
- http://www.oracle.com/technetwork/java/index-raji-test-141933.html["Introduction
37468
- to JSR 168"], and of course the
37469
- http://jcp.org/aboutJava/communityprocess/final/jsr168/[JSR-168 Specification] itself.
37465
+ For more general information about portlet development, please review the
37466
+ https://jcp.org/en/jsr/detail?id=286[JSR-286 Specification] itself.
37470
37467
****
37471
37468
37472
37469
In addition to supporting conventional (servlet-based) Web development, Spring also
37473
- supports JSR-168 Portlet development. As much as possible, the Portlet MVC framework is
37470
+ supports JSR-286 Portlet development. As much as possible, the Portlet MVC framework is
37474
37471
a mirror image of the Web MVC framework, and also uses the same underlying view
37475
37472
abstractions and integration technology. So, be sure to review the chapters entitled
37476
37473
<<mvc>> and <<view>> before continuing with this chapter.
37477
37474
37478
37475
[NOTE]
37479
37476
====
37480
37477
Bear in mind that while the concepts of Spring MVC are the same in Spring Portlet MVC,
37481
- there are some notable differences created by the unique workflow of JSR-168 portlets.
37478
+ there are some notable differences created by the unique workflow of JSR-286 portlets.
37482
37479
====
37483
37480
37484
37481
The main way in which portlet workflow differs from servlet workflow is that the request
@@ -37508,7 +37505,7 @@ guide the user through controlled navigations that drive business processes.
37508
37505
For more information about SWF, consult the Spring Web Flow website.
37509
37506
****
37510
37507
37511
- The dual phases of portlet requests are one of the real strengths of the JSR-168
37508
+ The dual phases of portlet requests are one of the real strengths of the JSR-286
37512
37509
specification. For example, dynamic search results can be updated routinely on the
37513
37510
display without the user explicitly rerunning the search. Most other portlet MVC
37514
37511
frameworks attempt to completely hide the two phases from the developer and make it look
@@ -37954,7 +37951,7 @@ can instantiate an existing `Portlet` as a `Controller` as follows:
37954
37951
----
37955
37952
37956
37953
This can be very valuable since you can then use interceptors to pre-process and
37957
- post-process requests going to these portlets. Since JSR-168 does not support any kind
37954
+ post-process requests going to these portlets. Since JSR-286 does not support any kind
37958
37955
of filter mechanism, this is quite handy. For example, this can be used to wrap the
37959
37956
Hibernate `OpenSessionInViewInterceptor` around a MyFaces JSF Portlet.
37960
37957
@@ -38246,7 +38243,7 @@ The following example shows how to use the `CommonsPortletMultipartResolver`:
38246
38243
Of course you also need to put the appropriate jars in your classpath for the multipart
38247
38244
resolver to work. In the case of the `CommonsMultipartResolver`, you need to use
38248
38245
`commons-fileupload.jar`. Be sure to use at least version 1.1 of Commons FileUpload as
38249
- previous versions do not support JSR-168 Portlet applications.
38246
+ previous versions do not support JSR-286 Portlet applications.
38250
38247
38251
38248
Now that you have seen how to set Portlet MVC up to handle multipart requests, let's
38252
38249
talk about how to actually use it. When `DispatcherPortlet` detects a multipart request,
@@ -38646,6 +38643,62 @@ using this annotation:
38646
38643
}
38647
38644
----
38648
38645
38646
+ As of Spring 3.0, there are dedicated `@ActionMapping` and `@RenderMapping` (as well as
38647
+ `@ResourceMapping` and `@EventMapping`) annotations which can be used instead:
38648
+
38649
+ [source,java,indent=0]
38650
+ [subs="verbatim,quotes"]
38651
+ ----
38652
+ @Controller
38653
+ @RequestMapping("EDIT")
38654
+ @SessionAttributes("site")
38655
+ public class PetSitesEditController {
38656
+
38657
+ private Properties petSites;
38658
+
38659
+ public void setPetSites(Properties petSites) {
38660
+ this.petSites = petSites;
38661
+ }
38662
+
38663
+ @ModelAttribute("petSites")
38664
+ public Properties getPetSites() {
38665
+ return this.petSites;
38666
+ }
38667
+
38668
+ @RenderMapping // default (action=list)
38669
+ public String showPetSites() {
38670
+ return "petSitesEdit";
38671
+ }
38672
+
38673
+ @RenderMapping(params = "action=add")
38674
+ public String showSiteForm(Model model) {
38675
+ // Used for the initial form as well as for redisplaying with errors.
38676
+ if (!model.containsAttribute("site")) {
38677
+ model.addAttribute("site", new PetSite());
38678
+ }
38679
+
38680
+ return "petSitesAdd";
38681
+ }
38682
+
38683
+ @ActionMapping(params = "action=add")
38684
+ public void populateSite(@ModelAttribute("site") PetSite petSite,
38685
+ BindingResult result, SessionStatus status, ActionResponse response) {
38686
+ new PetSiteValidator().validate(petSite, result);
38687
+ if (!result.hasErrors()) {
38688
+ this.petSites.put(petSite.getName(), petSite.getUrl());
38689
+ status.setComplete();
38690
+ response.setRenderParameter("action", "list");
38691
+ }
38692
+ }
38693
+
38694
+ @ActionMapping(params = "action=delete")
38695
+ public void removeSite(@RequestParam("site") String site, ActionResponse response) {
38696
+ this.petSites.remove(site);
38697
+ response.setRenderParameter("action", "list");
38698
+ }
38699
+ }
38700
+ ----
38701
+
38649
38702
38650
38703
38651
38704
[[portlet-ann-requestmapping-arguments]]
@@ -38890,7 +38943,7 @@ configuration.
38890
38943
[[portlet-deployment]]
38891
38944
=== Portlet application deployment
38892
38945
The process of deploying a Spring Portlet MVC application is no different than deploying
38893
- any JSR-168 Portlet application. However, this area is confusing enough in general that
38946
+ any JSR-286 Portlet application. However, this area is confusing enough in general that
38894
38947
it is worth talking about here briefly.
38895
38948
38896
38949
Generally, the portal/portlet container runs in one webapp in your servlet container and
@@ -38899,7 +38952,7 @@ container webapp to make calls into your portlet webapp it must make cross-conte
38899
38952
to a well-known servlet that provides access to the portlet services defined in your
38900
38953
`portlet.xml` file.
38901
38954
38902
- The JSR-168 specification does not specify exactly how this should happen, so each
38955
+ The JSR-286 specification does not specify exactly how this should happen, so each
38903
38956
portlet container has its own mechanism for this, which usually involves some kind of
38904
38957
"deployment process" that makes changes to the portlet webapp itself and then registers
38905
38958
the portlets within the portlet container.
0 commit comments