Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Won't Fix
    • Affects Version/s: 1.2
    • Fix Version/s: 1.2
    • Component/s: Uncategorized
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Sun

    • Issuezilla Id:
      15

      Description

      >>>>> 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 <f:view>.

      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.

        Activity

        Hide
        Ed Burns added a comment -

        up to p1 feature.

        Show
        Ed Burns added a comment - up to p1 feature.
        Hide
        Ed Burns added a comment -

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

        Show
        Ed Burns added a comment - I have asked Ryan Lubke of the Sun team to produce a proposal for this, based on Adam's content in this message.
        Hide
        Ed Burns added a comment -

        Created an attachment (id=2)
        source for proposal

        Show
        Ed Burns added a comment - Created an attachment (id=2) source for proposal
        Hide
        Ed Burns added a comment -

        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
        Show
        Ed Burns added a comment - 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
        Hide
        Ed Burns added a comment -

        take ownership

        Show
        Ed Burns added a comment - take ownership
        Hide
        Ed Burns added a comment -

        I've resolved ViewHandler, StateManager, and ResponseWriter and left the EL bits
        until we have the EL alignment done.

        Show
        Ed Burns added a comment - I've resolved ViewHandler, StateManager, and ResponseWriter and left the EL bits until we have the EL alignment done.
        Hide
        Ed Burns added a comment -

        Prepare to delete "spec" subcomponent.

        Show
        Ed Burns added a comment - Prepare to delete "spec" subcomponent.
        Hide
        Ed Burns added a comment -

        Move all to 1.2

        Show
        Ed Burns added a comment - Move all to 1.2
        Hide
        Manfred Riem added a comment -

        Closing resolved issue out

        Show
        Manfred Riem added a comment - Closing resolved issue out

          People

          • Assignee:
            Ed Burns
            Reporter:
            Ed Burns
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: