[
https://issues.apache.org/jira/browse/PLUTO-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Griffin updated PLUTO-772:
-------------------------------
Description:
This issue serves as a task for implementing a large subset of [MVC
1.0|https://www.mvc-spec.org] for use with portlet technology in Apache Pluto.
[The MVC 1.0 Specification, JavaDoc, and API are all licensed using The Apache
License 2.0|https://www.mvc-spec.org/news/2017/05/17/license-decided.html].
Although the Spec is also licensed using the standard JCP click-through
specification license, Pluto's implementation is in no way associated with the
JCP click-through specification license, and is not an implementation that ever
intends to pass the TCK, especially since the TCK is servlet/webapp based and
is incompatible with portlet environments.
h2. Background
Portlet 3.0 supplied the concept of a CDI "Bean Portlet" and introduced
annotation-driven method dispatching with annotations such as
{{@ActionMethod}}, {{@RenderMethod}}, and {{@ServeResourceMethod}}. This is
effectively the "C" (Controller) concern of the MVC design pattern.
However, Portlet 3.0 did not give us the "M" (Model) or "V" (View) concerns,
nor did it give us a CDI scope that allows for model data to survive from the
{{ACTION_PHASE}} to the {{RENDER_PHASE}} of the portlet lifecycle.
In order to remedy this shortcoming, Pluto's implementation of MVC 1.0
satisfies a large subset of MVC 1.0 requirements in a way that makes sense for
portlet developers. Requirements based on JAX-RS method dispatching are not
(and will not be) implemented -- instead, Pluto's implementation relies on the
aforementioned Portlet 3.0 CDI "Bean Portlet" method dispatching. Pluto also
implements {{@RedirectScoped}} so that model data to survive from the
{{ACTION_PHASE}} to the {{RENDER_PHASE}} of the portlet lifecycle.
h2. Security
MVC 1.0 features the {{@CsrfProtected}} annotation which enables and enforces
CSRF protection for controller methods. The Apache Pluto implementation of MVC
1.0 leverages CSRF protection supplied by Spring Security. For more
information, see PLUTO-768.
was:
This issue serves as a task for implementing a large subset of [MVC
1.0|https://www.mvc-spec.org] for use with portlet technology in Apache Pluto.
[The MVC 1.0 Specification, JavaDoc, and API are all licensed using The Apache
License 2.0|https://www.mvc-spec.org/news/2017/05/17/license-decided.html].
Although the Spec is also licensed using the standard JCP click-through
specification license, Pluto's implementation is in no way associated with the
JCP click-through specification license, and is not an implementation that ever
intends to pass the TCK, especially since the TCK is servlet/webapp based and
is incompatible with portlet environments.
h2. Background
Portlet 3.0 supplied the concept of a CDI "Bean Portlet" and introduced
annotation-driven method dispatching with annotations such as
{{@ActionMethod}}, {{@RenderMethod}}, and {{@ServeResourceMethod}}. This is
effectively the "C" (Controller) concern of the MVC design pattern.
However, Portlet 3.0 did not give us the "M" (Model) or "V" (View) concerns,
nor did it give us a CDI scope that allows for model data to survive from the
{{ACTION_PHASE}} to the {{RENDER_PHASE}} of the portlet lifecycle.
In order to remedy this shortcoming, Pluto's implementation of MVC 1.0
satisfies a large subset of MVC 1.0 requirements in a way that makes sense for
portlet developers. Requirements based on JAX-RS method dispatching are not
(and will not be) implemented -- instead, Pluto's implementation relies on the
aforementioned Portlet 3.0 CDI "Bean Portlet" method dispatching. Pluto also
implements {{@RedirectScoped}} so that model data to survive from the
{{ACTION_PHASE}} to the {{RENDER_PHASE}} of the portlet lifecycle.
> Implement MVCBean portlets
> --------------------------
>
> Key: PLUTO-772
> URL: https://issues.apache.org/jira/browse/PLUTO-772
> Project: Pluto
> Issue Type: New Feature
> Components: portlet container
> Affects Versions: 3.0.2
> Reporter: Neil Griffin
> Assignee: Neil Griffin
> Priority: Major
>
> This issue serves as a task for implementing a large subset of [MVC
> 1.0|https://www.mvc-spec.org] for use with portlet technology in Apache
> Pluto. [The MVC 1.0 Specification, JavaDoc, and API are all licensed using
> The Apache License
> 2.0|https://www.mvc-spec.org/news/2017/05/17/license-decided.html]. Although
> the Spec is also licensed using the standard JCP click-through specification
> license, Pluto's implementation is in no way associated with the JCP
> click-through specification license, and is not an implementation that ever
> intends to pass the TCK, especially since the TCK is servlet/webapp based and
> is incompatible with portlet environments.
> h2. Background
> Portlet 3.0 supplied the concept of a CDI "Bean Portlet" and introduced
> annotation-driven method dispatching with annotations such as
> {{@ActionMethod}}, {{@RenderMethod}}, and {{@ServeResourceMethod}}. This is
> effectively the "C" (Controller) concern of the MVC design pattern.
> However, Portlet 3.0 did not give us the "M" (Model) or "V" (View) concerns,
> nor did it give us a CDI scope that allows for model data to survive from the
> {{ACTION_PHASE}} to the {{RENDER_PHASE}} of the portlet lifecycle.
> In order to remedy this shortcoming, Pluto's implementation of MVC 1.0
> satisfies a large subset of MVC 1.0 requirements in a way that makes sense
> for portlet developers. Requirements based on JAX-RS method dispatching are
> not (and will not be) implemented -- instead, Pluto's implementation relies
> on the aforementioned Portlet 3.0 CDI "Bean Portlet" method dispatching.
> Pluto also implements {{@RedirectScoped}} so that model data to survive from
> the {{ACTION_PHASE}} to the {{RENDER_PHASE}} of the portlet lifecycle.
> h2. Security
> MVC 1.0 features the {{@CsrfProtected}} annotation which enables and enforces
> CSRF protection for controller methods. The Apache Pluto implementation of
> MVC 1.0 leverages CSRF protection supplied by Spring Security. For more
> information, see PLUTO-768.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
