Details

    • Type: Sub-task Sub-task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Component/s: Components/Renderers
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      322
    • Status Whiteboard:
      Hide

      EGTop5 effort_moderate cat2 javadoc size_medium importance_medium draft

      Show
      EGTop5 effort_moderate cat2 javadoc size_medium importance_medium draft

      Description

      There are currently nice interfaces, like ValueHolder and EditableValueHolder.
      But this isn't enough.

      The minimal contract of creating a (custom) JSF component is UIComponent.
      It is not necessary to extend something like UIComponentBase or even UIInput,
      which is good.

      For instance for checking if a component is able to be validated, some do a
      instanceof UIInput, which would fail in some cases (as in Trinidad). Luckily
      enough, we have the EditableValueHolder interfaces, so checking against that is
      fine.

      I noticed a lot of issues in the past with UIForm, since there is not "Form"
      interface for that. One of the issues, when making Tomahawk working with
      Trinidad/ADF Faces was that the Trinidad/ADF Faces form isn't extending UIForm
      (which isn't wrong). We ended up, using a String-based identifier (component
      family) for ensuring the component (from Trinidad) is a form. With an interface
      for Form (like for EditableValueHolder) there weren't a need for "checking Strings".

      This is true for "table components" as well. A "table interface" would be nice.

        Issue Links

          Activity

          mwessendorf created issue -
          Hide
          mwessendorf added a comment -

          On an interface for "Form", I can think about things like:
          -autoComplete
          -usesUpload (bool, when TRUE => set enctype="multipart/form-data")
          (and/or enctype)
          -prependId
          -defaultCommand (executed when hitting ENTER inside the form)

          On an interfaces for Tables (call it structuredData or so, since it could be
          implemented in a custom Tree, for instance) I can think of these:
          -var ?
          See Trinidad's UIXCollection CLASS, which is the base for all structured Data
          (in Trinidad):
          http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/component/UIXCollection.html

          Again such a "generic" interfaces could be useful when creating tree's (instead
          of extending UIData (like Tomahawk or the Hans Bergsten book).

          But... it is really important to have STRONG types, instead of messing around
          with Strings (component family)

          Show
          mwessendorf added a comment - On an interface for "Form", I can think about things like: -autoComplete -usesUpload (bool, when TRUE => set enctype="multipart/form-data") (and/or enctype) -prependId -defaultCommand (executed when hitting ENTER inside the form) On an interfaces for Tables (call it structuredData or so, since it could be implemented in a custom Tree, for instance) I can think of these: -var ? See Trinidad's UIXCollection CLASS, which is the base for all structured Data (in Trinidad): http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/component/UIXCollection.html Again such a "generic" interfaces could be useful when creating tree's (instead of extending UIData (like Tomahawk or the Hans Bergsten book). But... it is really important to have STRONG types, instead of messing around with Strings (component family)
          Hide
          Ed Burns added a comment -

          Add status whiteboard: EGTop5

          Show
          Ed Burns added a comment - Add status whiteboard: EGTop5
          Hide
          Ed Burns added a comment -

          effort_moderate

          Show
          Ed Burns added a comment - effort_moderate
          Hide
          Ed Burns added a comment -

          change target_milestone to 2.0

          Show
          Ed Burns added a comment - change target_milestone to 2.0
          Hide
          Ed Burns added a comment -

          As discussed at JSFOne, I think we need a behavioral interface for components that manage collections of
          children, such as trees, tables, and such.

          Show
          Ed Burns added a comment - As discussed at JSFOne, I think we need a behavioral interface for components that manage collections of children, such as trees, tables, and such.
          Hide
          Ed Burns added a comment -
              • Issue 189 has been marked as a duplicate of this issue. ***
          Show
          Ed Burns added a comment - Issue 189 has been marked as a duplicate of this issue. ***
          Hide
          kito75 added a comment -

          It'd make sense to expose a isPostBack() method (which I think is on
          FacesContext in 2.0) through the Form interface, as well.

          Show
          kito75 added a comment - It'd make sense to expose a isPostBack() method (which I think is on FacesContext in 2.0) through the Form interface, as well.
          Hide
          Ed Burns added a comment -
              • Issue 245 has been marked as a duplicate of this issue. ***
          Show
          Ed Burns added a comment - Issue 245 has been marked as a duplicate of this issue. ***
          Hide
          Ed Burns added a comment -

          We just didn't get to this one. Sorry Matzew.

          Show
          Ed Burns added a comment - We just didn't get to this one. Sorry Matzew.
          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 these to unscheduled because we need to target them correctly. 2.next isn't
          specific enough.

          Show
          Ed Burns added a comment - Move these to unscheduled because we need to target them correctly. 2.next isn't specific enough.
          Hide
          Ed Burns added a comment -

          I really don't think this is a P1 also.

          Show
          Ed Burns added a comment - I really don't think this is a P1 also.
          Hide
          kito75 added a comment -

          Matthias, aren't your example form properties more renderer-specific?

          Show
          kito75 added a comment - Matthias, aren't your example form properties more renderer-specific?
          Hide
          Ed Burns added a comment -

          cat2

          Show
          Ed Burns added a comment - cat2
          Hide
          Ed Burns added a comment -

          javadoc

          Show
          Ed Burns added a comment - javadoc
          Hide
          Ed Burns added a comment -

          components

          Show
          Ed Burns added a comment - components
          Hide
          Ed Burns added a comment -

          These are targeted at 2.1.

          Show
          Ed Burns added a comment - These are targeted at 2.1.
          Hide
          rogerk added a comment -

          triage

          Show
          rogerk added a comment - triage
          Hide
          Ed Burns added a comment -

          rogerk

          Show
          Ed Burns added a comment - rogerk
          Hide
          rogerk added a comment -

          triage

          Show
          rogerk added a comment - triage
          Hide
          rogerk added a comment -

          triage

          Show
          rogerk added a comment - triage
          kenaiadmin made changes -
          Field Original Value New Value
          issue.field.bugzillaimportkey 322 19927
          made changes -
          Ed Burns made changes -
          Status Whiteboard EGTop5 effort_moderate cat2 javadoc size_medium importance_medium EGTop5 effort_moderate cat2 javadoc size_medium importance_medium draft
          Ed Burns made changes -
          Parent JAVASERVERFACES_SPEC_PUBLIC-935 [ 98258 ]
          Issue Type Improvement [ 4 ] Sub-task [ 5 ]
          Ed Burns made changes -
          Fix Version/s 2.3 [ 16372 ]
          Fix Version/s 2.2 [ 10403 ]
          Ed Burns made changes -
          Assignee rogerk [ rogerk ]
          Hide
          Ed Burns added a comment -

          Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

          Show
          Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
          Ed Burns made changes -
          Priority Critical [ 2 ] Trivial [ 5 ]
          Fix Version/s 2.3 [ 16372 ]
          Ed Burns made changes -
          Priority Trivial [ 5 ] Major [ 3 ]
          Hide
          Ed Burns added a comment -

          Target for 2.3

          Show
          Ed Burns added a comment - Target for 2.3

            People

            • Assignee:
              Unassigned
              Reporter:
              mwessendorf
            • Votes:
              8 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: