Damon et al,
I'd rather consider that the "official line" be one of
"apply your own pragmatism". Rather than enforce a rule, understand
exactly what you're trying to achieve ... for me, that's maintainability and
clarity of code, rather than any purist ideal.
Separation of content and code can be taken on many levels;
on an extreme level it would suggest "thou shalt not put code into MXML
ever". However, if that then means that a piece of obvious code
- like say a method that clears the text in an input field and broadcasts
an event - is scurried away into an external file, then have you improved the
clarity of your code (ie can someone read it and understand it as easily)
? Or have you introduced abstraction that in turn introduces an
opportunity for confusion.
When something becomes it's extreme, it becomes it's
opposite -- so if people invest TOO much time and effort into code behind
classes, helper classes, etc, then all of a sudden the very thing they're trying
to achieve, clarity, is lost within complexity.
I'd advocate that really what we're doing is performing the
age-old refactorings of "Extract Method" and "Extract Class". We'll start
by putting things inline in event handlers, eg click="...code here....", then
we'll extract method to get click="callMyMethod()" where callMyMethod() resides
on the MXML inline, because it is encapsulated there. Finally, we'll find
we have a bunch of methods, or we have methods that don't deserve to be
encapsulated by the MXML Class, and so we'll factor them out into additional
classes, like ShoppingCarts, APRCalculators, etc, etc.
I think if you apply that pragmatism to when to extract
things into other classes, and apply that pragmatism with some understanding of
how to build object-based systems with the correct attention to cohesion and
decoupling, then the clarity will take care of itself.
If you just blindly follow some rules that some idiot wrote
in a book ;) without some thought behind where that rule may or not make sense,
then you're never going to be happy that you've got it right.
For me, I care about code clarity more than anything else
... can someone else sit down at your code, and quickly find their way around it
because it is logically organised ? If they can do that, then you
have expressed your design intent through code that both machine and human can
understand. All else follows that.
Apologies if any of the above sounds like teaching you to
suck eggs. I neither think there's a right answer here, nor do I feel
so strongly about this that I'm wishing to enter into big long spirited debate
on it. Whatever other people say is right too.
:)
Best,
Steven
--
Steven
Webster
Practice Director (Rich
Internet Applications)
Macromedia Consulting
EMEA
Office: + 44 (0) 131 338
6108
Mobile: +44 (0) 7917 428
947
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Damon E. Farnham
Sent: 03 November 2005 03:48
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] To code-behind or not to code-behind?Jules:Quoting from Steve and Alistair's Developing Rich Clients with Macromedia Flex book (p.57):"Developers should generally avoid inline ActionScript where possible; instead, they should refactor code into external classes imported at compile-time."While prototyping, and perhaps for small, exceptional cases, in-line AS is probably a reasonable approach, however the "rule" expressed above certainly creates a more easily managed configuration within a production environment.Hope this helps.Regards,Damon-----Original Message-----
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Julian Suggate
Sent: Wednesday, November 02, 2005 7:31 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] To code-behind or not to code-behind?Gidday everyone,Years back, I wrote php scripts with code embedded in the html and it led to maintenance hassles. Since then, I've migrated to Java and now .NET and what I liked about their models was the ability to separate the code into "code-behind", something done quite elegantly in ASP.NET. These eliminated a lot of the maintenance problems I'd encountered earlier with PHP.So when I saw macromedia's examples of mxml with <mx:Script>...</mx:Script> blocks embedded directly into the mxml, I immediately searched for a way to avoid this. I found that i could add a source=".." attribute to the mx:Script element and the AS code would be included by the compiler from an external file at compile time. The IDE was even smart enough that any elements I'd defined with id attributes in the mxml showed up with intellisense in the included AS file (I am using Flex Builder 2, not sure if FB1.5 had that feature or not).But now I'm having second thoughts. It kinda feels like going against the grain. I don't want to carry old biases into a new paradigm unnecessarily. I read an article by Aral Balkan (of ARP fame) endorsing the code-behind approach quite strongly, but by the same token, all sample apps from the Cairngorm team freely mix mxml and AS code, as do examples from macromedia themselves.I note though, that the Cairngorm framework itself is all pure AS; it is only the sample apps that use inline actionscript.I can't seem to find a best practice anywhere, because for every framework/example/article I find that seems to hint at one way of doing things, I find another one that suggests the opposite! Has anyone else with more Flex experience than me answered this question, particularly in terms of which approach is easier to maintain?At this stage, any hints would be appreciated!TIA,Jules
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
| Web site design development | Computer software development | Software design and development |
| Macromedia flex |
YAHOO! GROUPS LINKS
- Visit your group "flexcoders" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
