I just listened to the podcast about JavaFX and I thought I'd put down some thoughts I had about the discussion. I'm a long time Swing developer, and a Flex enthusiast. Flex is really like Swing in that it's a UI toolkit that fits over Actionscript. Flex also has a special compiler that takes MXML and translates it into Actionscript much like JSP is translated into a Servlet. In the end we're all just creating Actionscript. So I will use Flash, Flex or Actionscript interchangeably. Listening to the podcast it seemed like most of the participants weren't very adept at the innards of Flex/Flash which was somewhat frustrating since much of discussion was trying to compare JavaFX to these technologies.
Much of the discussion centered around calling Flex and C# a component toolkit. It was hard to understand what they meant by that because a component wasn't defined, and component is so overloaded it was hard to differentiate that from an plain old object. Especially since one of the participants kept saying Component != Visual Component. Well what is it then? How's that different that a plain old object? There was a thread about it in the forum, but that thread seemed to center on how callbacks were registered which I think is NOT exactly what makes these tool kits easier or cleaner than Swing or JavaFX. Closures and function pointers help in so much that you don't have to create Interfaces and statically typed Events to create custom callbacks, but that alone doesn't make a productive toolkit. Also the discussion that inheritance is the wrong and composition should be favored is a red herring as well. Flex and Flash are inheritance heavy. Very deep component hierarchies so that's not it either. Composition IS important, but it's not the driver of their success as a toolkit. Even in Flex there are times where you have to subclass. In fact every time you create a MXML file it subclasses your top level Component you defined in the XML. Very Swing-esque. There's nothing inherently wrong with Java that keeps it from being a decent UI toolkit. The language isn't holding it back. Actionscript looks a heck of a lot like Java in fact I sometimes think I am in Java. And C# is more similar to Java than not. As languages they are mostly equivalent. Yes having closures would help, but having just a simple genericised EventListener interface that's used uniformly would be just as good. All events in Flex take a function( event : Event ). So what works in Actionscript where Java doesn't? I have to say it's the event model that Actionscript employs that makes it better than Java's tool kits. Events in Actionscript are open. Any class can send and receive events. Swing is a closed model in that only Swing components can participate in the events. Dispatching events into the event stream is as simple as calling dispatchEvent() in flash. In Flex/Flash plain old Actionscript objects can participate in the event process. Any component can dispatch and event into the flow by extending EventDispatcher, or implementing IEventDispatch interface and hooking yourself up using a special constructor of EventDispather for composition. Event dispatch exists outside of the UI model so you can easily create a model layer (i.e. no UI components) that dispatches events, and a UI layer that dispatches events and use a controller layer to listen to both and redirect between the layers. This is a really important point because so often in Swing we'd use events in the UI and strange convoluted threading gymnastics to get back to the UI. Just simply dispatching an event from the model layer would have been so much easier to notify the UI. Event bubbling. Flex/Flash has the concept of event bubbling. Bubbling helps alleviate the performance issues because events can be defined to bubble or not at event creation time. Swing used to bubble all events in 1.0, but that got neutered when they had performance problems. That was a serious mistake. I think just introducing the concept of events that bubble or don't could have kept the old model around with the benefit of performance. Event bubbling allows outside clients to listen for possibly low level events from the outside without having to dig around inside a component to find the target. Think of it like how OO encapsulates data structures hiding those details from the outside world. Event bubbling allows UI components to hide the details of how a UI is put together so the outside clients don't care what the UI actually looks like. Bubbling means that I can trap button clicked, or table row selection events in my UI classes, then dispatch Application centered events like Podcast.Added event, or Podcast.Deleted events and they will bubble up to the Controller. Getting out of the low level UI events means that my UI components are portable in my application. Something that's very hard in Swing. Bubbling happens through the component tree automatically which is very nice since events are forwarded from child to parent and vice a versa for DisplayObjects. When you are outside of that they aren't automatically forwarded. Events act the same. Registering listeners, and dispatching are the same across any event, and receiver. How those events are routed is the same every time. In Swing we constantly were hand rolling our own events with different registration methods. Every component's events were separate and different. Different way of dispatching, different registering, different management. Flash events are uniform. This enables event forwarding, bubbling, phases, and canceling to work as you'd expect. It's the same no matter what component we are talking about. This uniform approach gives us our event system. Events use strings to uniquely identify themselves. In Swing we used class types which meant we had to create special classes/interfaces to define different events that slows us down. Reusing these pieces is confusing because we can't differentiate between two StateChanged events. The event type string does this for you and is much faster than create yet another class. While in Flash you can use separate Event classes for each type of event you don't have too. You can reuse events or use DynamicEvent for a time saver. MXML is the layout language. Actionscript is the logic language. MXML is XML so it's easy to parse and easy to use as a layout language. In Swing we so often would create components in methods, and spend 100's of lines just laying out crap. You can do this in Actionscript too, and it's just as verbose as Java. So often just wanted a simple XML file that i could put Swing components in and use IDs to reference those components. It would have cleaned up my UI so much more, and seperated layout from logic. And with an XML file it's easy to parse and create tools that could help me with that visually. Simpler layout rules. Flex doesn't have LayoutManagers. Swing's layout managers are a blessing and a curse. And really the only blessing came from outside of Swing because the default layout managers were, and still are plain awful. Plus layout managers made it impossible to create decent WYSIWYG layout tools. Flex has simple rules for layout. Absolute, or container managed. Container managed is simple horizontal or vertical stacking, but not all containers support this. Absolute can be specified as left, right, top, and bottom from the parent's edges, horizontal and vertical displacement from the center, or true x, y, width, height. This actually works quite well and is easy to understand. It's also easy to create WYSIWYG tools out of it too because the rules are simple. With Flex 4 layout managers are being introduced. I think this is ok, but it will hurt the WYSIWYG layout tools. And Adobe has yet to explain how that's going to work. The idea that you can use Flash Editor has been bantered around, but it's unclear how well it will work. All they've shown is look here's a button. Not good enough. Flex is skinnable without the need to code. Flex has a CSS skinning facility that any component can utilize to externalize colors, fonts, images, etc. Swing wrapped this into code which meant changing these things was a nightmare. Flex is moving away form CSS in Flex 4 to more dynamic skinning language similar to MXML which is awesome, but it's more overhead for simple things than the simple CSS solution. But they are way ahead of any toolkit I've seen out there in thinking about how you create very customizable components quickly without rewriting your own customized JList or JTable. Much of this was pioneered by the Degrapha project which is an awesome project. Finally Flex data structures work with their UI toolkits out of the box. Why don't we have a ListModel that implements the List interface yet? Why do Swing models suck so hard that you are constantly reinventing them for every project? Flex got it right where ArrayCollection and ICollection just work. JavaFX must be better in this area. I will be positive about JavaFX's future in that. Actionscript, while a nice language, is alone. It's only in the Flash platform, and it's not as well thought out as Java. You can't load native code, you can't easily interact with existing pieces of code. You can't share code between UI and server. Actionscript is only for Flash. You can't redistribute the flash platform. So I have to implement algorithms at least twice, and if I go mobile more than that. Java is a language first with lots of thought given to making it portable to lots of environments. The JVM can run anywhere we want. JavaFX means to me the ability to write slick UIs using Java's ubiquity if it matures correctly. That's JavaFX clear win over the Flash platform right now. It's all how well Sun and the community can execute on that vision. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
