Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 1.0-SNAPSHOT
    • Labels:
      None
    • Environment:

      all

      Description

      Hi,
      I have attached a file with a few changes to adapt to build 42 of JavaFX and to make MigPane more consistent with the other layout panes. The changes are:

      • Compatible with build 42 of JavaFX 2.0 beta.
      • Renamed "addChild" to just "add" like in all other layout panes.
      • Added a "clearConstaints" method.
      • Removed TextBox (which doesn't exist anymore) and added TextField to node type test.
      • Store CC instance instead of String in node.properties.
      • Adjusted "private static final String CC_KEY = "MigPane_CC";" to standard layout pane naming rules.
      • Remove "migChildren". Instead an event handler is attach to "children" to catch the add and remove events.
        Nodes can now be added directly to "children" as it is done by all other layout panes.
      • Due to the changes with "children" it is not possible anymore to distinguish between managed and unmanaged
        nodes in the previous way. But this was a error-prone and confusing concept anyway. The same effect
        can be achieved by using "new CC().external()" instead. Affects test 4 and 5.
      • Removed two of the internal lists because the same effect can be achieved more easily by attaching the
        relevant information directly to the nodes.

      I have further planned a change to make it possible to change the constraints of a node AFTER it has
      been added to the MigPane but I do not yet know when I will have the time for that.

      Michael

        Activity

        Hide
        tbee added a comment - - edited

        I've already migrated to b42 (JFXtras as well) and release it. When will they finally stop messing with the API?

        I'm not sure I agree with the addChild() -> add() change. This has to do with the somewhat strange construct JavaFX uses now: getChilderen().add()
        Since we cannot really override what, the most logical rename would be addChilderen(), so I went for addChild().
        But since the JavaFX team seams to be less puristic about their naming conventions and introduced a simple add().
        Hm.

        The other changes seem very interesting. The managed and unmanaged nodes again are a direct result of the getChilderen().add(). I'm not sure if I want that to be blocked or not. It also introduces a powerful concept where you can under or overlay the managed nodes. Maybe using a stack layout would be cleaner, but I'm not out on that yet.

        I would give you committer rights on the project, but then I would like to exchange opinions on changes to the code base before you make them.

        Show
        tbee added a comment - - edited I've already migrated to b42 (JFXtras as well) and release it. When will they finally stop messing with the API? I'm not sure I agree with the addChild() -> add() change. This has to do with the somewhat strange construct JavaFX uses now: getChilderen().add() Since we cannot really override what, the most logical rename would be addChilderen(), so I went for addChild(). But since the JavaFX team seams to be less puristic about their naming conventions and introduced a simple add(). Hm. The other changes seem very interesting. The managed and unmanaged nodes again are a direct result of the getChilderen().add(). I'm not sure if I want that to be blocked or not. It also introduces a powerful concept where you can under or overlay the managed nodes. Maybe using a stack layout would be cleaner, but I'm not out on that yet. I would give you committer rights on the project, but then I would like to exchange opinions on changes to the code base before you make them.
        Hide
        tbee added a comment -

        Ok. Interesting change. So the question is: do we encapsulate all administration in MigPane, so no one can mess with our data, or do we expose some of our internal administration via the (re)use of the node's properties with the risk of people fiddling with it? I see this as a inheritance vs composition discussion, both have their advantages. Reuse especially when it comes to keeping the administration clean of memory leaks.

        I must say that I'm not leaning towards exposing layout information in a node's properties ATM. Listening to the getChilderen() collection and updating the internal administration is wise. Maybe the use of SoftReferences as well... But that would make the whole implementation much more complex. Hm.

        Show
        tbee added a comment - Ok. Interesting change. So the question is: do we encapsulate all administration in MigPane, so no one can mess with our data, or do we expose some of our internal administration via the (re)use of the node's properties with the risk of people fiddling with it? I see this as a inheritance vs composition discussion, both have their advantages. Reuse especially when it comes to keeping the administration clean of memory leaks. I must say that I'm not leaning towards exposing layout information in a node's properties ATM. Listening to the getChilderen() collection and updating the internal administration is wise. Maybe the use of SoftReferences as well... But that would make the whole implementation much more complex. Hm.
        Hide
        tbee added a comment -

        I've gotten some feedback from other high profile Java people and the consensus seems to be that it is preferable not to expose layout information.

        Show
        tbee added a comment - I've gotten some feedback from other high profile Java people and the consensus seems to be that it is preferable not to expose layout information.
        Hide
        tbee added a comment -

        Adopted some suggestions, but the biggest part involving moving the CC into the node's properties is not my preferred solution.

        Show
        tbee added a comment - Adopted some suggestions, but the biggest part involving moving the CC into the node's properties is not my preferred solution.
        Hide
        Michael Paus added a comment -

        Well, of course my contribution was only meant as a suggestion and you are of course free to do what you like with them.

        My goal was to make MigPane as consistent with the other layout panes, most notably GridPane, as possible. Therefore the name change of addChild and the removable of the migChildren. I find it highly inconsistent if people cannot use getChildren().add in the same way as they expect it. Under- and overlays can be achieved easily by other means and the current possiblity is just a confusing duplication of these. Maybe you should talk with your high profile Java people about this aspect too

        The other issues are implementation details for which I don't have any clear preference.

        Show
        Michael Paus added a comment - Well, of course my contribution was only meant as a suggestion and you are of course free to do what you like with them. My goal was to make MigPane as consistent with the other layout panes, most notably GridPane, as possible. Therefore the name change of addChild and the removable of the migChildren. I find it highly inconsistent if people cannot use getChildren().add in the same way as they expect it. Under- and overlays can be achieved easily by other means and the current possiblity is just a confusing duplication of these. Maybe you should talk with your high profile Java people about this aspect too The other issues are implementation details for which I don't have any clear preference.

          People

          • Assignee:
            tbee
            Reporter:
            Michael Paus
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: