I'd be happy to share that information with you. My main reasons for preferring
straight Actionscript over MXML are:
1. My editor of choice, Visual SlickEdit, which I've used since my C days in
the last millenium, does not have an MXML mode. It provides nice code
completion, syntax highlighting, autoindent, etc. for XML or Actionscript
separately, but not together. So when I have to work with MXML, I usually pull
the Actionscript out into a separate include file.
2. I don't like to fuss with namespaces and manifest files to use my own
components in MXML, especially for one-offs.
3. As a matter of personal preference, I prefer working with code, with all
of its curly braces, parentheses, function calls, etc., over XML. As far as the
extra verbosity of code goes, I have some utility functions which make it
comparable to MXML. For example, I have a utility function that will add a
UIComponent to its parent container, and set any number of properties or styles
on it, all in a single function call.
4. As a corollary to #3, I prefer that the code that ultimately is compiled
is written (and hence known) by me, rather than generated, so if it doesn't
work right, I can more easily diagnose the problem.
I rarely use databinding. Instead, I use old-fashioned assignment statements,
that execute exactly where and when I want them to. I previously worked with a
guy who was committed to doing things in "The Flex Way", who bound all of the
controls on a GUI form to the fields of the object it was meant to modify. But
since the form had a Cancel button, he also had to write a lot of code that
would save a snapshot of the properties of the object so he could restore the
object's original state if the Cancel button was clicked. When I had to go back
and fix the numerous bugs in that form after he left, I ripped out all of the
binding and restore code, and simply updated the object's properties when the
OK button was clicked. The end result was much less code that was far more
understandable.
Gordon Smith <[EMAIL PROTECTED]> wrote:
> I don't see why the Flex team couldn't build a minimal set of
defaults
> into the Application class that would allow it to be used outside of MXML.
We could make this work (although we won't have time before Flex 3 ships).
Please file an enhancement request at http://bugs.adobe.com/flex if you feel it
is important for a future release.
But I'm always interested in why some people avoid MXML. What's your reason?
- Gordon
---------------------------------
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Dave
Glasser
Sent: Sunday, December 02, 2007 12:47 PM
To: [email protected]
Subject: RE: [flexcoders] Application without MXML: Is it possible?
I was already aware of that, but forgoing the use of UIComponents is not
really an option for me.
I don't see why the Flex team couldn't build a minimal set of defaults into
the Application class that would allow it to be used outside of MXML. But
absent that, I think the API docs should clearly indicate that the only
practical way to instantiate and use the class is through MXML.
Alex Harui <[EMAIL PROTECTED]> wrote:
Not all applications have to have mx:Application at the top level.
You can start with Sprite if you want. Thats what happens when you create an
ActionScript project in Flex Builder. But then you cant u! se most of the mx:
components.
---------------------------------
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Dave
Glasser
Sent: Saturday, December 01, 2007 2:06 PM
To: [email protected]
Subject: Re: [flexcoders] Application without MXML: Is it possible?
I looked at the generated actionscript and it does look like there's a
lot going on, and it's not worth trying to make it work without MXML. Maybe
I'll log a bug report requesting that they say in the API doc that the
Application class can only (as a practical ! matter) be used via the
<mx:Application> MXML tag.
hank williams <[EMAIL PROTECTED]> wrote:
> Is what I'm trying to do impossible, at least without adding some
amount of setup code that is normally generated by the MXML preprocessor and
isn't documented anywhere? __
As I understand it, this is exactly correct. If you compile an MXML
with the option on that generates actionscript (I forget how you do
this) you will see a lot of generated code even in an MXML hello
world.
Regards,
Han