+1
___
Kito D. Mann | @kito99 | Author, JSF in Action
Web Components, Polymer, JSF, PrimeFaces, Java EE, and Liferay training and
consulting
Virtua, Inc. | virtua.tech
JSFCentral.com | @jsfcentral | knowesis.io
<
http://knowesis.io/web/webcomponents> - fresh Web Components info
+1 203-998-0403
* Listen to the Enterprise Java Newscast: *http://
<
http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
<
http://ww.enterprisejavanews.com>*
On Wed, Jul 27, 2016 at 3:02 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:
> I created https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1429
> on this.
>
> While at it, I'd propose to improve FacesWrapper#getWrapped() on this as
> well.
>
> Old:
> * <p class="changed_added_2_0">A class that implements this
> * interface uses this method to return an instance of the class
> * being wrapped.</p>
>
>
> New:
>
> * <p class="changed_modified_2_3">A class that implements this
> * interface must use this method to access the instance of the class
> * being wrapped.</p>
>
>
> Cheers, B
>
> On Tue, Jul 26, 2016 at 9:20 AM, arjan tijms <arjan.tijms_at_gmail.com>
> wrote:
>
>> +1 great idea!
>>
>> On Tue, Jul 26, 2016 at 12:56 AM, Leonardo Uribe <leonardo.uribe_at_irian.at
>> > wrote:
>>
>>> +1
>>>
>>> 2016-07-25 15:47 GMT-05:00 Neil Griffin <neil.griffin_at_portletfaces.org>:
>>>
>>>> +1 but it would be interesting to know why the reduction of boilerplate
>>>> wasn't part of the wrapper classes from the beginning. The absence makes it
>>>> seem intentional.
>>>>
>>>> > On Jul 23, 2016, at 5:54 PM, Josh Juneau <juneau001_at_gmail.com> wrote:
>>>> >
>>>> > +1, I agree that consistency makes sense.
>>>> >
>>>> > Josh Juneau
>>>> > juneau001_at_gmail.com
>>>> > http://jj-blogger.blogspot.com
>>>> > https://www.apress.com/index.php/author/author/view/id/1866
>>>> >
>>>> >
>>>> > On Sat, Jul 23, 2016 at 4:42 PM, Bauke Scholtz <balusc_at_gmail.com>
>>>> wrote:
>>>> > Hi,
>>>> >
>>>> > Check all implementing classes of FacesWrapper:
>>>> https://docs.oracle.com/javaee/7/api/javax/faces/FacesWrapper.html
>>>> When extending such a FacesWrapper class like ResourceWrapper you always
>>>> end up with below minimally required boilerplate:
>>>> >
>>>> >
>>>> > public class MyResource extends ResourceWrapper {
>>>> > private Resource wrapped;
>>>> >
>>>> > public MyResource(Resource wrapped) {
>>>> > this.wrapped = wrapped;
>>>> > }
>>>> >
>>>> > @Override
>>>> > public Resource getWrapped() {
>>>> > return wrapped;
>>>> > }
>>>> > }
>>>> >
>>>> >
>>>> > Compare with a.o.
>>>> http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequestWrapper.html
>>>> It has an explicit constructor taking wrapped instance and already a
>>>> default getWrapped() implementation returning exactly that.
>>>> >
>>>> >
>>>> > public class MyRequest extends HttpServletRequestWrapper {
>>>> > public MyRequest(HttpServletRequest wrapped) {
>>>> > super(wrapped);
>>>> > }
>>>> > }
>>>> >
>>>> >
>>>> > You just have to push wrapped to super() and there's already a
>>>> default implementation for getWrapped(). This also forces developers to use
>>>> getWrapped() instead of the local variable. Because, when developers use
>>>> the local variable, the decorator chain may break when the wrapper instance
>>>> is in turn wrapped by another wrapper instance (as can be seen in a.o.
>>>> ResponseWriterWrapper when using MyFaces as its PartialResponseWriter
>>>> extends from it but internally doesn't correctly use getWrapped()).
>>>> >
>>>> > I propose improving all FacesWrapper classes to add such a
>>>> constructor (along with the default one) so that boilerplate can be reduced
>>>> and robustness can be improved.
>>>> >
>>>> > Thoughts?
>>>> >
>>>> > Cheers, B
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>
>>
>