3 Replies Latest reply: Apr 1, 2013 3:46 PM by jsmith RSS

    why would one choose to go the FXML/Controller Route vs Straight FX Code???

    KonradZuse
      The only instance I have used FXML/Controller is when I was using SceneBuilder, and honestly it was more of a pain than to just hardcode things. I used to always use the Netbeans Gui Builder over just hard coding it, but FX is much easier to do things than Swing IMO.

      Scene Builder is also decent at the moment, and can only do a few things. I'm hoping it gets much better with 2.0, as well as the INTEGRATION into Netbeans for 3.0, which will happen in a couple of years tho.... So maybe then we will see some good Scene Builder use, but does that mean it will all be FXML when it's integrated? Maybe auto-generated FXML, who knows.

      The main point is, why use it? Is there a key use for it, or just a preferred method, as well as learning a new skillset?

      Edited by: KonradZuse on Apr 1, 2013 12:08 PM
        • 1. Re: why would one choose to go the FXML/Controller Route vs Straight FX Code???
          James_D
          From a purely practical viewpoint, you answered your own question by referring to SceneBuilder. FXML is much (much) simpler than Java, so it's relatively easy to create a tool that generates, and more to the point, parses FXML. So using FXML for layout will in the long run enable you to use a tool such as SceneBuilder later on, even if you choose to code the FXML by hand to begin with.

          I have to confess I haven't been overly impressed with SceneBuilder (yet); the only thing I miss from my days of Swing programming is Eclipse's WindowBuilder which was phenomenal. But it is still early days...

          There are a couple of other considerations, though.

          While it makes sense to use objects to represent the nodes in a scene graph, using methods to actually create the layout is a pretty bad fit in terms of language paradigms. A method implements an algorithm; it's a sequence of statements whose order is important. A GUI layout is a static state of affairs. In using Java to create a layout, your code looks like "put this in here, then put this in here, etc". In fact the order in which things are placed is often irrelevant; you can create the scene, create the root of the scene, create the children of the root of the scene, then add the children to their parents, and then put the root in the scene. Or you can add the root to the scene, then put the children in the parent. As long as objects are instantiated before their use, pretty much any ordering of the statements will work exactly the same way. This leads to a lack of standard coding techniques, and makes it really difficult to write tools such as SceneBuilder which can parse existing code.

          On the other hand, an XML-based language like FXML is ideal for representing a scene graph, as both are basically tree structures. To place child nodes inside a parent node, you simply define the child tags inside the parent tag. It's a much more natural fit.

          The other benefit is that using FXML forces you to use good programming practice in terms of separating the layout ("view") from the business logic ("controller"). In large projects this kind of separation of concerns makes the code far more maintainable. You can, of course, achieve this separation using Java instead of FXML but using FXML forces you into good practice.
          • 2. Re: why would one choose to go the FXML/Controller Route vs Straight FX Code???
            KonradZuse
            Yes, exactly, I agree.

            Yeah Scenebuilder, as I mentioned above, isn't all that good, but again it's still really new. I'm actually surprised there isn't a 2.0 beta out(maybe there is and we haven't found it yet..), but it has it's issues right now. You really cannot do all that much with it. I used it to make a LineChart and it only built the parent chart, and not the children lines within it. So I had to use all JavaFX code to do that, which IMO is pointless of the Scenebuilder, but yes again it's new, and lets see how it works out. I'm sure, knowing Oracle and the Netbeans Crew, when it gets to Netbeans Integration it will be full of features. FX 1.0 and 2.0 were HUGE differences :P. Have you ever used Netbeans? I used to use Eclipse, but then went over to netbeans because of more plugin support at first I believe, and the gui builder as well. Didn't really look into Eclipse gui builders, just thought there was none.

            I actually got into an argument with someone who uses Scala and they were talking about how "Java doesn't hold conventional coding practices, and boilerplate code blah blah blah" I just said that any language has it's boilerplates, and anyone can have bad coding practices, bad excuses. Like you did say some languages make you do it in a certain way, but if you know anything about design or how to be "neat" it works out. I mean I HATE cluttered code, I have everything organized how I like it, and that's how I go. It's easy to read for myself, and others who want to read it. I remember someone at my school telling me that they knew someone who was in the competition, and was good, but when he judges asked him to explain his code, because they couldn't understand it, neither could he haha. That's really bad though, but still. Anyone can be amazing with any language, or bad with any language, sometimes things matter, but hey for most people it's as long as you get the job done, but that usually is no bueno :P.

            Edited by: KonradZuse on Apr 1, 2013 12:20 PM
            • 3. Re: why would one choose to go the FXML/Controller Route vs Straight FX Code???
              jsmith
              I'm actually surprised there isn't a 2.0 beta out
              I don't think work has started on the 2.x branch of SceneBuilder yet.

              The latest SceneBuilder preview release (1.1 branch), is currently available from:
              http://www.oracle.com/technetwork/java/javafx/downloads/devpreview-1429449.html

              The 1.1 previews have much more functionality and wider platform support than the 1.0 release.