Enhanced Decorator support

eclipse-faces-bot commented 20 years ago

On Thu, 08 Apr 2004 16:49:03 -0700, Adam Winer adam.winer@ORACLE.COM said:

AW> The faces-config.xml support for the decorator pattern is AW> one of my favorite features in JSF, and I like pushing AW> it at users whenever I get a chance. But it is a pain AW> using it, especially on objects with large APIs (like ViewHandler).

AW> I'd recommend we follow the lead of the Servlet API and AW> provide convenience classes for implementing the Decorator AW> pattern. (They were a bit more than convenience classes AW> for the Servlet API, but anyway...)

AW> This would make implementing the Decorator pattern much, AW> much simpler. It also makes it much more robust - as things AW> stand now, every time we add a method to any of these AW> decoratable APIs in a new version of JSF, all existing AW> Decorators will break!

AW> This would involve, as an extreme, adding the following ten AW> classes to JSF: AW> ApplicationFactoryWrapper AW> NavigationHandlerWrapper AW> ViewHandlerWrapper AW> StateManagerWrapper AW> FacesContextFactoryWrapper AW> ResponseWriterWrapper AW> PropertyResolverWrapper AW> VariableResolverWrapper AW> LifecycleFactoryWrapper AW> RenderKitFactoryWrapper

AW> But of that long list, only four are especially useful: AW> ViewHandlerWrapper AW> StateManagerWrapper AW> ResponseWriterWrapper AW> PropertyResolverWrapper

AW> The rest are either rather esoteric, or are wrappers for AW> single method APIs (where using a canned wrapper would AW> be even harder than writing the wrapper from scratch).

AW> BTW, I'm aware this nothing built-in about decorator support AW> for ResponseWriters. But we've found over the last few AW> years of using an analogous concept that decorating ResponseWriters AW> is very, very useful for things like:

AW> - Optimizing page content AW> - Catching common HTML errors AW> - Adding whitespace (the current RI pushes this task to each AW> renderer) AW> - Sliding in design-time hooks AW> - Adding comments to the page output (e.g., this content AW> was built by a UICommand with id='foo')

AW> ... all of which don't require bloating the base response writer AW> or adding any performance or output size overhead for users not AW> using the decorator. And we don't really need anything special AW> to support decorating ResponseWriters - that can be done in the AW> JSP page with some easy tags sliding inside of .

AW> This would be a very nice improvement in JSF 1.1, and I AW> don't think it's a huge amount of work, but I could AW> understand punting it to JSF 1.2.

Environment

Operating System: All Platform: Sun

Affected Versions

[1.2]

eclipse-faces-bot commented 5 years ago

Issue Imported From: https://github.com/javaee/javaserverfaces-spec/issues/15
Original Issue Raised By:@glassfishrobot
Original Issue Assigned To: @edburns
Original Issue Closed By:@glassfishrobot

eclipse-faces-bot commented 20 years ago

@glassfishrobot Commented Reported by @edburns

eclipse-faces-bot commented 20 years ago

@glassfishrobot Commented @edburns said: up to p1 feature.

eclipse-faces-bot commented 20 years ago

@glassfishrobot Commented @edburns said: I have asked Ryan Lubke of the Sun team to produce a proposal for this, based on Adam's content in this message.

eclipse-faces-bot commented 20 years ago

@glassfishrobot Commented @edburns said: Created an attachment (id=2) source for proposal

eclipse-faces-bot commented 20 years ago

@glassfishrobot Commented @edburns said: From Ryan Lubke:

Motivation

AW> The faces-config.xml support for the decorator pattern is AW> one of my favorite features in JSF, and I like pushing AW> it at users whenever I get a chance. But it is a pain AW> using it, especially on objects with large APIs (like ViewHandler).

AW> I'd recommend we follow the lead of the Servlet API and AW> provide convenience classes for implementing the Decorator AW> pattern. (They were a bit more than convenience classes AW> for the Servlet API, but anyway...)

AW> This would make implementing the Decorator pattern much, AW> much simpler. It also makes it much more robust - as things AW> stand now, every time we add a method to any of these AW> decoratable APIs in a new version of JSF, all existing AW> Decorators will break!

Proposal

Create wrapper classes for the following:

ViewHandlerWrapper
StateManagerWrapper
ResponseWriterWrapper
PropertyResolverWrapper
VariableResolverWrapper (this one was added more for balance)
These classes have a single constructor which takes an instance of the class they are designed to wrap.
The default behavior for the methods of each implementation call through to the wrapped instance

eclipse-faces-bot commented 20 years ago

@glassfishrobot Commented @edburns said: take ownership

eclipse-faces-bot commented 20 years ago

@glassfishrobot Commented @edburns said: I've resolved ViewHandler, StateManager, and ResponseWriter and left the EL bits until we have the EL alignment done.

eclipse-faces-bot commented 14 years ago

@glassfishrobot Commented @edburns said: Prepare to delete "spec" subcomponent.

eclipse-faces-bot commented 14 years ago

@glassfishrobot Commented @edburns said: Move all to 1.2

eclipse-faces-bot commented 10 years ago

@glassfishrobot Commented @manfredriem said: Closing resolved issue out

eclipse-faces-bot commented 20 years ago

@glassfishrobot Commented File: wrapper-src.zip Attached By: @edburns

eclipse-faces-bot commented 7 years ago

@glassfishrobot Commented This issue was imported from java.net JIRA JAVASERVERFACES_SPEC_PUBLIC-15

eclipse-faces-bot commented 14 years ago

@glassfishrobot Commented Marked as won't fix on Thursday, March 4th 2010, 6:09:29 am

jakartaee / faces