I'm sorry, I don't really buy that argument.
What it sounds like you are describing is the creation of a component.
Fine - you can do that in AS3 or MXML; or a mix of the two. Doesn't
really matter which.
Then - surely - for every project you need to stitch together your
components. Because in no two projects are the same components
arranged in the same way.
What I (and others) have been saying is that MXML is a pretty good
solution for that phase - the layout.
I'm not saying MXML is the be-all and end-all. It absolutely isn't. I
really like - and use - AS3. But MXML is _useful_ as part of the
view/layout definition; it's an easy, readable, concise shorthand for
connecting things together. There's no reason you can't use AS3. But
that's no reason to argue _against_ MXML, particularly.
What you seem to be saying is 'but I can achieve the same in AS3 with
a bit of work first'. Fine. What you haven't said is 'and I think
using MXML is a bad idea because...'
I'm not even really sure why this is an argument, and exactly what you
are arguing.
Yes - with a bunch of coding up front - such as you describe - you can
minimise the amount of AS3 you need to write each time.
But I'm describing Flex/AS3/MXML straight out of the box. Why write a
bunch of code up front that you don't actually need to? Why fix what
isn't broken? If you love writing your own libraries - great, go
ahead. If you feel the Flex components don't suit your needs - again,
go ahead. My argument was AS3 is more verbose and less readable for
layout than MXML. That's true however you spin it.
At the root of it, MXML is just AS3. It just goes through a
translation stage first. I'm not clear why it seems to offend you so
much.
What I was answering was Elia's post stating that 'it's crap'. I find
that a poor value-judgement. As I've said in other mails - we use it.
It's a useful tool. There are others. If you choose not to use it,
then that's fine.
I'm pretty sure the original original question was asking about the
situations in which you'd use Flash over Flex, and vice versa, and
what might be the technical reasons for doing so. I think we've
drifted. MXML isn't Flex. AS3 isn't Flash.
Ian
(I think I've had enough of this, now - I just seem to be repeating myself...)
On Thu, Nov 20, 2008 at 9:52 PM, sebastian <[EMAIL PROTECTED]> wrote:
> Hi Ian,
>
> While it is true that to write this code [below] in AS3 it would take more
> lines of code; this is not true once you have done it 'once' and you can
> then re-use your code.
>
> For example: I made a class called 'AdvButton' which extends 'Button' a long
> time ago and I re-use it in all my projects. I then extended the AdvButton
> with another class called 'WrapButton' which accepts a GUI element and
> automatically sizes the invisible button to match, events are defaulted to
> my cross-project standard, and position is matched to passed object...
> Making it so trivial now to add interactive visual elements..
>
> So if I want to array an interface I just call a loop, pass a visual element
> and viola, I am done. Better still, once I write a class that does a
> loop-placement, I can then re-call that same class from any new projects...
>
> So yes: its more work once, but only the first time. Once the AS is written,
> It's very fast and the liens of code to write are super-minimal; just like
> in Flex.
>
> example:
>
> Flash file [with visual assets]
> ^
> |
> Core [extends MovieClip]
> ^
> |
> Navigation [extends extends Sprite]
> ^
> |
> WrapButton [extends AdvButton]
> ^
> |
> AdvButton [extends Button]
> ^
> |
> Button
>
> In my Core all I need to write that is project-specific is:
>
> public function Core ()
> {
> new ProcessXML ("xml/nav.xml",this,"returnFunction");
> }
>
> public function returnFunction (__xmldata:XML):void
> {
> leftNavHolder = new Sprite ();
>
> var margin = 10; //pixels between each nav element
> var vertical = true; //whether the nav is vertical or horizontal
> leftNav = new Navigation (__xmldata,NavItem,leftNavHolder,margin,vertical);
>
> //Where 'NavItem' is a movieclip Class asset in the *.fla that follows
> //established UI standards the Navigation is expecting.
>
> leftNavHolder.x = 20; //screen position X
> leftNavHolder.y = 20; //screen position Y
>
> this.addChild (leftNavHolder);
> }
>
> Where I feel your comparison falls short is that you are assuming that the
> AS2/3 person would code every UI logic from scratch, which is just not
> true!!
>
> I could do the same you implied by making a class that handles all the
> placement, event association and adding children to the timeline and then
> encapsulate that into a programmer-friendly instantiation process:
>
> var myButton:AdvButton = new AdvButton ("UserEvent.CANCEL",true);
> vBox.addChild (myButton);
>
> And if you wanted, you could also include the 'label' as part of it too;
> ((would depend though on context if that would be useful to abstract or
> not.))
>
> Long story short: Once I have this above interaction established, I can now
> create any navigation you want, left aligned, right aligned and with any
> margin I want between what ever visual element I want in just 5 lines of
> code; which can be even less, if you don't mind density...
>
> -=-=-
>
> So in my opinion the real advantages of Flex over Flash for UI/data-binding
> is:
>
> 1. A standard that is commonly shared in the industry, making it easier for
> teams to develop collaboratively. [I pray my system makes sense to anyone,
> but it's still a custom-made system and thus by definition, less
> interchangeable]
>
> 2. A boon for people who are new to Flash and don't have dozens/hundreds of
> pre-made AS classes already made from other projects that they can re-use.
>
> Sincerely,
>
> Sebastian.
>
> Ian Thomas wrote:
>>
>> On Thu, Nov 20, 2008 at 8:30 AM, Elia Morling <[EMAIL PROTECTED]>
>> wrote:
>>
>>> The language itself lends itself to spaghetti coding, because MXML can
>>> easily turn into nesting hell. , unless the coders know what they are
>>> doing.
>>> The benefits of Flex databinding and UI are bogus, if you are an OOP
>>> programmer reusability exists with any OOP language.
>>
>> Bogus?
>>
>> Not at all. The benefits are in speed of development and clarity.
>>
>> It is perfectly possible to replicate databinding in AS3 (after all,
>> the underlying implementation _is_ AS3).
>>
>> But to do so will require considerably more code, and is harder to read.
>>
>> Similarly for the UI - yes, you can replicate everything in MXML's
>> layout in AS3, but it also requires more code and is harder to read.
>>
>> Consider this simple layout example in MXML:
>>
>> <mx:VBox width="100%" horizontalAlign="center">
>> <mx:Label text="Testing"/>
>> <mx:Button label="Cancel" click="dispatchEvent(new
>> UserEvent(UserEvent.CANCEL,true))"/>
>> </mx:VBox>
>>
>> And in AS3:
>>
>> var vbox:VBox=new VBox();
>> vbox.percentWidth=100;
>> vbox.setStyle("horizontalAlign","center");
>>
>> var label:Label=new Label();
>> label.text="Testing";
>> vbox.addChild(label);
>>
>> var button:Button=new Button();
>> button.label="Cancel";
>> button.addEventListener(MouseEvent.CLICK,onCancelClicked,false,0,true);
>> vbox.addChild(button);
>>
>> addChild(vbox);
>>
>> private function onCancelClicked(ev:MouseEvent):void
>> {
>> dispatchEvent(new UserEvent(UserEvent.CANCEL,true));
>> }
>>
>> In what way is the AS3 clearer? In what way is it easier to maintain?
>> In what way is it easier to see how the objects are laid out on the
>> screen just by looking at the code? In what way is it _faster to
>> develop_?
>>
>> In what way is the MXML more spaghetti-like?
>>
>> I agree that - as with any layout language - you can get tangled up by
>> burying the implementation inside the layout. That's the same sort of
>> issue that exists in other languages - for example, PHP. But that's
>> simply about learning how to use it correctly.
>>
>> I think it's foolish to entirely write off a useful syntax/language
>> based on examples written by people who don't understand how to use it
>> properly.
>>
>> But then, I find MXML a useful tool for layout. It's your loss if you
>> don't use it.
>>
>> Ian
>> _______________________________________________
>> Flashcoders mailing list
>> Flashcoders@chattyfig.figleaf.com
>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>>
> _______________________________________________
> Flashcoders mailing list
> Flashcoders@chattyfig.figleaf.com
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
