Comments on: Fx prefix in Gumbo revisited http://www.peterelst.com/blog/2009/05/26/fx-prefix-in-gumbo-revisited/ Founding Partner - Project Cocoon Tue, 09 Mar 2010 08:46:36 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Tom Van den Eynde http://www.peterelst.com/blog/2009/05/26/fx-prefix-in-gumbo-revisited/comment-page-1/#comment-21108 Tom Van den Eynde Wed, 27 May 2009 21:20:52 +0000 http://www.peterelst.com/blog/?p=1987#comment-21108 I tend to make my 'own' components based on the components provided by Flex. This way I only have to change the base class of 'my' components and everything works fine again. Using only your 'own' components you can fix flaws (like the focus border not being drawn when giving focus using the mouse) in 1 central place. I tend to make my ‘own’ components based on the components provided by Flex. This way I only have to change the base class of ‘my’ components and everything works fine again. Using only your ‘own’ components you can fix flaws (like the focus border not being drawn when giving focus using the mouse) in 1 central place.

]]> By: Tink http://www.peterelst.com/blog/2009/05/26/fx-prefix-in-gumbo-revisited/comment-page-1/#comment-21107 Tink Wed, 27 May 2009 08:57:34 +0000 http://www.peterelst.com/blog/?p=1987#comment-21107 Maybe I'm missing something here, but I don't understand why they didn't just add 1 new namespaces for the Spark components. i.e. why didn't the mx namespace stay as xmlns:mx="http://www.adobe.com/2006/mxml" and just add a new one for Spark xmlns:spark="library://ns.adobe.com/flex/spark" so that all code was backward compatible. You'd only have to add a new namespace to you code, if you decided to implement one of the new Spark components. I thought the main issue was that it was to be backwards compatible. Maybe I’m missing something here, but I don’t understand why they didn’t just add 1 new namespaces for the Spark components.

i.e. why didn’t the mx namespace stay as

xmlns:mx=”http://www.adobe.com/2006/mxml”

and just add a new one for Spark

xmlns:spark=”library://ns.adobe.com/flex/spark”

so that all code was backward compatible. You’d only have to add a new namespace to you code, if you decided to implement one of the new Spark components.

I thought the main issue was that it was to be backwards compatible.

]]> By: jay http://www.peterelst.com/blog/2009/05/26/fx-prefix-in-gumbo-revisited/comment-page-1/#comment-21106 jay Tue, 26 May 2009 18:18:12 +0000 http://www.peterelst.com/blog/?p=1987#comment-21106 @Aral: " not great news if you’re just getting into Flex " I don't know about new developers... try convincing a young developer who is just out of school/college and has been already seduced by the OSS trenches that he should be targeting a proprietary platform. Ok, now on top of that try to convince him that his applications cannot have Buttons, Datagrids and Forms. It must have FxButtons, FxDatagrids, and FxForms... oops, you probably lost him by now... :-D Anyway, my point is really that argument for productivity is a good one but it's not the only one and many times is not the ultimate reason on which software platforms are chosen. The fact that so many people choose open software and standards over proprietary ones stands also as testament of this, as proprietary software many times offer better productivity, but still the lower risk and long term benefit of OSS has historically proven it's value. @Aral:

” not great news if you’re just getting into Flex ”

I don’t know about new developers… try convincing a young developer who is just out of school/college and has been already seduced by the OSS trenches that he should be targeting a proprietary platform.

Ok, now on top of that try to convince him that his applications cannot have Buttons, Datagrids and Forms.

It must have FxButtons, FxDatagrids, and FxForms… oops, you probably lost him by now… :-D

Anyway, my point is really that argument for productivity is a good one but it’s not the only one and many times is not the ultimate reason on which software platforms are chosen.

The fact that so many people choose open software and standards over proprietary ones stands also as testament of this, as proprietary software many times offer better productivity, but still the lower risk and long term benefit of OSS has historically proven it’s value.

]]> By: Ben Stucki http://www.peterelst.com/blog/2009/05/26/fx-prefix-in-gumbo-revisited/comment-page-1/#comment-21105 Ben Stucki Tue, 26 May 2009 17:46:05 +0000 http://www.peterelst.com/blog/?p=1987#comment-21105 Aral, There are those of us in the Flex community who are involved out of a (*gasp*) passion for developing apps with Flex. So let me assure you that no one in the vocal minority was motivated by convoluting the framework in an attempt to look smart or make money. I'm frankly disappointed by these stray comments you're throwing out, and I'm finding it difficult to address the valid concerns in the midst of them (which were much debated over). I think we're all interested in seeing the framework succeed, so let's keep it above the belt shall we? Aral, There are those of us in the Flex community who are involved out of a (*gasp*) passion for developing apps with Flex. So let me assure you that no one in the vocal minority was motivated by convoluting the framework in an attempt to look smart or make money. I’m frankly disappointed by these stray comments you’re throwing out, and I’m finding it difficult to address the valid concerns in the midst of them (which were much debated over). I think we’re all interested in seeing the framework succeed, so let’s keep it above the belt shall we?

]]> By: TJ Downes http://www.peterelst.com/blog/2009/05/26/fx-prefix-in-gumbo-revisited/comment-page-1/#comment-21104 TJ Downes Tue, 26 May 2009 15:44:38 +0000 http://www.peterelst.com/blog/?p=1987#comment-21104 Aral, your concerns seem to assume that the average developer learning Flex, who had the capability to learn Flex 3, would find Flex 4 to be significantly more difficult. I don't really buy into that. I believe most people who want to learn Flex are considerably bright enough to figure these things out. Aral, your concerns seem to assume that the average developer learning Flex, who had the capability to learn Flex 3, would find Flex 4 to be significantly more difficult. I don’t really buy into that. I believe most people who want to learn Flex are considerably bright enough to figure these things out.

]]> By: Aral Balkan http://www.peterelst.com/blog/2009/05/26/fx-prefix-in-gumbo-revisited/comment-page-1/#comment-21102 Aral Balkan Tue, 26 May 2009 14:25:00 +0000 http://www.peterelst.com/blog/?p=1987#comment-21102 Peter, Also mention that this will mean that _existing code_ cannot be reused without making changes. So if you're using five different libraries and maybe a couple of skins you'll have to go in there and add namespaces to everything, including the CSS. With the Fx prefix, you could just drop your existing code into your project. Wanna add a Gumbo afterwards, go right ahead, just add it, no need to change anything. Wanna use a skin created for Flex 3, no problemo. ^^^ All that's lost with namespaces. These are real, _practical_ reasons for why this change is a step backwards. I'm not talking about aesthetics of formal beauty here but pragmatism. It also adds additional complexity that will confuse newer developers and make it harder to learn the framework. That's great news if you're writing books (because they'll have to buy more books to read about this confusing stuff) or if you're a consultant/advanced developer (you can charge more and get more work and dazzle people by knowing all this complex stuff) but not great news if you're just getting into Flex, evaluating it against similar technologies or if you're concerned about the competitiveness of the platform and future adoption rates among developers. Peter,

Also mention that this will mean that _existing code_ cannot be reused without making changes. So if you’re using five different libraries and maybe a couple of skins you’ll have to go in there and add namespaces to everything, including the CSS.

With the Fx prefix, you could just drop your existing code into your project. Wanna add a Gumbo afterwards, go right ahead, just add it, no need to change anything. Wanna use a skin created for Flex 3, no problemo.

^^^ All that’s lost with namespaces.

These are real, _practical_ reasons for why this change is a step backwards. I’m not talking about aesthetics of formal beauty here but pragmatism.

It also adds additional complexity that will confuse newer developers and make it harder to learn the framework. That’s great news if you’re writing books (because they’ll have to buy more books to read about this confusing stuff) or if you’re a consultant/advanced developer (you can charge more and get more work and dazzle people by knowing all this complex stuff) but not great news if you’re just getting into Flex, evaluating it against similar technologies or if you’re concerned about the competitiveness of the platform and future adoption rates among developers.

]]> By: Peter http://www.peterelst.com/blog/2009/05/26/fx-prefix-in-gumbo-revisited/comment-page-1/#comment-21101 Peter Tue, 26 May 2009 13:12:09 +0000 http://www.peterelst.com/blog/?p=1987#comment-21101 Good point Asger, in an ideal world we would of course have a complete set of Spark components -- but right now its true that you're more or less forced to use multiple namespaces. Good point Asger, in an ideal world we would of course have a complete set of Spark components — but right now its true that you’re more or less forced to use multiple namespaces.

]]> By: Asger Flashger Laursen http://www.peterelst.com/blog/2009/05/26/fx-prefix-in-gumbo-revisited/comment-page-1/#comment-21100 Asger Flashger Laursen Tue, 26 May 2009 13:08:31 +0000 http://www.peterelst.com/blog/?p=1987#comment-21100 I agree, though I would say that in terms of Flex 4, there *will* be a lot of use cases where you would mix mx: and s: name-spaces. Forms, RPC etc., is still mx: only components thus, would have to be intermixed with the new name-space. I'm all for name-spaces, and one way to go about clearing out what is what could be a supporting IDE which color coded the various name-spaces differently. Cheers Asger I agree, though I would say that in terms of Flex 4, there *will* be a lot of use cases where you would mix mx: and s: name-spaces.
Forms, RPC etc., is still mx: only components thus, would have to be intermixed with the new name-space.

I’m all for name-spaces, and one way to go about clearing out what is what could be a supporting IDE which color coded the various name-spaces differently.

Cheers

Asger

]]>