Inspiring

Question

Fx prefix revisited

Forum|Forum|17 years ago
February 6, 2009
72 replies
23035 views

Alrighty, we promised we'd have further discussion about this on the forums, so here we go. Since I think the email system can't handle really long posts, I'm going to post a series of things that I've written up, along with some responses that started among the team. We'll take things from there.

Solving the naming convention with regard to overlapping classnames is especially difficult when you take a number of factors into account. Here are some of the things to consider as we look to address the issue (not prioritized and not exhaustive):

These issues can be attributed to general use and the SDK:
- Flex 4 aims to be compile-time compatible with Flex 3. This means that we cannot rename existing classes nor break major interface contracts.
- Given we can't rename existing classes, what package naming structure makes sense if new classes will overlap with existing.
- How does CSS differentiate between classes with the same local name (class name)
- How will new users understand the differences between Spark and Halo classes, and especially understand when there is overlap
- What should documentation do to differentiate between Spark and Halo controls, and how do we control which page a user arrives at when searching
- How will someone reading code easily understand which control the code is using
- Given the change in architectures, how does someone easily know which architecture a component belongs to
- The number of overlapping controls between Spark and Halo will increase after Flex 4, Spark will receive new controls over time

These issues can be attributed to an IDE (any of 'em):
- How does code hinting work when you have overlapping classes (what can it do to help differentiate)
- If a list of components is in a panel, how do those components get differentiated
- Should a tool warn when components from different architectures are mixed, how does the tool know when such mixing of overlapping components or architectures is intentional
- Should the tool promote one architecture's components over another, or provide user preferences to control promotion, and how flexible do those preferences need to be

Next up: the current situation.

Developers

This topic has been closed for replies.

Show previous replies

_Michael_Labriola_

Participant

Okay, I only have a few things to add.

First, I spend most of my waking hours figuring out how to teach or actually teaching people to use Flex that are either coming from other traditional programming languages or from HTML backgrounds. There are many problems that these individuals have while learning Flex, however, the use of namespaces has never been one of them. In fact, of all of the criticism we have received on the training from the source book (and trust me, people love to email me with criticism) not one person has ever expressed confusion about the namespaces and we introduce this concept in Chapter 3 of the beginner book.

Second, I understand Adobe's desire to make this approachable for new users, and I think that is a reasonable goal. However, doing so at the expense of more advanced users is only a way to build resentment and dismay, not community expansion. Sorry if that seems off topic, but I believe a good portion of this discussion revolves around a desire to make things easier for beginners without a good understanding of what might do that. Truthfully, I believe the answer is pretty clear: Multiple namespaces and better tooling.

I have deployed a project with a duplicate of every single Flex core SDK class. Because the tooling was insufficient we had to prefix everything. I hate it. I wish it was different. I don't want to do it again.

Michael Labriola

_Arul_Prasad_

Participant

Agree with Ryan Stewart, Tinc, Manish, and all those who support multiple namespaces.

I don't much to add, but still want to add an extra vote to multiple namespaces.

Like Ryan said, I think making it easier for newcomers should be the tools(FlexBuilder) job. The language itself should be 'right'; it need not be easy for HTML developers. IMHO, HTML developers who want to hand code MXML, would be smart enough to understand namespace prefixes. And if they aren't, they'd take the easier approach, of using the tool(Flex Builder), just like how they'd use Dreamweaver for HTML.

Talking about newcomers, a newcomer to Flex 5 / 6 (when eventually Halo would be phased out) in the future would be wondering why some Flex classes have a "Fx" at the beginning of its name, and some don't. So at some point or the other, questions will have to be answered. It would be best to not pollute the language with the immediate future in mind.

Thanks.

DustyJ

Participant

Right, so I'll admit that I got caught up in the hyperbole surrounding this issue, but I guess I was trying to point out that there are issues with readability, scanability and noob-ability with BOTH solutions, and that the common 'argument' against prefixes is that "it looks bad" or "doesn't feel right", rather than an actual technical argument.

There are technical arguments against the pure-namespace issue; although those can be overcome, the amount of dev time that would go into overcoming these obstacles could better be used in finishing the framework. I guess I see the 'Community Committee' saying that they want to get rid of the prefix, but they aren't offering up anything to the cost/benefit analysis...

I know it's been suggested, but maybe a formal proposal from the Community Committee that says "We want the pure solution, and we're prepared to commit to adding the missing Gumbonents (Who coined that word?) while the Flex team focuses on removing the prefixes and the features required to do so" would allow 'those in charge' to see that the community is willing to buy this feature with their own time.

_Arnoud_Bos_

Participant

Namespaces is wayyyy better than FX<ComponentName>. Please dont go that way. The needed transition/mix of components is bad enough but at least do it withouth polluting component names. A Button is a Button. What is FxButton? some kind off buton with effects? Just doesn't feel right. What bothers me is that you are releasing a version 4(!) of a technology and that it wont be finished. I love flex but this is lame imho. Flex 3 is ok, so why not wait until all the components are ready before releasing version 4? Novice users then wont even have all the problems with mixing components, they can just use version 4 all the way. If you want to attract new users and propose flex is rather easy to learn this is the way to go. Experienced users wont have a problem migrating old software using extra namespaces as they are used to them anyway. Anyway i'll probably stick to flex 3 until 4 is really finished including all currently available components in flex 3. As it's again a complete rewrite of the components the first version probably has some bugs anyway. In the meantime libraries as degrafa will fill the gap for more primitive drawing for me. Sorry that i sound so negative, but im really dissaponted that flex4 won't be finished (or has a smaller component-set) at the time it will be released. But still flex is nr1 in ria..... so keep up the good work! Arnoud

Constantin Ehrenstein

Known Participant

In addition to my recent post, I'd like to express my hope that the Flex SDK team will have the balls (figure of speech, no offense to the female coders) to confront Adobe's suits with the fact that the migration to the next generation of Flex won't be complete by the time Flex 4 rolls out.

Why not admit that we're in a substantial transition of the Flex framework which is almost impossible to complete within one product cycle?

Sure, code-freezing a half-baked Flex SDK for Flex 4 imposes hardships on developers of all experience levels (presumably especially the novice developers) and will definitely look kind of messy. But what are the choices?

1. Prettifying the half-baked mess (as developers out there might see it) with something that looks as if it was all intentional (i.e. introduce Fx prefixes)

2. Shrugging your shoulders, telling the Adobe suits "if you'll have to roll out Flex 4 by fall '09, there will be a half-baked framework" (i.e. mix mx: with fx: namespace)

3. Postponing the release of Flex 4 until the next generation of the framework is sufficiently complete and stable (i.e. provide a default namespace for the new language/components bundle, along with the opportunity to tie in legacy code via namespaces)

4. Opening up to the community and accepting help from veteran community developers to outsource component development so that the Gumbo language/Spark components will be ready by the time Flex 4 is supposed to ship

I can't help but favoring #4, followed by #3, #2, #1.

To me, the top priority always is the most sophisticated, consistent language. Don't forget that the migration frenzy will be over sooner or later, and I shudder with disgust when I think of some awkward glossed-over workarounds for temporary problems remaining in the MXML language.

Adobe made the right decision to open the Flex SDK up to the community, but now the quality of the language should not be messed with because of some Adobe specific business decision (i.e. the release time frame of Flex 4).

@Dusty:
If we stay true to the principle that the most recent fully functional language/components bundle will occupy the default language, there is no need to abolish import statements.

So by the time the Gumbo/Spark package isn't complete yet, we're supposed to use

import mx.some.Componentname;



myHaloComp:Componentname = new Componentname();

mySparkComp:fx.some.spark.Componentname = new fx.some.spark.Componentname();

--simply because the Halo bundle represents the last fully functional set.

As soon as the Gumbo/Spark bundle is ready, we use

import fx.some.spark.Componentname;



myHaloComp:mx.some.Componentname = new mx.some.Componentname();

mySparkComp:Componentname = new Componentname();

This will hold in future migration phases, too: we will always have the most recent fully functional set occupy the default namespace, with legacy or not-yet-ready additions tied in via namespaces.

This is a very straightforward and consistent principle which is easy to grasp, even for novice developers.

C.

_Haykel_Ben_Jemia_

Known Participant

Hi,

my suggestion for the default set of namespaces:

MXML 2006 language namespace as we know it
MXML 2009 language namespace that will contain the spark components, halo components that are not yet (or will not be) ported to spark and the remaining language constructs
Halo component namespace that contains only halo components that are not in the MXML 2009 namespace
Spark component namespace that contains only spark components (that are not in the MXML 2006 namespace anyway)

MXML 2006 and MXML 2009 namespaces can not be mixed.

Old Flex 3 code will still compile as it uses the MXML 2006 namespace. If a Flex application should be ported to spark, then the language namespace should be changed to MXML 2009 and compile errors (if there are any) corrected. If spark components should be added to a Flex 3 application, then it can be done through the spak component namespace. A pure Gumbo application will only need the MXML 2009 namespace.

As development on Gumbo goes on, everytime a Halo component is replaced with a new Spark component, it takes its place in the MXML 2009 namespace and the halo component goes to the halo component namespace.

Haykel Ben Jemia

Allmas
Web & RIA Development
http://www.allmas-tn.com

On Tue, Feb 10, 2009 at 10:37 PM, Peter Farland < member@adobeforums.com> wrote:

A new message was posted by Peter Farland in

Developers --

Fx prefix revisited

Hi all, hearing your feedback is great and I hope we can approach a decision for Gumbo soon.

First, a minor point: for the default set of namespaces in MXML - hearing folks are used to namespace prefixes is useful. Prior to this I had the sense that prefix-less MXML was where folks wanted to go - though personally I don't mind either way. As others have said, MXML is XML and the only reason we're discussing this is that a convention has to be established for documentation.

Point 1.) If people prefer prefixes, we establish the convention that prefixes will be used for our well known MXML namespaces (for the sake of consistency).

For the namespaces themselves (ignoring CSS issues for now), I'm hearing loud and clear that folks are used to multiple namespaces because custom components and third party libraries are the norm. First, I think it's worth repeating the following assumption:

Point 2.) Flex 3 MXML 2006 namespaced documents will still be recognized by the Gumbo compiler.

Given that, some folks have explicitly said they are fine with Gumbo separating MXML 2009 into 3 well known namespaces. Others alluded that they were fine with "multiple namespaces" but didn't describe what they thought would live in each namespace.

I'd like to hear from the folks who weren't specific about what they think of the original proposal for three well known namespaces: specifically, a new MXML 2009 namespace (language), a new Halo namespace (component) and a new Spark namespace (component). The contents of these namespaces are largely distinct (though faceless components (like services) would exist in halo and spark). MXML 2006 would not be mixed with MXML 2009.

Since folks said they're comfortable with multiple namespaces, are they also comfortable with having to re-namespace and potentially re-prefix Flex 3 content when they want to mix it into a Gumbo document? Is it obvious what would be a Spark component, a language component, a Halo component?

The concept of merging namespaces was also brought up in the original proposal, but it seems people are fine with just a clean separation of components and the language. Does anyone object to leaving them separate? Or were some people assuming there would be some default merging, say of at least spark + faceless components into MXML 2009? I'd like us to be specific about people expect in each namespace and what the day-to-day MXML experience would be like.

To me, arbitrary merging of namespaces bringing back the issue of collisions and I feel that it makes sharing code more complicated as you have to consider the existing merges that have been applied.

Perhaps less important to some, I also want to circle back on the issue of CSS type selector collisions. I heard the following:

a). Disambiguation of CSS type selectors is less urgent as basic type selectors are not the usual approach for customizing component styles.

b). There's an acceptance of having to consider namespaces in CSS selectors if types needed to be disambiguated.

c). Jared also mentioned the possibility of ignoring unknown style properties.

Hearing a) is a good reminder, though I think we still need to decide on the approach in the Gumbo timeframe - even for edge cases. For b), I'd like to dig deeper: while there's an acceptance of having to use namespaces if and when CSS type selectors need disambiguation, I haven't heard people's opinions if this was made mandatory for all type selectors. Also, I think c) is an easy way out, but the issue of missing style property typos is likely a deal breaker.

Thoughts?

View/reply at Fx prefix revisited

Replies by email are OK.

Use the unsubscribe form to cancel your email subscription.

bclinkinbeard

Participating Frequently

Why would you ever need to instantiate fx.controls.Button and mx.controls.Button? There is simply no reason to ever do that.

On Tue, Feb 10, 2009 at 10:13 PM, Dusty Jewett < member@adobeforums.com> wrote:

A new message was posted by Dusty Jewett in

Developers --

Fx prefix revisited

Maybe it's just that the opposition to the Fx is so vocal, and those in support of it think that Adobe won't change it, but I feel odd for voicing my support for Prefixing the new components. I'd actually go further and suggest using SparkButton over FxButton, putting the absurd "GxButton" argument to rest.

I don't care about mxml, even though I know that beginner users will find the difference between Button and SparkButton much easier to understand that Button and fx:Button are the same thing, but mx:Button is different, unless the person that wrote the file made mx the * namespace, which means that Button and mx:Button are the same thing, and fx:Button is different.

I'm kinda pissed that if prefixing goes through, I might have to start declaring all of the crossover components as:

var fxb:fx.controls.Button = new fx.controls.Button

var mxb:mx.controls.Button = new mx.controls.Button

Seriously? How easy is that to scan through? Why have import statements at all?

Now imagine casting your event objects:

var b:mx.controls.Button = event.currentTarget as mx.controls.Button;

var c:fx.controls.Button = fx.controls.Button(event.currentTarget);

And yes, we will be supporting both mx and fx buttons in the same code for some time, as we'll be up to about 100 modules + 5 libraries by the time Flex 4 is released, and convincing management that we have to have a month or two to convert everything over will be impossible.

(and my head starts to hurt just thinking about the mess that our css files will turn into... our designers heads might explode)

View/reply at Fx prefix revisited

Replies by email are OK.

Use the unsubscribe form to cancel your email subscription.

_Josh_McDonald_

Known Participant

I think if you're building one component with both mx.core.Button *and* mx.gumbo.Button (or whatever it is) from ActionScript, you're definitely doing something that's going to make your code ugly either way. And if you're only importing one "Button" and one "Container", your code won't be any harder to read for one being in Halo and one being Spark.

-Josh

On Wed, Feb 11, 2009 at 1:13 PM, Dusty Jewett < member@adobeforums.com> wrote:

A new message was posted by Dusty Jewett in

Developers --

Fx prefix revisited

Maybe it's just that the opposition to the Fx is so vocal, and those in support of it think that Adobe won't change it, but I feel odd for voicing my support for Prefixing the new components. I'd actually go further and suggest using SparkButton over FxButton, putting the absurd "GxButton" argument to rest.

I don't care about mxml, even though I know that beginner users will find the difference between Button and SparkButton much easier to understand that Button and fx:Button are the same thing, but mx:Button is different, unless the person that wrote the file made mx the * namespace, which means that Button and mx:Button are the same thing, and fx:Button is different.

I'm kinda pissed that if prefixing goes through, I might have to start declaring all of the crossover components as:

var fxb:fx.controls.Button = new fx.controls.Button

var mxb:mx.controls.Button = new mx.controls.Button

Seriously? How easy is that to scan through? Why have import statements at all?

Now imagine casting your event objects:

var b:mx.controls.Button = event.currentTarget as mx.controls.Button;

var c:fx.controls.Button = fx.controls.Button(event.currentTarget);

And yes, we will be supporting both mx and fx buttons in the same code for some time, as we'll be up to about 100 modules + 5 libraries by the time Flex 4 is released, and convincing management that we have to have a month or two to convert everything over will be impossible.

(and my head starts to hurt just thinking about the mess that our css files will turn into... our designers heads might explode)

View/reply at Fx prefix revisited

Replies by email are OK.

Use the unsubscribe form to cancel your email subscription.

--
"Therefore, send not to know For whom the bell tolls. It tolls for thee."

Josh 'G-Funk' McDonald
- josh@joshmcdonald.info

- http://twitter.com/sophistifunk
- http://flex.joshmcdonald.info/

DustyJ

Participant

Maybe it's just that the opposition to the Fx is so vocal, and those in support of it think that Adobe won't change it, but I feel odd for voicing my support for Prefixing the new components. I'd actually go further and suggest using SparkButton over FxButton, putting the absurd "GxButton" argument to rest.

I don't care about mxml, even though I know that beginner users will find the difference between Button and SparkButton much easier to understand that Button and fx:Button are the same thing, but mx:Button is different, unless the person that wrote the file made mx the * namespace, which means that Button and mx:Button are the same thing, and fx:Button is different.

I'm kinda pissed that if prefixing goes through, I might have to start declaring all of the crossover components as:
var fxb:fx.controls.Button = new fx.controls.Button
var mxb:mx.controls.Button = new mx.controls.Button

Seriously? How easy is that to scan through? Why have import statements at all?

Now imagine casting your event objects:
var b:mx.controls.Button = event.currentTarget as mx.controls.Button;
var c:fx.controls.Button = fx.controls.Button(event.currentTarget);

And yes, we will be supporting both mx and fx buttons in the same code for some time, as we'll be up to about 100 modules + 5 libraries by the time Flex 4 is released, and convincing management that we have to have a month or two to convert everything over will be impossible.

(and my head starts to hurt just thinking about the mess that our css files will turn into... our designers heads might explode)

_boobiestar1234_

Participating Frequently

Quote:
Since folks said they're comfortable with multiple namespaces, are they also comfortable with having to re-namespace and potentially re-prefix Flex 3 content when they want to mix it into a Gumbo document? Is it obvious what would be a Spark component, a language component, a Halo component?

- If I have never seen Flex MXML and I was just getting into it I would be confused if I was able to choose Button, FxButton, fx:Button or mx:Button. If I saw, "FxButton" and "Button" I would think that, "FxButton" was an alternative choice. I think if you type "Button" that would be the recommended option to choose. If Spark is the future than "Button" or "fx:Button" should be the default. I might be confused on what we've established so far in this discussion but I can't see a new user understanding the distinction the "Fx" prefix is making any better than using a namespace to establish it.

I think trying to remove the namespaces altogether is causing a lot of these issues. I like them and think it makes MXML stand out but I can see that others would want that. I think if you get a new developer and show them a mxml file without any namespaces they may understand it quicker but they are going to see namespaces sooner or later. Either in the documentation or in the multitude of examples online. It's a temporary tradeoff that seems to be causing a lot of problems. It's when you show them what Flex can do that you sell them.

Judah

Show more replies

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded