Hi Borek. Thanks for your thoughts. They are very much appreciated. And for what it's worth, on a purely technical level, I agree with you, Microsoft has done a very nice job in the architecture of their framework.
Let me respond to a few comments. 1) Actually, no, I think you were right when you said 'WPF.' For both .NET/3 and Flex, the serialization languages (XAML, MXML) are very thin syntaxes on top of complex frameworks. In both cases, most of the functionality you're looking at is framework functionality, not language functionality. It's similar in my mind to how many people conflate the language javascript with the library of DOM and other apis provided by the browser (i.e., many desktop tools use javascript as a scripting language, which helps developers learn to script them, but learning a language is not the hard part...it's how to use the functionality in the APIs that's difficult). 2) To that point, you're right that performance isn't really an issue when you're discussing a serialization format. MXML is already very capable today of doing the kind of composition we're discussing here (case in point: Doug was able to write a component that uses the composition feature of MXML). It's the performance cost of a framework that supports that level of abstraction and flexibility that we're concerned with. 3) It's worth pointing out that some of your arguments below focus specifically on the components available out of the box with the frameworks (i.e., the button scenario). For example, for a new 3rd party component, you have to distribute and maintain a separate component in WPF just as you with Flex. So in many respects (not all, I know), the comparison boils down to what's available out of the box vs. what the platform enables the community to build and provide. I'm not trying to trivialize that difference...yes, having it available out of the box is a big plus. 4) Re: complexity: my comment is based on my previous usage of WPF. In my experience, while very basic usage of both technologies is comparable in terms of markup complexity, more complex features tend to balloon your markup in XAML. I also believe that both flex and WPF have a 'cliff' you walk off when you cross over a certain level of complexity. From my experience, it takes longer to get to that cliff in WPF (i.e., you can do more out of the box in just markup), but once you get there, it's a much bigger cliff. Put more simply, my experience was that writing a good custom component is much harder in WPF. But I'm sure my focus when working with WPF has been different from yours, and I think this is as much a matter of opinion and personal experience as anything else, so I can't argue too strongly that I'm right and you're wrong J 5) Rest assured, we want to see MXML and flex improve further as well, and power and flexibility is one key area where we want to continue to evolve. But we need to continue to adopt a pay as you go model...the power and flexibility needs to be there, but not at the expense of developers and use cases that have no need for them. We will continue to balance flexibility and power against performance, ubiquity, simplicity, familiarity and other concerns. All so that flex applications continue to be something that the broad populations of developers can create, and the broad population of end users can use. Ely. From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of borekbe Sent: Friday, June 01, 2007 4:19 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Really complex buttons (aka what WPF got right) Hi Ely It's great to hear directly from a Flex developer! I would like to take a chance and share my views while you listen :) I must stress again that I'm fairly new to Flex but maybe that can be a good thing now - I can see all the problems very clearly because I often don't have enough experience to find adequate solutions. Here are few assorted comments that expand on our discussion. 1) I used WPF in the title where I should have used XAML instead, my apologies. But I hope it was obvious what I meant from the code sample. 2) I really don't know why is this but both you and Aral Balkan (in a blog post I saw the other day) seem to suggest that MXML is more "Notepad-friendly" than XAML. In my personal experience, from the application developer point of view, these formats are in almost 1:1 relationship when you leave aside the fact that you can express vector graphics and many other things, like 3D or text documents, in XAML. If all you need are layout containers, form controls, buttons, assets and other common things, you'll end up with almost the same XML markup whichever technology you use. With one exception - XAML allows for much better composability as was pointed in the Button example before. 3) I'm glad you brought up the concepts of "power" and "simplicity" which is very important in many aspects of software development. What Microsoft achieved with XAML is something like a miracle in my eyes - they achieved *both*. Please compare the Button example that I posted before with (the truly excellent) CanvasButton component [ http://dougmccune.com/blog/2007/06/01/new-component-canvasbutton-added-t o-flexlib/] Doug brilliantly created in a few moments. To quickly compare both versions: * XAML-like and MXML snippets are now almost the same. I still prefer XAML version better because it uses the standard "Button" while MXML uses "CanvasButton". You can say right now what Button does but you will need to slightly investigate CanvasButton if you wish to use it. This is added complexity. * In XAML, there is no code required. * In Flex, you need to distribute and maintain separate component. In XAML, you don't. All three points mean that in Flex, you have less power and need more skills/effort. 4) I can't comment on performance since I don't really understand the internals of Flex compilers etc. But I can hardly imagine how the serialization format, or whether you use direct XML notation or a custom container that then holds some child components, can influence the performance any significantly. But you used this argument twice so there may be some issues. 5) The more I think about Adobe's and Microsoft's serialization formats, the more I believe that Flex is much closer to ASP.NET/WebForms declarative language than to XAML. With WebForms markup, you have similar concepts of user and custom controls (first for simple scenarios and defined in markup, second for arbitrarily complicated components but defined in code), you have similar limitation etc. XAML is really a next gen programming language and I don't feel that MXML is there yet. In conclusion... I don't want this to be a useless rant. I very much like Flex as a platform - ActionScript is a really nice language and the framework seems to do what it's intended for. I even like MXML much better that var b:Button = new Button() :) But I want to see it improving even further. To be honest, I thought that the development on the Flex platform will be quicker - it was all fine until I needed to have slightly more complicated tab in the TabNavigator. In WPF, I would simply carry on composing the UI while in Flex, I've lost much time investigating how to work around the technical limitations of mx:Button. There can be some technical problems like performace (as mentioned above) but I also understand that it may be simply too difficult to implement something like XAML - there, the components are practically "look-less" and this is definitely something that can be hard to change. Anyway, I just wanted to share my first impressions. Hope it will be of any value to you. Regards, Borek --- In flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> , "Ely Greenfield" <[EMAIL PROTECTED]> wrote: > > > > > > Hi Borek. I can give you the short answer, which is that composition is > an important goal of the flex framework. But we have two design goals > which WPF doesn't have - specifically > > - keeping the framework something that will perform well on the > 98% of the machines on the internet that currently have flash deployed > (WPF has much heavier client requirements). > > - keeping MXML something that a developer and/or designer can > look at, easily read and comprehend, and code by hand as appropriate > (most XAML files that I see tend to be fairly hard to read to the > typical developer). > > > > Both of these have forced us to walk a delicate line between power and > simplicity in our component framework, and composability is one of those > areas where we have been forced to make hard tradeoffs (and continue to > debate them on a daily basis). > > > > Having said that, the move to Flash Player 9, AS3, and the new AVM+ has > given us additional power (usable on the broad majority of the > internet...over 85% penetration at this point, I believe) that we've > only just begun to take advantage of in the framework. Expect to see us > weaving composition deeper and deeper into the framework as it evolves. > > > > I should also mention that there's technically nothing stopping you from > making composable controls like flexible buttons today. Personally, I > believe it's worth every flex developers time to learn a little bit of > component development; while there may be an initial up front learning > investment, Once you have the knowledge, banging out a couple of custom > built or reusable components doesn't take a lot of work. But building > that kind of flexibility into every push button in every flex > application, without paying a non-trivial cost in performance and > complexity, is something that takes time and consideration. > > > > Ely. > > > > > > > > > > From: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> [mailto:flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> ] On > Behalf Of borekbe > Sent: Friday, June 01, 2007 9:31 AM > To: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > Subject: [flexcoders] Really complex buttons (aka what WPF got right) > > > > Hi, I'm still learning Flex and during the last few hours, I've been > struggling with some button-related problems. > > I am trying to create a button which contains not only label and icon > but any arbitrary contents. If Flex was WPF, you could do something like > > > <mx:Button> > <mx:VBox> > <mx:Label ... /> > <mx:Image ... /> > <custom:Component ... /> > </mx:VBox> > </mx:Button> > > This approach really saves a lot of time and hassle but unfortunately > is not implemented in Flex (this would be great for future versions). > What I did in Flex was that I created a custom component based on > Canvas (say MyButton) and designed it however I wanted. I've set the > buttonMode property to true so I now have the nice hand cursor. Click > event is automatically there... > > So far so good. But the ultimate goal is to have something like > TabNavigator, except that the tabs are pretty complicated MyButtons. > No again, because the TabBar is based on buttons, you can only set > label and icon. I don't think I can help myself creating a new class > based on TabBar because the Button limitation would be still there. > > As far as I can see it, to have a custom button is fairly common > scenario and I can't believe that Flex makes it so hard for me as a > developer. There must be some way that I have simply missed. > > Could anyone more experienced please advise me, or generally comment > on Flex composability of more advanced controls? > > Thanks, > Borek >
<<image001.jpg>>
<<image002.jpg>>
