> JavaFX supports composition via Mixin's and traditional inheritence.
Mixin's are great. That's very encouraging to see.
I hear a lot of discussion and promise from databinding. Particularly
that data binding with enable the same things event bubbling will. It
will NOT. Flex also has data binding, and it's a bit of curse and a
blessing. Databinding is helpful, but it can be a serious performance
problem if overused. I think the sound from the forum is that
databinding might be promising too much.
I would also disagree data binding can provide you the component model
you're after. I think I understand or at least can guess what a
component model might be. as Joe sees it. A component is a discrete
system that is composed of one or more objects. It has a single
interface or feels like a single object, but it's internals might be
much more than that: Components composed from other components. I
would go so far as to say that it participates in event dispatching in
that it dispatches it's own events, and can respond to events from
other components. A component is not that different than our basic UI
classes.
I think I did a better description of what a component might be in
another email so I'll refrain from re describing it here. Event
bubbling and binding are two separate things, and I don't think
binding will allow you to do the same thing as event bubbling can for
you. I hope my other email will make that clearer.
Databinding just allows you to skip explicit event registration
listening/handling. It's syntatic sugar for
addListener('property', function( event : Event ) : void {
myObject.property = event.property;
}
Bubbling is about default event routing. It's not the same thing, and
I think if you could cleverly route events using bubbling you'll find
it cumbersome eventually.
Charlie
On Sep 22, 8:33 am, Steven Herod <[email protected]> wrote:
> > 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
-~----------~----~----~----~------~----~------~--~---
