Re: [flexcoders] To code-behind or not to code-behind?

Thu, 03 Nov 2005 14:50:05 -0800

Stephen,
 
Thanks for taking the time to reply. I agree that the iterative approach you describe is a good way to design new applications from the ground up. Pattern-overuse at the start of a project are like "solutions looking for a problem" to quote one of my team-mates. However, we are looking to port a large, existing application from Flash to Flex (~50,000 lines of AS2). We already have performed a lot of the "extract method" and MVC type refactorings that you refer to and our codebase is relatively mature. We have a complete micro-architecture with multiple tiers on the client. All of our client-side business objects and controllers and services have already been factored out into their own classes. But our View layer is rather brittle.
 
We have recently wanted to mature the application further in a direction we have ignored until now: UI flexibility. Ideally, reskinning the application should not be a big task, but with our current implementation we may be looking at a couple months of work. So while code readability and maintainability are very important to us, they must also be balanced with a healthy dose of flexibility and the ability to re-skin, preferably without touching any logic at all. In my experience, flexibility often comes at the expense of readability, as does efficiency.
 
So what we are really wondering is, bearing in mind that our goals are the same as those you mention but that we also require flexibility and the ability to reskin our own custom controls, should we be using code behind or inline AS?
 
Thanks again,
 
Jules
 
On 11/4/05, Steven Webster <[EMAIL PROTECTED]> wrote:
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: [email protected] [mailto: [email protected]] On Behalf Of Damon E. Farnham
Sent: 03 November 2005 03:48
To: [email protected]
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: [email protected] [mailto:[email protected]] On Behalf Of Julian Suggate
Sent: Wednesday, November 02, 2005 7:31 PM
To: [email protected]
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





--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com


YAHOO! GROUPS LINKS



Reply via email to