Good point Josh! I totally forgot about Lifecycle model! Another big improvement over Swing.
All components have a lifecycle model, and how properties of those objects are bound to the UI, UI elements are constructed, and how changes to those properties are propagated back to the UI controls. Flex handles this because of how MXML is put together. Think about it like this. Say you wanted to construct a UI component, but you couldn't do it in the constructor. Or think of it like you don't want to pass all the data in the constructor. PodcastView view = new PodcastView(); view.setModel( new PodcastModel() ); view.setImage( new Icon() ); view.setLoginName( "Charlie" ); view.setPassword( "JavaFX" ); ui.add( view ); At what point does the toolkit create the UI and bind those changes into the UI controls created in PodcastView? In Swing this was always a problem because you typically created controls in constructor, then tried to manage when properties changed update those. I know some controls (JTable) allowed you to do this, but it was very much hand rolled, and not every component did it the same way or if at all. When you wrote you own component it was too cumbersome to follow this model, or lack thereof, so typically things were constructed once and never altered much. Flex provides a way in which every developer can handle this for any component created. Actually constructing the UI elements isn't done in the constructor. There is a callback createChildren() that actually constructs the children. And that means those setters in my example would need to hold onto those values until commitProperties() is called. Inside the commitProperties() method you bind those values into the UI elements in your component. Charlie On Sep 22, 1:28 am, Josh McDonald <[email protected]> wrote: > As a Java guy who's been writing Flex for a living for the last two years, > I'm often cursing the fact that I'm too far away to contribute to the > various posse meetups that touch on the subject of "RIAs". > > I'd like to add a few additional points to Sasperilla's comparison. But > before I do, I'll add this disclaimer: > > Everything I'm complaining about may in fact exist. But I follow Java and > Flex news, blogs, podcasts, etc fairly thoroughly. If I don't know about it, > nobody does. And if you're working at Sun on this and keeping it a secret, > your boss is risking his own job, this stuff needs to get out there and get > mindshare. If *Adobe* is schooling you on OSSing their platform, you need to > sort some shit out. > > 1. Bindings > > I've no idea how the bindings work in JavaFX, and that's the problem. In > Flex they're well documented, they use the built-in Event system for > updates, and there's an AS3 API to programmatically create them, all of > which meaning that they can be used in pure AS3 code that doesn't touch > MXML. We need to be able to hook into JavaFX bindings from Java (and Scala, > and Clojure, and...). And not only that, we need to do it without jumping > through hoops made of glass that'll shatter with every version. This would > be a start, hopefully allowing the practice of binding to "bleed out" into > Java and other JVM languages. > > 2. The component lifecycle > > There's a *lot* of questionable decisions represented in the mx.* hierarchy. > But those decisions are documented, along with a standard lifecycle of > instantiation, child-creation, and invalidation/validation (of the > components I mean, not input). This you can see at work in the many existing > components, and makes a good pattern to use when creating your own custom > components. > > This is probably what JavaFX needs the most right now in order to compete. > Some may say it's a lack of components; but I say that the lack of a > sanctioned and documented component model and lifecycle is what's stopping > people from building the components we're missing. > > 3. A solid component + skin pattern > > Flex 2/3 had many issues, but the wide range of styles was a good start. The > Spark architecture in Flex 4 has drastically reduced the skin properties > that can be styled using CSS, but at the same time is a giant step forward > in separation of behaviour and presentation. Everything I've seen from > JavaFX is "let's turn 4 state images into a button". This isn't skinning, > it's Visio. Can the scene graph even do a "9-slice scale" on a node? If not, > why not? If so, why's it so hard to find? > > Like I said, all this may exist, but it's not "out there" being seen. > Everything I'm ranting about is because I want to see better tools to work > with. I love Flex, and Player's scene graph is pretty good, but the AVM2 > sucks. Rescue me from it! > > I know the JavaFX team may be small. So open more stuff, and we can help. > When you don't have a competitive advantage (and let's face it, JavaFX and > SL are tied for a distant second), keeping platform secrets doesn't help. > > </rant> > > -Josh > > 2009/9/22 sasperilla <[email protected]> > > > > > > > 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 > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
