Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0
    • Fix Version/s: 2.2
    • Component/s: Components/Renderers
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      901
    • Status Whiteboard:
      Hide

      size_large importance_large draft

      Show
      size_large importance_large draft

      Description

      The "targets" attribute, present on several elements in the <cc:interface> section, is a blemish on the
      purity of the interface declaration. It introduces a touch of implementation detail to the <cc:interface>
      section. The "targets" attribute conceptually pushes information from the interface into the
      implementation.

      A less architecturally offensive solution is to make it so the implementation pulls this information from
      the interface section.

        Issue Links

          Activity

          Hide
          Ed Burns added a comment -

          Target 2.2

          Show
          Ed Burns added a comment - Target 2.2
          Hide
          Jakob Korherr added a comment -

          Created an attachment (id=333)
          Prototype for implementsActionSource,... including systest for actionSource and editableValueHolder

          Show
          Jakob Korherr added a comment - Created an attachment (id=333) Prototype for implementsActionSource,... including systest for actionSource and editableValueHolder
          Hide
          Jakob Korherr added a comment -

          I added a prototype-patch for this issue that adds the following tags:

          • cc:implementsActionSource
          • cc:implementsEditableValueHolder
          • cc:implementsValueHolder
          • cc:insertClientBehavior

          In addition, the patch contains a systest for cc:implementsActionSource and
          cc:implementsEditableValueHolder.

          Everything works great and it really felt good writing the tests with these new
          tags.

          One thing did not work though: f:ajax. It seems that it has some hack for
          composite components which uses the targets attribute of cc:clientBehavior. Did
          not jump into deep here, but "normal" client behaviors are working.

          Frankly, I would really like to see some of this in JSF 2.1. If necessary, I can
          provide more systests.

          Show
          Jakob Korherr added a comment - I added a prototype-patch for this issue that adds the following tags: cc:implementsActionSource cc:implementsEditableValueHolder cc:implementsValueHolder cc:insertClientBehavior In addition, the patch contains a systest for cc:implementsActionSource and cc:implementsEditableValueHolder. Everything works great and it really felt good writing the tests with these new tags. One thing did not work though: f:ajax. It seems that it has some hack for composite components which uses the targets attribute of cc:clientBehavior. Did not jump into deep here, but "normal" client behaviors are working. Frankly, I would really like to see some of this in JSF 2.1. If necessary, I can provide more systests.
          Hide
          kellerapps added a comment -

          Without targets=, how does one route composite component attrs like ValueChangeListener & validators to an impl component?

          Show
          kellerapps added a comment - Without targets=, how does one route composite component attrs like ValueChangeListener & validators to an impl component?
          Hide
          Jakob Korherr added a comment -

          via special tags as children of the target component(s). just see the above post..

          Show
          Jakob Korherr added a comment - via special tags as children of the target component(s). just see the above post..
          Hide
          Ed Burns added a comment -

          LU> To be more explicit, this is the example that should fail:

          LU> <ez:loginPanel id="loginPanel" model="#

          {bean}

          ">
          LU> <f:actionListener for="loginEvent"
          LU> binding="#

          {bean.loginEventListener}

          " />
          LU> <f:actionListener for="loginEvent"
          LU> binding="#

          {bean.loginEventListener2}

          " />
          LU> <f:actionListener for="cancelEvent"
          LU> binding="#

          {bean.cancelEventListener}

          " />
          LU> </ez:loginPanel>

          LU> <composite:interface name="loginPanel">
          LU> <composite:actionSource name="loginEvent" />
          LU> <composite:actionSource name="cancelEvent" />
          LU> </composite:interface>
          LU> <composite:implementation>
          LU> <h:commandButton name="button1">
          LU> <f:actionListener
          LU> binding="#

          {cc.actionSource.loginEvent}

          "/>
          LU> </h:commandButton>
          LU> <x:mycompositecomponent name="button2">
          LU> <f:actionListener
          LU> binding="#

          {cc.actionSource.cancelEvent}

          " for="someOtherEvent"/>
          LU> </x:mycompositecomponent>
          LU> </composite:implementation>

          Show
          Ed Burns added a comment - LU> To be more explicit, this is the example that should fail: LU> <ez:loginPanel id="loginPanel" model="# {bean} "> LU> <f:actionListener for="loginEvent" LU> binding="# {bean.loginEventListener} " /> LU> <f:actionListener for="loginEvent" LU> binding="# {bean.loginEventListener2} " /> LU> <f:actionListener for="cancelEvent" LU> binding="# {bean.cancelEventListener} " /> LU> </ez:loginPanel> LU> <composite:interface name="loginPanel"> LU> <composite:actionSource name="loginEvent" /> LU> <composite:actionSource name="cancelEvent" /> LU> </composite:interface> LU> <composite:implementation> LU> <h:commandButton name="button1"> LU> <f:actionListener LU> binding="# {cc.actionSource.loginEvent} "/> LU> </h:commandButton> LU> <x:mycompositecomponent name="button2"> LU> <f:actionListener LU> binding="# {cc.actionSource.cancelEvent} " for="someOtherEvent"/> LU> </x:mycompositecomponent> LU> </composite:implementation>
          Hide
          Ed Burns added a comment -
          Show
          Ed Burns added a comment - testcase war showing that this mostly works. The only part that doesn't work is the passing through of the listener to the inner cc, that's issue < http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-755 >.
          Hide
          Ed Burns added a comment -

          Due to lack of reply to my message about this issue on 2 June 2011 <http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2011-06/message/1> I am closing this issue and stating that the only real problem is JAVASERVERFACES_SPEC_PUBLIC-755.

          Show
          Ed Burns added a comment - Due to lack of reply to my message about this issue on 2 June 2011 < http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2011-06/message/1 > I am closing this issue and stating that the only real problem is JAVASERVERFACES_SPEC_PUBLIC-755 .
          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:
              10 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 42 minutes
                42m