adfemg
  1. adfemg
  2. ADFEMG-63

Bug 7502373 : PAGEDEF FILES NOT CREATED UNDER PAGEDEFS PATH FOR JSPX CREATED IN SUB-DIRECTORY

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Labels:
      None

      Description

      hi

      As pointed out in ...
      Bug 7502373 : PAGEDEF FILES NOT CREATED UNDER PAGEDEFS PATH FOR JSPX CREATED IN SUB-DIRECTORY
      ... and some OTN forum threads [1], Page Definition files can end up "all over the place"
      (also illustrated by http://www.consideringred.com/files/oracle/img/2011/PageDefLocations.png ).

      But bug 7502373 currently has "Status 32 - Not a Bug. To Filer", so it does not look like this behaviour will be improved in the context of this bug 7502373.

      • (q1) Why does bug 7502373 have "Status 32 - Not a Bug. To Filer"?
      • (q2) Do any other bugs (or enhancement requests) exist that try to improve (the consistency of) the location where Page Definition files are created?

      A related suggestion was done in JIRA issue ADFEMG-60 .

      many thanks
      Jan Vervecken

        Activity

        Hide
        chriscmuir added a comment -

        In answer to q1 the last text in the bug:

        @ the behavior reported by this bug is 'as expected' we realize the change in
        @ naming pattern is a little surprising, but this was the behavior requested by
        @ our internal applications teams because it lends itself to a package-matching
        @ approach where the pagedef file name matches the jsf file location.

        CM.

        Show
        chriscmuir added a comment - In answer to q1 the last text in the bug: @ the behavior reported by this bug is 'as expected' we realize the change in @ naming pattern is a little surprising, but this was the behavior requested by @ our internal applications teams because it lends itself to a package-matching @ approach where the pagedef file name matches the jsf file location. CM.
        Hide
        Jan Vervecken added a comment -

        Thanks for your reply Chris.

        Given that on Project Properties in JDeveloper the ADF Model panel has a "PageDef sub-package" to be configured, which is documented as "... a name for the package that will contain your project's page definition files ...", it seems also fair to "expect" Page Definition files to end up there (one way or another).

        • about "... a package-matching approach where the pagedef file name matches the jsf file location"
          If that is what is required (requested by applications teams) it looks like it can also be implemented in the configured "PageDef sub-package".

        Any feedback on question (q2)?

        regards
        Jan Vervecken

        Show
        Jan Vervecken added a comment - Thanks for your reply Chris. Given that on Project Properties in JDeveloper the ADF Model panel has a "PageDef sub-package" to be configured, which is documented as "... a name for the package that will contain your project's page definition files ...", it seems also fair to "expect" Page Definition files to end up there (one way or another). about "... a package-matching approach where the pagedef file name matches the jsf file location" If that is what is required (requested by applications teams) it looks like it can also be implemented in the configured "PageDef sub-package". Any feedback on question (q2)? regards Jan Vervecken
        Hide
        chriscmuir added a comment -

        In answering q2, it's a difficult thing to search on as the terms "pageDef", "location", "path", "package" get a large amount of hits. From my rudimentary searches I didn't find a significant match .... but the Oracle Support interface blocks more than 200 results so there could be one hiding somewhere.

        I'd suggest if you do want a change, just lodge an ER anyway, and let development decide if it's a duplicate.

        CM.

        Show
        chriscmuir added a comment - In answering q2, it's a difficult thing to search on as the terms "pageDef", "location", "path", "package" get a large amount of hits. From my rudimentary searches I didn't find a significant match .... but the Oracle Support interface blocks more than 200 results so there could be one hiding somewhere. I'd suggest if you do want a change, just lodge an ER anyway, and let development decide if it's a duplicate. CM.
        Hide
        Jan Vervecken added a comment -

        Thanks for your reply Chris.

        • about (q2)
          • Thanks for trying to search. Indeed finding good search terms for this is not easy.
        • about "I'd suggest if you do want a change, just lodge an ER anyway ..."
          • Not sure in which terms best to request an enhancement, maybe like
            "Can (optional) features be introduced that allow to avoid having to move Page Definintion files?"
            or more like
            "Can (optional) features be introduced that allow to have all Page Definition files in the configured "PageDef sub-package" or sub-packages thereof?"
            or something else?
            Suggestions anyone?

        thanks
        Jan Vervecken

        Show
        Jan Vervecken added a comment - Thanks for your reply Chris. about (q2) Thanks for trying to search. Indeed finding good search terms for this is not easy. about "I'd suggest if you do want a change, just lodge an ER anyway ..." Not sure in which terms best to request an enhancement, maybe like "Can (optional) features be introduced that allow to avoid having to move Page Definintion files?" or more like "Can (optional) features be introduced that allow to have all Page Definition files in the configured "PageDef sub-package" or sub-packages thereof?" or something else? Suggestions anyone? thanks Jan Vervecken
        Hide
        chriscmuir added a comment -

        One thing to keep in mind with any solution you propose, be mindful that JDev needs to be careful about the size of the package structure it creates + the pageDef file name, as some operating systems have a limit of 255 characters to the relating file/directory path. If memory serves me correctly, Win XP suffers from this limitation, and XP is still a supported platform for JDev.

        CM.

        Show
        chriscmuir added a comment - One thing to keep in mind with any solution you propose, be mindful that JDev needs to be careful about the size of the package structure it creates + the pageDef file name, as some operating systems have a limit of 255 characters to the relating file/directory path. If memory serves me correctly, Win XP suffers from this limitation, and XP is still a supported platform for JDev. CM.
        Hide
        Jan Vervecken added a comment -

        Thanks for your reply Chris.

        • about "... JDev needs to be careful ... as some operating systems have a limit of 255 characters to the relating file/directory path ..."
          • Wouldn't that be a limitation of the operation system, rather than a limitation of a tool like JDeveloper? Those using such operation system should have the option to use package/directory names that fit within the limitations of the environment they work in, not?

        Any suggestions for my question on how to best phrase this enhancement request, more general or more specific?
        (There have been enhancement requests "rejected" because those reviewing it focused on a suggested solution, rather than the "goal" of the enhancement (see ADFEMG-34).)

        thanks
        Jan Vervecken

        Show
        Jan Vervecken added a comment - Thanks for your reply Chris. about "... JDev needs to be careful ... as some operating systems have a limit of 255 characters to the relating file/directory path ..." Wouldn't that be a limitation of the operation system, rather than a limitation of a tool like JDeveloper? Those using such operation system should have the option to use package/directory names that fit within the limitations of the environment they work in, not? Any suggestions for my question on how to best phrase this enhancement request, more general or more specific? (There have been enhancement requests "rejected" because those reviewing it focused on a suggested solution, rather than the "goal" of the enhancement (see ADFEMG-34 ).) thanks Jan Vervecken
        Hide
        duncanmills added a comment -

        I can tell you now that there is very little chance of this change request being acted upon. We actually changed to the current behaviour by default fairly early on in the 11g cycle because of path length issues that the Fusion Application development process ran into.
        To explain here's the scenario:

        1) You decide on a page fragment naming structure relative to HTML_ROOT maybe encoding product, component, subcomponent into that naming. This reflects your overall package structure that is used within the Java source as well. Let's use <HTML_ROOT>/oracle/demo/bindingdemo/view/taskFlow1 as an example
        2) You have your similar Java package naming for the project and this is the default project setting
        3) Now if we were to always respect the pagedef setting for pages in subdirectories the path to the pagedef would become:

        /oracle/demo/bindingdemo/view/taskFlow1/pageDefs/oracle/demo/bindingdemo/view/taskFlow1/page1PageDef.xml

        Hopefully you start to appreciate the problem - we've suddenly doubled the path depth for no real reason and thing actually become harder to find and we're dealing with much more unwieldy pageDef identifiers in the cpx

        We're not going to put in a behaviour like this which would break existing clients. The reality is that packaging and naming standards do vary so much that it's hard for the IDE to generalize a location and it's probably a mistake to try. A better enhancement would be just to remove that PageDefs Subpackage option all together from the project preferences to reduce the confusion if that's a big deal?

        Show
        duncanmills added a comment - I can tell you now that there is very little chance of this change request being acted upon. We actually changed to the current behaviour by default fairly early on in the 11g cycle because of path length issues that the Fusion Application development process ran into. To explain here's the scenario: 1) You decide on a page fragment naming structure relative to HTML_ROOT maybe encoding product, component, subcomponent into that naming. This reflects your overall package structure that is used within the Java source as well. Let's use <HTML_ROOT>/oracle/demo/bindingdemo/view/taskFlow1 as an example 2) You have your similar Java package naming for the project and this is the default project setting 3) Now if we were to always respect the pagedef setting for pages in subdirectories the path to the pagedef would become: /oracle/demo/bindingdemo/view/taskFlow1/pageDefs/oracle/demo/bindingdemo/view/taskFlow1/page1PageDef.xml Hopefully you start to appreciate the problem - we've suddenly doubled the path depth for no real reason and thing actually become harder to find and we're dealing with much more unwieldy pageDef identifiers in the cpx We're not going to put in a behaviour like this which would break existing clients. The reality is that packaging and naming standards do vary so much that it's hard for the IDE to generalize a location and it's probably a mistake to try. A better enhancement would be just to remove that PageDefs Subpackage option all together from the project preferences to reduce the confusion if that's a big deal?
        Hide
        Jan Vervecken added a comment -

        Thanks for your reply Duncan.

        Sure, I appreciate that some naming choices could get you into trouble (but maybe that applies to many other things that need a name, if you choose too long values).

        What about giving JDeveloper users a choice between the current approach (apparently preferred by the Fusion Application development process), and something else that allows to avoid multiple top-level packages with Page Definition files (which could fit in many naming standards and could avoid moving of Page Definition files)?

        regards
        Jan Vervecken

        Show
        Jan Vervecken added a comment - Thanks for your reply Duncan. Sure, I appreciate that some naming choices could get you into trouble (but maybe that applies to many other things that need a name, if you choose too long values). What about giving JDeveloper users a choice between the current approach (apparently preferred by the Fusion Application development process), and something else that allows to avoid multiple top-level packages with Page Definition files (which could fit in many naming standards and could avoid moving of Page Definition files)? regards Jan Vervecken
        Hide
        Jan Vervecken added a comment -

        fyi

        Some aspects pointed out in this JIRA issue ADFEMG-63 seem to make more sense in the context of naming guidelines like [ADFng1-03021] and [ADFng1-03022], about "the directory structures and packages to use for the bounded task flows and their relating objects", in the "ADF Naming and Project Layout Guidelines v1.00"
        at http://www.oracle.com/technetwork/developer-tools/adf/learnmore/adf-naming-layout-guidelines-v1-00-1897849.pdf

        regards
        Jan Vervecken

        Show
        Jan Vervecken added a comment - fyi Some aspects pointed out in this JIRA issue ADFEMG-63 seem to make more sense in the context of naming guidelines like [ADFng1-03021] and [ADFng1-03022] , about "the directory structures and packages to use for the bounded task flows and their relating objects", in the "ADF Naming and Project Layout Guidelines v1.00" at http://www.oracle.com/technetwork/developer-tools/adf/learnmore/adf-naming-layout-guidelines-v1-00-1897849.pdf regards Jan Vervecken
        Hide
        chriscmuir added a comment -

        On this clarification, I'm willing to include a section in the Guidelines of alternatives approaches to laying out the components, as long as somebody defines the complete set of guidelines and has tested it in a multi-application-workspace with ADF Libraries to detect naming collisions. This would be with an eye to providing readers a choice.

        Thanks,

        CM.

        Show
        chriscmuir added a comment - On this clarification, I'm willing to include a section in the Guidelines of alternatives approaches to laying out the components, as long as somebody defines the complete set of guidelines and has tested it in a multi-application-workspace with ADF Libraries to detect naming collisions. This would be with an eye to providing readers a choice. Thanks, CM.
        Hide
        Jan Vervecken added a comment -

        Thank you for the update Chris.

        • about "... as long as somebody defines the complete set of guidelines and has tested it ..."
          • Currently I don't have the time or experience to define such alternative, and sufficiently generic, guidelines.

        regards
        Jan Vervecken

        Show
        Jan Vervecken added a comment - Thank you for the update Chris. about "... as long as somebody defines the complete set of guidelines and has tested it ..." Currently I don't have the time or experience to define such alternative, and sufficiently generic, guidelines. regards Jan Vervecken
        Hide
        chriscmuir added a comment -

        In looking at the history of this issue, besides the closed bug 7502373, I do not see any other ERs or bugs logged against this issue. If within a week there hasn't been an update to this issue I'll close it.

        Show
        chriscmuir added a comment - In looking at the history of this issue, besides the closed bug 7502373, I do not see any other ERs or bugs logged against this issue. If within a week there hasn't been an update to this issue I'll close it.
        Hide
        Jan Vervecken added a comment -

        Thank you for the update Chris.

        • about "What about giving JDeveloper users a choice between the current approach (apparently preferred by the Fusion Application development process), and something else that allows to avoid multiple top-level packages with Page Definition files (which could fit in many naming standards and could avoid moving of Page Definition files)?"
          • Without an answer to this question, if I ever come up with a related enhancement request (that has a chance to be considered) I will create another issue.
            Now closing this JIRA issue ADFEMG-63.

        regards
        Jan Vervecken

        Show
        Jan Vervecken added a comment - Thank you for the update Chris. about "What about giving JDeveloper users a choice between the current approach (apparently preferred by the Fusion Application development process), and something else that allows to avoid multiple top-level packages with Page Definition files (which could fit in many naming standards and could avoid moving of Page Definition files)?" Without an answer to this question, if I ever come up with a related enhancement request (that has a chance to be considered) I will create another issue. Now closing this JIRA issue ADFEMG-63 . regards Jan Vervecken

          People

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

            Dates

            • Created:
              Updated:
              Resolved: