i am using force.com flex toolkit to retrieve datas from salesforce to flex 3….in flex builder i am able to retrieve the datas but when i hosted to server its not retrieving the data can anyone guide me how to solve this problem

The CSS support in Flex is not even standardized CSS, so I’d imagine there’d be little reason to argue against implementing custom CSS features such as *gasp* namespacing. C# has a nice way of disambiguing between types of the same name used in the same document, something similar could definately be used in CSS as it would blow the OMG-theres-so-much-work-to-port-our-CSS-to-Gumbo argument out of the water:
/* Begin css snippet */

using Button = mx.controls.Button;
using FxButton = fx.controls.Button;

Button
{
/* Whatever styles apply to the old crappy buttons */
}

FxButton
{
/* Whatever styles apply to the new funky gumbo buttons. No really, Gumbo rocks! */
}

/* End css snippet */

Fact of the matter is, these issues will always show up and is why we even have namespaces in the first place. It’s silly beyond reason to prefix class names but if that’s what you guys HAVE to do in order to get Gumbo out the door on time, then by all means prefix the OLD component sets with Mx or whatever (also not ideal for reasons I will explain later).

Point 2:
The ASDoc argument is moot. Make use of the [Deprecated] attribute and mark any such classes apropriately in ASDoc, sorting them with less priority and you solved the issue:

Button
[Deprecated] Button
HSlider
[Deprecated] HSlider

It doesn’t look all that pretty, but marking the classes deprecated means you have the necessary meta data available to do proper filtering. Tick a checkbox to hide deprecated classes and there you go, problem solved. Naturally, the meaning of the attribute Deprecated is to convey the fact that the class will itself disappear in the next version of the framework. This ensures that code bloat will not happen since you allow the graceful exit of old classes. What you effectively allow with prefixing the classes however IS code bloat. Deprecated classes are deprecated for a reason and should be removed from the codebase as soon as possible. Besides, this support is already implemented, the compiler already recognizes this. There’s NO REASON WHAT SO EVER to ignore that fact.

http://livedocs.adobe.com/flex/3/html/help.html?content=metadata_3.html

Point 3 that you mention is just grasping at straws. You can’t seriously mean that in order to facilitate the IDE you’re changing the framework. That’s about as absurd as it sounds. It’s not like “Button” is the only data you have available to you when building the code hinting information, and even if it was, you’re problem is not types of the same name anyway.

It really does seem like you have detached yourselves from the grips of reality. Flex is an excellent product, light years ahead of the competition. Ignoring this issue is an embarrassment and a slap in the face to your developer community. I LOVE Gumbo, the new skinning architecture makes so much sense. The new and improved CSS support is lovely. It’s starting to look more and more like a proper development ecosystem. Ignoring namespaces makes it, and Adobe, look silly. Not for naming the classes wrong, but for not understanding the concept of namespaces. It’s one of those things you’d expect the developers of a framework to grok.

Blaming the decision to forgo namespaces altogether on the complexity of the compiler is even more embarrassing and it ignores the ACTUAL issue completely. It might not be trivial to implement, but please try to consider the alternatives from a real world perspective, your customer’s perspective. This problem is not new and have been solved ages ago (it’s answer is namespaces). It is entirely possible to do away with namespace of course, many frameworks have done it in the past. Take a look at Apple for instance, they have code like this all over the place:

NSString
NSMutableArray
NSDictionary
CDCRecipient
CDCEmail
CDCEmailAttachment
CDCTableView
CDCOutlineView
CDCArrayController

Yeah, works out fantastically well. Best of all, it’s scalable:
FXNSCDCABCFOOBARButton

Hungarian notation anyone?

What really scares me are the rules-but-not-really-that-are-side-effects-of-this-silly-decision-to-forgo-namespacing:
“Now we did break this rule in one place, to avoid collisions between new Gumbo animation classes and Halo animation classes, but that general rule stands firm. So, in future versions of Flex, when we add a new skinnable component, it will be prefixed with ‘Fx’. As for why there are other classes new in Gumbo that are not prefixed, that is because they are not skinnable components in the Gumbo architecture but instead are graphic elements, new classes, etc.”

So essentially, it’s not a rule then? It became inconvenient with animation classes, what’s to say there won’t be other classes where inconveniance will yet again become an issue?

Please try to understand that you’re actually missing the point in this issue. Prefixing classes makes things more confusing in the long run. What’s even worse is that you then condone the use of classes and components that may well, going by the suggestions in your text, disappear at some point! This is a migration nightmare waiting to happen. Let’s for arguments sake you do go with the prefix route and people start using Halo and Fx components together, not knowing they’ll go away in Flex 5 (ficticious name). Now when Flex 5 rears it’s head and you again ask your customers to migrate (and they should!), you’ve effectively painted yourselves into a corner. Because remember, Flex 5 did away with the Halo components, but you never issued any warnings about this (the sole purpose of the Deprecated tag) so companies have developed these huge codebases on the assumption that they could take the datagrid from Halo and use with all the fancy pants magic going on in Fx. Using the deprecated tag, you still allow this, but issue proper warnings. This will actually EASE the transition from Flex 3 to Flex 4 (and subsequently Flex 5) instead of the prefixing solution (hack, if you will) which will merely be confusing, at best.

I sincerely hope that Adobe changes it’s mind before committing to this huge mistake.

One thing of note: it’s much easier to type ‘fx’ on a Dvorak keyboard than on a QWERTY. For me it’s like everyone else typing ‘yb’. So yet another reason for people to switch.

As Ted would say, here’s my 2 cents.

1. seems to make sense and I don’t know how you’d address it.

2. You already have this. o.e. take a look in the docs for HTTP service. 1 for MXML, 1 for AS.

3. Most of use I would have thought all have our own implementations of components, or other 3rd party components. You get prompted with a list of options that fit what u type, and select the one u want. Easy!

Also using fx? I mean that stands for Flex right? This sounds pretty limiting, what would you use next? Sound as naff as mx was back in the day.

Adobe is a design company, and good design is a valuable asset to any application. I understand this, and from a business viewpoint, there is probably ground to be gained by Flex when it comes to the integration of designers. But in this case, the ends don’t justify the means.

Many adopters of Flex, are small businesses, which do not have a designer on staff. Making the framework inconsistent only makes the life of the developer more complicated and not worth the effort. Please take a look at the bigger picture, and further evaluate what the priorities of the framework should be. By far, I’m only excited about typed arrays, otherwise I see no compelling reason to adopt the new sdk.

I agree with Deepa when she explain about the way to maping things in Flex.

The problem of most developers that follow the three in the end are that “not agreeness”.

Keep in mind that 2004 Flex was as2.0 and had a very complicated thing.

The design in mid the marshall plan for Flex 4 is a lot challenge in 18 months to face off.

Imagine to map and support previous version of a SDK that is used for generic propouse with less key enter in less time?

Excuse people But, the way FX prefix is done you will decide if your project decides to target to Flex 4 SDK or flex 2/3.

If you’re using the way flex 2/3 are why not using Degrafa? (www.degrafa.org) That’s the way Adobe Flex Team is working with them.

The only problem I see in the view of Deepa, is like Josh Tynjala says:
“…In short, I’d very much prefer to see the mx: stick around for Halo. It’s already a part of life now, so we’re used to it, and once it’s fully deprecated, Gumbo won’t make my files look like they’ve been infected with a nasty Fx disease….”

Should be a little simple and removing the fx prefix for halo, define the target sdk in namespace and keep using mx.

Looks like more Flex Builder limitations than in SDK as well.

Regards
Igor Costa

A temporary solution to the CSS issue could be:

- create new gumbo classes in a different namespace (fx:)
- leave the CSS engine as is
- create a subclass (e.g. FxButton) that simply extends flex.components.Button

This way, when (and only when) mixing halo/gumbo AND css skinning is required, developers can use the Fx version (at least until a better CSS compiler will be ready).

Not that the CSS lacks of namespace support is currently an issue on its own…

Also, why no FxLabel? Would seem the easiest one of all to implement…

Simple eh!?

Or is the idea with the Gumbo components to deprecate some of the current Halo components methods and properties?