Hi all.
I was working on creating a frameworkless MXML project which would:
- consist of 2 frames and let you design both "preloader" frame and "application" frame.
- will use MXML for laying out visual components as well as other common things like event mapping, remote operations calls etc.
- will be as small as possible in size.

Finally, I've made the example that works!
Here, you're welcome to try it:
http://e4xu.googlecode.com/files/frameworkless.zip - the basic example project
http://e4xu.googlecode.com/files/framework.swc - the patched framework.swc
Patch details:
- Removed dependency on IUIComponent from ObjectUtilities.
- Removed dependency on Sort (and thus the dependency on SystemManager) from IListCollection.
- Completely replaced StyleManager and ServerConfig classes.
- when compiling, you'll need to provide an empty CSS file for -defaults-css-url additional compiler arguments (to make StyleManager quite, as we don't want to depend on this one as well).

There for sure may be tons of bugs, better solution, required features and such. So, if you feel interested in this, I would like to here your opinion. The entire code base is here:
http://code.google.com/p/e4xu/source/br ... /trunk/src

My patch was based on SDK 3.2. I'm looking forward to upgrade it to Gumbo, though, this isn't something I'll be doing soon.

It is not highly organized... and it needs a clean up, documentation etc, etc, but, sure, if you have anything to say about it, I'll happily listen to that too.

PS. the example project compiles into 14K SWF in debug mode!

PPS. Mind it, that if you want to compile it, you'll need to compile against the patched SWC, not the one that you may download with the SDK. It may eventually compile with the SDK standard SWC, but in certain cases it will include the classes / interfaces you don't want to be there. So, consider yourself warned

You sample is amazing but I couldn't use your custom framework.swc (BTW I just tried adding it into my project and it just seems to complain that StyleManager is missing many methods).

Did you continue in this direction? Did you use it in a "real project"?

Yes, sure I will, though there ware few "features" that putt me off a bit...
Like, digging a bit dipper into the process of translating of MXML file I found that it is very raw at the moment This means that the MXML compiler isn't very smart... in fact it isn't smart at all, besides there are lots of minor bugs an inconsistency of what comes out of MXML code...

Few things to mention:
- impossible to add multiple listeners for the same event.
- impossible to remove listeners added through MXML.
- inconsistent behavior of [DefaultProperty] when used with [ArrayType].
- impossible to specify access modifiers through MXML.
- no control over how generated listeners are defined (they are declared as public always for no reason).
- general "not smart" code generation (like, references to functions are made by string identifier - a potential danger of ambiguity if you happen to have more than one open namespace and those namespaces happen to have methods with the same names, valid listeners added through MXML are not recognized- thus additional listeners are generated).
- And least but not last: the properties declared in MXML are not guaranteed to be declared in the AS resulting from it in any order... nor alphabetical, nor display object / non-display object... neither the order from MXML - so that if you wanted to do the depth management by yourself, it just looks now like that is completely impossible...

And there are lots more things to complain about...

And, yes, I'm working on some big project where I intend to use what I try to do with MXML. But it is miles away from being completed and is huge at the very best it will get into production stage late this Autumn (well, I may be optimistic ).

Considering the framework.swc. I have updated that file several times, firstly, I forgot to add there the classes needed for embedding assets. I'll check if I forgot anything else to add there. Besides it is based on framework.swc from SDK 3.2 (at that time ISystemManager used to have way less methods (all the ApplicationDomainBridge stuff was added in 3.3, which made SyStemManager even more difficult when trying to load Flex SWF into regular SWF )
A friend of mine is now working on some sort of navigation helpers and site structure patterns (if you're familiar with Gaia - something of that kind, but less complex). So, next thing I'll be working on will be incorporating of what he does in my project. Sure, I'll have to review all I have and, yes, I'll continue working on it!

Besides, I've added an example of stuff I added lately:
(skins / styles and hints)
http://code.google.com/p/e4xu/source/br ... k/examples
it has an SWF which is basically the test of different things + the MXML source for it.

I'm updating and reorganizing the project, finally, it had seen some practical use! So, I'll try to bring at least some of it's parts into production state.
I'm upgrading the project to use FP10 features.

Some goals to achieve:
* I will also try to completely change the skinning concept (there isn't a lot to change, but still...) to use FGX.
* Make naming more consistent and put some documentation in, at least, base classes...
* It is possible, that if, and I will be given enough time to do it... I'll consider making some kind of preprocessor for MXML... The ultimate goal would be to patch the compiler, but this seems like quite some task for me alone...

Here's a screenshot of couple of components being developed, and there're more to come:

Minor update:
I've patched the framework.swc for to be compliant with SDK 4.X.
http://e4xu.googlecode.com/files/framework.swc
This is for anyone who wants to use basic MXML features without using Flex framework visual stuff (binding and embedding resources). It grew in size somewhat... but, I'll try to look over embeds once again, I'm sure the size may be reduced to be even less than that.

EDIT: It appears that after the patch some features ware broken. For instance, XML cannot be resolved in MXML code now...
I'm working on fixing that...

EDIT2: The XML issue fixed! Thanks Adobe and Paul Reilly.

For whoever is interested:
http://kb2.adobe.com/community/publishi ... 52670.html
This, and I'm going to write more about bindings, built-ins usage, styles and skins when I have time.

This is interesting ...

So for most projects, I think that the Flash IDE + SWC + FlashDevelop workflow is best. It strikes a nice balance between laying things out visually in Flash, then programming in FlashDevelop.

However, for developers who are not using the Flash IDE, using MXML in this way seems like a good alternative. Unless I am mistaken, you could use MXML to embed graphics and set up visual properties like width, height, scale and the display order without using the Flex framework.

If someone developed an alternative to the Flash IDE, MXML would be a good format. The visual editor wouldn't have to use Flex at all, but it could streamline PNG and JPG imports, moving, resizing, masking and other visual tasks. Of course, I think the Flash IDE does this all fine, but some people are really into open source, and who knows? Perhaps a better visual environment could be created for game developers, who usually tend to be the people I see asking about developing without the Flash IDE.

Well, MXML is basically a sort of template language for AS3 in a sense that a single node will usually translate into several lines in AS.
However, for graphics and resources there is FXG. This is kind of what SWFMill was to AS2. The FXG format although designed by Adobe isn't yet fully implemented and the specs changed last time maybe a week ago (now it's version 2), but, I think that because of FXG being an XML format it is likely that sooner or later there will be some IDE alternative to Flash for creating Flash graphics.
Adobe's implementation of FXG isn't perfect however... for whatever reason they decided to mix it with the framework stuff, i.e. some tags in it are implemented as UIComponent extending classes (if you don't watch out Group -> spark.components.Group)... Or, you may occasionally use something that will make it import Flex framework stuff, like bindings etc. (Eg. BitmapImage relies on @Embed() -> Embed requires mx.core.BitmapAsset, mx.core.FlexBitmap + couple of others).
Sounds and video are missed out...
http://opensource.adobe.com/wiki/displa ... cification

There is another not so good thing about MXML - the code behind generation. It is many times hardcoded in the compiler. However, altering that sounds doable. We are now investigating the possibilities of tweaking it a bit (the Velocity Apache packages), so it will allow more stuff that are common in MXML layout to be done without using framework. In fact there are countless possibilities of what may be done, the limit is only the human resources and the time for doing what we want I think that first of first we'll try to rewrite the bindings and resource managing, and, we'll see what else may be done.