Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Labels:
      None

      Description

      hi

      Please consider naming guideline [ADFng1-04029] in the "ADF Naming and Project Layout Guidelines v1.00" [1].

      [ADFng1-04029] - Component IDs - All UI components defined in page and page fragments must have an ID. Use the JDeveloper generated ID as a prefix in lowercase, drop the numeral suffix, and give the rest of the name a meaningful name in camelcase. Keep the generated UI component IDs short.

      Is this naming guideline [ADFng1-04029] suggesting to rename all JDeveloper generated component ID's?

      many thanks
      Jan Vervecken

        Activity

        Hide
        chriscmuir added a comment -

        Thanks for lodging the issue Jan. Agreed, this is a contentious rule due to the amount of work it creates for the developer.

        This rule comes from QAs using testing tools like Selenium that they wanted more meaningful IDs. As such changing the ID of an af:inputText for a surname field to "itSurn" was deemed to satisfy the QA's demands, while still keeping the IDs short(ish).

        Another advantage is that of providing stable component IDs. For automated UI tests components need stable IDs to continue to run. If developers change the IDs the rule tests automatically fail. One thing in the IDE that makes developers change the IDs is the fact they often copy n paste components and their IDs and this creates an ID collision. The quick fix is to change the ID numeric suffix, they have no meaning and the developers do no cognitive assessment of what the ID should be. Yet we've just broken the QA's tests as a result. If we however use more meaningful component IDs like "itSurn" as there is some meaning in "Surn", developers are more likely to correct this to something more meaningful for the copied component.

        As such with two competing demands, how to write a rule that satisfies the QA's needs and not overwork the developers at the same time?

        Show
        chriscmuir added a comment - Thanks for lodging the issue Jan. Agreed, this is a contentious rule due to the amount of work it creates for the developer. This rule comes from QAs using testing tools like Selenium that they wanted more meaningful IDs. As such changing the ID of an af:inputText for a surname field to "itSurn" was deemed to satisfy the QA's demands, while still keeping the IDs short(ish). Another advantage is that of providing stable component IDs. For automated UI tests components need stable IDs to continue to run. If developers change the IDs the rule tests automatically fail. One thing in the IDE that makes developers change the IDs is the fact they often copy n paste components and their IDs and this creates an ID collision. The quick fix is to change the ID numeric suffix, they have no meaning and the developers do no cognitive assessment of what the ID should be. Yet we've just broken the QA's tests as a result. If we however use more meaningful component IDs like "itSurn" as there is some meaning in "Surn", developers are more likely to correct this to something more meaningful for the copied component. As such with two competing demands, how to write a rule that satisfies the QA's needs and not overwork the developers at the same time?
        Hide
        Jan Vervecken added a comment -

        Thank you for the update Chris.

        • about "This rule comes from QAs using testing tools like Selenium that they wanted more meaningful IDs. ..."
          • To some extent I think I understand.
            But, is your answer really, yes, naming guideline [ADFng1-04029] is suggesting to rename all JDeveloper generated component ID's?
        • about "... changing the ID of an af:inputText for a surname field to "itSurn" ..."
          • This seems like a very straightforward example.
            I wonder if there could be more specific naming guidelines for other components, or component combinations, on a (non-trivial) page?
            Maybe someone could post a sample of a page here that has naming guideline [ADFng1-04029] applied, to get a better idea of what it is aiming for.
        • about "As such with two competing demands, how to write a rule that satisfies the QA's needs and not overwork the developers at the same time?"
          • Maybe a more intelligent IDE.
            Not sure to what extent the context of a component (like its attribute values, other (parent or child) components) can be taken into account to assist a developer in giving a "more meaningful" component ID's.

        regards
        Jan Vervecken

        Show
        Jan Vervecken added a comment - Thank you for the update Chris. about "This rule comes from QAs using testing tools like Selenium that they wanted more meaningful IDs. ..." To some extent I think I understand. But, is your answer really, yes, naming guideline [ADFng1-04029] is suggesting to rename all JDeveloper generated component ID's? about "... changing the ID of an af:inputText for a surname field to "itSurn" ..." This seems like a very straightforward example. I wonder if there could be more specific naming guidelines for other components, or component combinations, on a (non-trivial) page? Maybe someone could post a sample of a page here that has naming guideline [ADFng1-04029] applied, to get a better idea of what it is aiming for. about "As such with two competing demands, how to write a rule that satisfies the QA's needs and not overwork the developers at the same time?" Maybe a more intelligent IDE. Not sure to what extent the context of a component (like its attribute values, other (parent or child) components) can be taken into account to assist a developer in giving a "more meaningful" component ID's. regards Jan Vervecken
        Hide
        chriscmuir added a comment -

        In addressing the first two abouts.

        1) Yes, the guideline 04029 is suggesting all component IDs. Having discussed this again internally there is still two camps of thought, and it can be split between developers and QAs having different needs. To accomodate the two different view points, as I've done in the ADF Code Guidelines for one of the rules, I'll document two different versions of the rule "a" a new rule suited toward developers and "b" the original rule suited towards QA. I then leave the reader to decide which to choose.

        In discussing the IDs with internal development staff, the rule new rule "a" states rather than changing all IDs, there are certain circumstances where the ID should be changed. For documentation purposes that new rule and the circumstances are as follows:

        [ADFng2-04064a] - Component ID format – For the majority of UI component IDs generated by JDeveloper leave the ID as that generated. However for any UI component that is:
        o Referred to via a partialTrigger
        o Has its clientComponent=true
        o Or looked up programmatically via a bean
        • Change the generated component ID such that is has a prefix in lowercase, drop the numeral suffix, and give the rest of the name a meaningful name in camelcase.

        You may also notice the new rule number. As the original rule was overloaded with conditions I've split rule 04029 into separately 04029 and 04064. Now rule 04029 deals with "all components should have IDs where permissible", and the new rule 04064 "a" and "b" that deal with the format of the ID.

        2) In addressing the two different versions of the new rule 04064 I've also included a small example of an inputForm based on the Departments table from the HR schema.

        In addition I've also included a section to detail the currently generated ID prefixes per component for reference purposes, approximately 83 components.

        Show
        chriscmuir added a comment - In addressing the first two abouts. 1) Yes, the guideline 04029 is suggesting all component IDs. Having discussed this again internally there is still two camps of thought, and it can be split between developers and QAs having different needs. To accomodate the two different view points, as I've done in the ADF Code Guidelines for one of the rules, I'll document two different versions of the rule "a" a new rule suited toward developers and "b" the original rule suited towards QA. I then leave the reader to decide which to choose. In discussing the IDs with internal development staff, the rule new rule "a" states rather than changing all IDs, there are certain circumstances where the ID should be changed. For documentation purposes that new rule and the circumstances are as follows: • [ADFng2-04064a] - Component ID format – For the majority of UI component IDs generated by JDeveloper leave the ID as that generated. However for any UI component that is: o Referred to via a partialTrigger o Has its clientComponent=true o Or looked up programmatically via a bean • Change the generated component ID such that is has a prefix in lowercase, drop the numeral suffix, and give the rest of the name a meaningful name in camelcase. You may also notice the new rule number. As the original rule was overloaded with conditions I've split rule 04029 into separately 04029 and 04064. Now rule 04029 deals with "all components should have IDs where permissible", and the new rule 04064 "a" and "b" that deal with the format of the ID. 2) In addressing the two different versions of the new rule 04064 I've also included a small example of an inputForm based on the Departments table from the HR schema. In addition I've also included a section to detail the currently generated ID prefixes per component for reference purposes, approximately 83 components.
        Hide
        Jan Vervecken added a comment -

        Thank you for the update Chris.

        The changes you suggest can help clarify naming guideline [ADFng1-04029].

        As can be found in "ADF Naming and Project Layout Guidelines v2.00" [1] :

        [ADFng2-04029] - Component must have IDs - All UI components defined in page and page fragments must have an ID if they support the ID attribute.

        [ADFng2-04064a] - Component ID format – For the majority of UI component IDs generated by JDeveloper leave the ID as that generated. However for any UI component that is:

        • Referred to via a partialTrigger
        • Has its clientComponent=true
        • Or looked up programmatically via a bean
          Change the generated component ID such that is has a prefix in lowercase, drop the numeral suffix, and give the rest of the name a meaningful name in camelcase.

        [ADFng2-04064b] - Component ID format - For all UI components change the JDeveloper generated ID to use the default component ID prefix in lowercase, drop the numeral suffix, and give rest of the ID a meaningful name in camelcase. However keep the generated UI component IDs short by abbreviating the name.

        regards
        Jan Vervecken

        Show
        Jan Vervecken added a comment - Thank you for the update Chris. The changes you suggest can help clarify naming guideline [ADFng1-04029] . As can be found in "ADF Naming and Project Layout Guidelines v2.00" [1] : [ADFng2-04029] - Component must have IDs - All UI components defined in page and page fragments must have an ID if they support the ID attribute. [ADFng2-04064a] - Component ID format – For the majority of UI component IDs generated by JDeveloper leave the ID as that generated. However for any UI component that is: Referred to via a partialTrigger Has its clientComponent=true Or looked up programmatically via a bean Change the generated component ID such that is has a prefix in lowercase, drop the numeral suffix, and give the rest of the name a meaningful name in camelcase. [ADFng2-04064b] - Component ID format - For all UI components change the JDeveloper generated ID to use the default component ID prefix in lowercase, drop the numeral suffix, and give rest of the ID a meaningful name in camelcase. However keep the generated UI component IDs short by abbreviating the name. [1] http://www.oracle.com/technetwork/developer-tools/adf/learnmore/adf-naming-layout-guidelines-v2-00-1904828.pdf regards Jan Vervecken
        Hide
        chriscmuir added a comment - - edited

        In reviewing this issue it looks like it is now complete. Next time I revisit this issue if there hasn't been follow up I shall close.

        Show
        chriscmuir added a comment - - edited In reviewing this issue it looks like it is now complete. Next time I revisit this issue if there hasn't been follow up I shall close.
        Hide
        chriscmuir added a comment -

        As per last comment, closing issue.

        CM.

        Show
        chriscmuir added a comment - As per last comment, closing issue. CM.

          People

          • Assignee:
            Unassigned
            Reporter:
            Jan Vervecken
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: