> 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.
Closures are backed in to Java FX.
> 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.
JavaFX supports composition via Mixin's and traditional inheritence.
> 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.
I suspect the data binding capabilities of JavaFX may provide similiar
functionality here.
> 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.
Not sure about this, I know I'd like keyboard and mouse events to
automatically bubble up through the scene graph, but not sure if it
does it in 1.2
> 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.
Again, data binding probably handles this stuff in JavaFX, you might
bind to the 'selectedIndex' property of the ListView component.
> 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.
> 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.
JavaFX is a single language for layout and code/logic. Horses for
courses, personally I found a big mismatch between MXML and
ActionScript functionality (like the web services functionality). In
theory you could do the same thing using both techs, but they weren't
actually equivalent in the way they behaved.
And of course, in JavaFX, you can back off to plain old Java when
needed.
> Simpler layout rules. Flex doesn't have LayoutManagers. Swing's
Layout sucks in JavaFX right now. JFXtra's offers some assistance
here with a Grid and MigLayout layout helpers, but its a priority I
believe for the team.
> 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.
Interesting to hear that they are moving away from CSS. JavaFX offers
CSS skinning and an option to provide your own Skin{} class which can
provide a custom rendering option for something like a button or a
list view.
I don't find it particularly well described in the docs, but it seems
powerful.
> 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.
There aren't enough complex controls in JavaFX to know how this is
going to be handled. Josh? :)
> 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.
Absolutely, and that's when Flex I think, might be screwed in many
regards, inside that walled garden you can do things, but ....
well.... you know.
Maybe the brave new world of RIA's and cloud means you don't need all
this stuff, but at least my JavaFX app can load that excel
spreadsheet, create a local database, create a PDF and then send an
JMS message today because of the interoperability with Java
(Okay, I might be totally nuts to do that, but you know... the options
there :)
> 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. ...
Well, we all hope (I know I am).
>From what I've seen over the past 10 months of working with JavaFX is
that
1. It was initially quite immature
2. It's rapidly improving
3. The guys at Sun seem to 'get' it, and are working their butts off
to make it work.
4. Version 1.3 might be the tipping point for 'real' apps - both with
controls and performance
5. Java 7 (JDK 1.7), Jigsaw (whatever you wanna call it) might be the
thing that gets it to the Flash level startup times. <- That
statement is a statement of pure faith and hope.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
