RE: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?)
Dear to the heart, indeed! A recent lane-split passed 5 cars recently on I66 has me revisiting the pattern in this lane-splitting-illegal state of VA. Luckily the whole experience was one of braking, because I'd have only had ~30hp to put to the road if acceleration was involved : ) "So of course, I wanted something equipped to drive across arctic tundra. It just makes me feel better." Good times, good times! From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Roger GonzalezSent: Thursday, November 03, 2005 1:20 PMTo: flexcoders@yahoogroups.comSubject: RE: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?) OK, we're analysing this to a level it was never meant to be analysed at. This often seems to happen, though. I find design patterns to beincredibly useful for attaching names to common code constructs (bothfor describing how something was implemented or how it could/should beimplemented) but I find them unhelpful whenever they're wedged into acontext where the potential user of the pattern hasn't previously workedon the problem and personally experienced the pain of coding themselvesinto a corner. They get locked up in a terror that they aren'tfollowing the pattern to the letter, and freak out when the patternisn't a 100% match for what they're trying to do. I once saw some codethat had a class factory that produced class factories, for no reasonother than they didn't dare put two factory methods on the same object,because the pattern didn't say that was ok.To bring it back to an area near and dear to my heart, its likeexplaining lanesplitting techniques to a motorcyclist who lives in arural area with no traffic. Sure, there are lots of best practices andpotential gotchas and what-to-do-when, but they're only interesting froma theoretical perspective if you're never in that situation. However,they'll make a lot more sense -after- a cell-phone-babbling soccer momin a Maibatsu Monstrosity suddenly realizes she needs to exit soon andcuts you off, forcing you to threshold brake, release, swerve a fulllanes-width in front of a bus to the next gap between lanes, and thenaccelerate so hard you pull a small wheelie off a rain-slicked Bott'sDot while still leaned over, three cylinders of bottled impatiencehowling as you feed 120hp to the ground via a sticky rubber contactpatch the size of a deck of cards[1] (Ah, Lanesplitting Pattern #4, on-and off-ramps are like tributaries in the traffic stream, they causeturbulence...)-rg[1] Part of my employment agreement is that I must checkpoint my codeinto source control a bit more frequently than my sane coworkers. -- 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 Software design and development Macromedia flex Software development best practice 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.
RE: [flexcoders] To code-behind or not to code-behind?
just stuff AS into our mxml. If it bites us later we'll just refactor No, man, dont do that. In 1.5, the 32k problem *will* bite you. Just start off putting the AS into a helper class (static or otherwise). Then youll do: MyHelperClass.myFunction() From the beginning instead of having to do it later. Trust me. Tracy From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Julian Suggate Sent: Thursday, November 03, 2005 10:02 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] To code-behind or not to code-behind? Thanks for your time everyone. Because we have barely scratched the surface with Flex, I am asking stupid questions probably ... apologies if it's coming across as obtuse. I think I wasgetting confused because mxml is the class. Call me slow on the uptake! I only just clicked that separating the code from the mxml makes no difference semantically-- seems more of an ideological debate than anything else. I'm not a big fan of those!I can see why Steven's initial response was kind of blase. I think we'll go with the grain on this one and just stuff AS into our mxml. If it bites us later we'll just refactor. On 11/4/05, Steven Webster [EMAIL PROTECTED] wrote: The existence of ActionScript code in the MXML file or not, has never impacted on the strategy for skinning. Good to hear. For the psycho-analytically inclined, you can see the process of paradigm-shifting going on in glorious technicolour as I continue to ask silly questions and then back down ;-) But you're probably accustomed to that on this list. 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 Software design and development Macromedia flex Software development best practice 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.
Re: [flexcoders] To code-behind or not to code-behind?
I was also raised .NET / Java and keep my code files the same name as the component and put them in a mx:Script source=ComponentName.as / It's probably personal perference but Flex Builder and the Eclipse plugin for mxml can't help at all with *.as formatting or any sort of tag completion if you keep your script in the mxml file. That... plus I love being able tosee the versions of the mxml files apart from the script in source control... shows me where we messed up in designing the UI higher version number in an mxml file means bad design up front. And now for the inflamatory material IT'S JUST CLEANER... WHY WOULDN'T YOU KEEP YOUR CODE FILE SEPARATE???!?!?!?!?? *snickers* On 11/2/05, Julian Suggate [EMAIL PROTECTED] wrote: 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 thegrain. 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 hintswould be appreciated! TIA, Jules--Flexcoders Mailing ListFAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 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. -- 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 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.
RE: [flexcoders] To code-behind or not to code-behind?
So what's the best practices for this process of seperating the MXML and AS? I'm just getting up to speed with Cairngorm so I figure it would be good to get into the right habits now. I would like to note, however, that one can go into a resursive perceived optimization extrme with just about any model, until the effort at not ever repeating anything actually becomes a burden in itself...so I don't believe there is a purest/extremist view that should be applied to any model. There's a threshold of waiting in the wings while designing where it just becomes the right time to seperate into an abstractino; granted, I realize code-behind isn't necessarily exactly like an actual pure design (but then again after 3 years of ASP.Net I realize how overkill it can be and I'm finding much more comfort in Java designs; webservices). I've did an IBuySpy store and found after considering it's implementation after 2 years to be just outright un-elegant. C#.Net and VB.Net is more elegant as far as what .Net can really do...and Web Services is really the best target for that and I find MXML consumes them quite well thank you. The way I see it, the majority of the future is Web Services WDSL and Flex Presentation Tier (long term even as long as there is a 3D modelling project for the future of Flash). -r --- Matt Horn [EMAIL PROTECTED] wrote: Guilty. The examples in the Flex documentation usually mix AS and MXML... but we do this mostly for readability. Plus, we want people to be able to just copy a sample out of the doc and paste it into a file and run it -- without worrying about file structures, relative vs absolute paths, etc. This doesn't mean we shouldn't try to improve on the samples somehow... matt horn flex docs From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Julian Suggate Sent: Wednesday, November 02, 2005 10: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 YAHOO! GROUPS LINKS *Visit your group flexcoders http://groups.yahoo.com/group/flexcoders on the web. *To unsubscribe from this group, send an email to: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service http://docs.yahoo.com/info/terms/ . __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com Yahoo! Groups Sponsor
RE: [flexcoders] To code-behind or not to code-behind?
Title: Message 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 SuggateSent: Wednesday, November 02, 2005 7:31 PMTo: flexcoders@yahoogroups.comSubject: [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 thegrain. 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 hintswould 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.
RE: [flexcoders] To code-behind or not to code-behind?
Title: Message 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. FarnhamSent: 03 November 2005 03:48To: flexcoders@yahoogroups.comSubject: 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 SuggateSent: Wednesday, November 02, 2005 7:31 PMTo: flexcoders@yahoogroups.comSubject: [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 (
RE: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?)
Douglas, Got me thinking thoughin OOP terms just what is a helper object? I don't recall seeing these in say Java, or maybe they have a different name. View Helper was one of the Core J2EE Patterns, that would most usually have been implemented as a custom-tag in JSP. It's nothing magical, just a pattern to be aware you can refactor towards. Sometimes patterns make the simple sound magical. But the View Helper ain't that. It's simple. Steven -- Steven Webster Practice Director (Rich Internet Applications) Macromedia Consulting EMEA Office: + 44 (0) 131 338 6108 Mobile: +44 (0) 7917 428 947 Yahoo! Groups Sponsor ~-- Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM ~- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?)
Yeah, I understand the ViewHelper. The more generic 'helper object' though I have not heard of. So, View Helper is a helper obejct. So, say I have a Front Controller object that needs some 'help', would I apply a Front Controller Helper object? Obvioulsy this depends on the problem to solve, abstractly though is this idea sound? I'm no master of patterns, but sounds like the view helper may come from a larger parent pattern called Helper or something. Does UK English really use ain't? lol! DK On 11/3/05, Steven Webster [EMAIL PROTECTED] wrote: Douglas, Got me thinking thoughin OOP terms just what is a helper object? I don't recall seeing these in say Java, or maybe they have a different name. View Helper was one of the Core J2EE Patterns, that would most usually have been implemented as a custom-tag in JSP. It's nothing magical, just a pattern to be aware you can refactor towards. Sometimes patterns make the simple sound magical. But the View Helper ain't that. It's simple. Steven -- Steven Webster Practice Director (Rich Internet Applications) Macromedia Consulting EMEA Office: + 44 (0) 131 338 6108 Mobile: +44 (0) 7917 428 947 -- 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 -- Douglas Knudsen http://www.cubicleman.com this is my signature, like it? Yahoo! Groups Sponsor ~-- Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM ~- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
RE: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?)
See my previous reply for a concrete example. I just meant an extra object that encapsulates a well defined piece of functionality, aggregated into your application. I wasn't alluding to any particular GoF-blessed pattern, but if you really need to get pedantic, the application is probably best described as using the bridge pattern. Helpers can be anything from flyweights to factories. I personally consider it bad mojo to have the application's implementation details exposed, so I abstract out pieces of functionality through interfaces, build helper classes that implement those interfaces, and only pass the interfaces around. This is a bit of leftover habit from keeping gigantic C++ apps from turning into dependency hairballs. An additional benefit is that you can then move those reusable bits off into RSLs, decoupling development. If you only change implementation code but keep the interface constant, you don't need to recompile clients of the interface. This sort of development has some small development overhead in extra interfaces and whatnot, but pays off as your code scales. -rg -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Douglas Knudsen Sent: Thursday, November 03, 2005 8:13 AM To: flexcoders@yahoogroups.com Subject: Re: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?) Yeah, I understand the ViewHelper. The more generic 'helper object' though I have not heard of. So, View Helper is a helper obejct. So, say I have a Front Controller object that needs some 'help', would I apply a Front Controller Helper object? Obvioulsy this depends on the problem to solve, abstractly though is this idea sound? I'm no master of patterns, but sounds like the view helper may come from a larger parent pattern called Helper or something. Does UK English really use ain't? lol! DK On 11/3/05, Steven Webster [EMAIL PROTECTED] wrote: Douglas, Got me thinking thoughin OOP terms just what is a helper object? I don't recall seeing these in say Java, or maybe they have a different name. View Helper was one of the Core J2EE Patterns, that would most usually have been implemented as a custom-tag in JSP. It's nothing magical, just a pattern to be aware you can refactor towards. Sometimes patterns make the simple sound magical. But the View Helper ain't that. It's simple. Steven -- Steven Webster Practice Director (Rich Internet Applications) Macromedia Consulting EMEA Office: + 44 (0) 131 338 6108 Mobile: +44 (0) 7917 428 947 -- 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 -- Douglas Knudsen http://www.cubicleman.com this is my signature, like it? Yahoo! Groups Sponsor ~-- Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM -- --~- -- 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 Yahoo! Groups Sponsor ~-- Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM ~- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?)
Just so I can get some context, it seems the Yahoo! Maps API follows this route; the majority of the controls all follow the 5 main interfaces. Is that an example of a real-world usage scenario using what you describe below in a Flex context? - Original Message - From: Roger Gonzalez [EMAIL PROTECTED] To: flexcoders@yahoogroups.com Sent: Thursday, November 03, 2005 12:03 PM Subject: RE: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?) See my previous reply for a concrete example. I just meant an extra object that encapsulates a well defined piece of functionality, aggregated into your application. I wasn't alluding to any particular GoF-blessed pattern, but if you really need to get pedantic, the application is probably best described as using the bridge pattern. Helpers can be anything from flyweights to factories. I personally consider it bad mojo to have the application's implementation details exposed, so I abstract out pieces of functionality through interfaces, build helper classes that implement those interfaces, and only pass the interfaces around. This is a bit of leftover habit from keeping gigantic C++ apps from turning into dependency hairballs. An additional benefit is that you can then move those reusable bits off into RSLs, decoupling development. If you only change implementation code but keep the interface constant, you don't need to recompile clients of the interface. This sort of development has some small development overhead in extra interfaces and whatnot, but pays off as your code scales. -rg -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Douglas Knudsen Sent: Thursday, November 03, 2005 8:13 AM To: flexcoders@yahoogroups.com Subject: Re: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?) Yeah, I understand the ViewHelper. The more generic 'helper object' though I have not heard of. So, View Helper is a helper obejct. So, say I have a Front Controller object that needs some 'help', would I apply a Front Controller Helper object? Obvioulsy this depends on the problem to solve, abstractly though is this idea sound? I'm no master of patterns, but sounds like the view helper may come from a larger parent pattern called Helper or something. Does UK English really use ain't? lol! DK On 11/3/05, Steven Webster [EMAIL PROTECTED] wrote: Douglas, Got me thinking thoughin OOP terms just what is a helper object? I don't recall seeing these in say Java, or maybe they have a different name. View Helper was one of the Core J2EE Patterns, that would most usually have been implemented as a custom-tag in JSP. It's nothing magical, just a pattern to be aware you can refactor towards. Sometimes patterns make the simple sound magical. But the View Helper ain't that. It's simple. Steven -- Steven Webster Practice Director (Rich Internet Applications) Macromedia Consulting EMEA Office: + 44 (0) 131 338 6108 Mobile: +44 (0) 7917 428 947 -- 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 -- Douglas Knudsen http://www.cubicleman.com this is my signature, like it? Yahoo! Groups Sponsor ~-- Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM -- --~- -- 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 -- 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 Yahoo! Groups Sponsor ~-- Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM ~- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
RE: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?)
OK, we're analysing this to a level it was never meant to be analysed at. The ViewHelper is a name borrowed from the Core J2EE Pattern catalogue. As far as I'm aware, it's just a name, it's not a more generic or specific form of another pattern, it's just an observation that sometimes it makes sense to take functionality out of a big thing, and stick it in a smaller thing. If you abstract functionality out of a Front Controller and stick it in a class that you think helps it; give it a name that makes sense ? There are no pattern gods that will strike you down for not calling it a Front Controller Helper. Code communicates intent. So whatever you intend, communicate it. Steven -- Steven Webster Practice Director (Rich Internet Applications) Macromedia Consulting EMEA Office: + 44 (0) 131 338 6108 Mobile: +44 (0) 7917 428 947 -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Douglas Knudsen Sent: 03 November 2005 16:13 To: flexcoders@yahoogroups.com Subject: Re: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?) Yeah, I understand the ViewHelper. The more generic 'helper object' though I have not heard of. So, View Helper is a helper obejct. So, say I have a Front Controller object that needs some 'help', would I apply a Front Controller Helper object? Obvioulsy this depends on the problem to solve, abstractly though is this idea sound? I'm no master of patterns, but sounds like the view helper may come from a larger parent pattern called Helper or something. Does UK English really use ain't? lol! DK On 11/3/05, Steven Webster [EMAIL PROTECTED] wrote: Douglas, Got me thinking thoughin OOP terms just what is a helper object? I don't recall seeing these in say Java, or maybe they have a different name. View Helper was one of the Core J2EE Patterns, that would most usually have been implemented as a custom-tag in JSP. It's nothing magical, just a pattern to be aware you can refactor towards. Sometimes patterns make the simple sound magical. But the View Helper ain't that. It's simple. Steven -- Steven Webster Practice Director (Rich Internet Applications) Macromedia Consulting EMEA Office: + 44 (0) 131 338 6108 Mobile: +44 (0) 7917 428 947 -- 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 -- Douglas Knudsen http://www.cubicleman.com this is my signature, like it? Yahoo! Groups Sponsor ~-- Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM -- --~- -- 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 Yahoo! Groups Sponsor ~-- Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM ~- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
RE: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?)
OK, we're analysing this to a level it was never meant to be analysed at. This often seems to happen, though. I find design patterns to be incredibly useful for attaching names to common code constructs (both for describing how something was implemented or how it could/should be implemented) but I find them unhelpful whenever they're wedged into a context where the potential user of the pattern hasn't previously worked on the problem and personally experienced the pain of coding themselves into a corner. They get locked up in a terror that they aren't following the pattern to the letter, and freak out when the pattern isn't a 100% match for what they're trying to do. I once saw some code that had a class factory that produced class factories, for no reason other than they didn't dare put two factory methods on the same object, because the pattern didn't say that was ok. To bring it back to an area near and dear to my heart, its like explaining lanesplitting techniques to a motorcyclist who lives in a rural area with no traffic. Sure, there are lots of best practices and potential gotchas and what-to-do-when, but they're only interesting from a theoretical perspective if you're never in that situation. However, they'll make a lot more sense -after- a cell-phone-babbling soccer mom in a Maibatsu Monstrosity suddenly realizes she needs to exit soon and cuts you off, forcing you to threshold brake, release, swerve a full lanes-width in front of a bus to the next gap between lanes, and then accelerate so hard you pull a small wheelie off a rain-slicked Bott's Dot while still leaned over, three cylinders of bottled impatience howling as you feed 120hp to the ground via a sticky rubber contact patch the size of a deck of cards[1] (Ah, Lanesplitting Pattern #4, on- and off-ramps are like tributaries in the traffic stream, they cause turbulence...) -rg [1] Part of my employment agreement is that I must checkpoint my code into source control a bit more frequently than my sane coworkers. Yahoo! Groups Sponsor ~-- Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM ~- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?)
Anyone else break into a cold sweat reading that last part? Whew... that was nice, John Woo style! - Original Message - From: Roger Gonzalez [EMAIL PROTECTED] To: flexcoders@yahoogroups.com Sent: Thursday, November 03, 2005 1:20 PM Subject: RE: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?) OK, we're analysing this to a level it was never meant to be analysed at. This often seems to happen, though. I find design patterns to be incredibly useful for attaching names to common code constructs (both for describing how something was implemented or how it could/should be implemented) but I find them unhelpful whenever they're wedged into a context where the potential user of the pattern hasn't previously worked on the problem and personally experienced the pain of coding themselves into a corner. They get locked up in a terror that they aren't following the pattern to the letter, and freak out when the pattern isn't a 100% match for what they're trying to do. I once saw some code that had a class factory that produced class factories, for no reason other than they didn't dare put two factory methods on the same object, because the pattern didn't say that was ok. To bring it back to an area near and dear to my heart, its like explaining lanesplitting techniques to a motorcyclist who lives in a rural area with no traffic. Sure, there are lots of best practices and potential gotchas and what-to-do-when, but they're only interesting from a theoretical perspective if you're never in that situation. However, they'll make a lot more sense -after- a cell-phone-babbling soccer mom in a Maibatsu Monstrosity suddenly realizes she needs to exit soon and cuts you off, forcing you to threshold brake, release, swerve a full lanes-width in front of a bus to the next gap between lanes, and then accelerate so hard you pull a small wheelie off a rain-slicked Bott's Dot while still leaned over, three cylinders of bottled impatience howling as you feed 120hp to the ground via a sticky rubber contact patch the size of a deck of cards[1] (Ah, Lanesplitting Pattern #4, on- and off-ramps are like tributaries in the traffic stream, they cause turbulence...) -rg [1] Part of my employment agreement is that I must checkpoint my code into source control a bit more frequently than my sane coworkers. -- 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 Yahoo! Groups Sponsor ~-- Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM ~- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?)
yeah right! I even ran to the kawasaki web site just to peek...neat little flash there. Ok, sorry for sounding all pedantic, was just curious is all. I'm certainly far from the pattern spouting zealot. The ideas do make me miss college/academia though :( DK On 11/3/05, JesterXL [EMAIL PROTECTED] wrote: Anyone else break into a cold sweat reading that last part? Whew... that was nice, John Woo style! - Original Message - From: Roger Gonzalez [EMAIL PROTECTED] To: flexcoders@yahoogroups.com Sent: Thursday, November 03, 2005 1:20 PM Subject: RE: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?) OK, we're analysing this to a level it was never meant to be analysed at. This often seems to happen, though. I find design patterns to be incredibly useful for attaching names to common code constructs (both for describing how something was implemented or how it could/should be implemented) but I find them unhelpful whenever they're wedged into a context where the potential user of the pattern hasn't previously worked on the problem and personally experienced the pain of coding themselves into a corner. They get locked up in a terror that they aren't following the pattern to the letter, and freak out when the pattern isn't a 100% match for what they're trying to do. I once saw some code that had a class factory that produced class factories, for no reason other than they didn't dare put two factory methods on the same object, because the pattern didn't say that was ok. To bring it back to an area near and dear to my heart, its like explaining lanesplitting techniques to a motorcyclist who lives in a rural area with no traffic. Sure, there are lots of best practices and potential gotchas and what-to-do-when, but they're only interesting from a theoretical perspective if you're never in that situation. However, they'll make a lot more sense -after- a cell-phone-babbling soccer mom in a Maibatsu Monstrosity suddenly realizes she needs to exit soon and cuts you off, forcing you to threshold brake, release, swerve a full lanes-width in front of a bus to the next gap between lanes, and then accelerate so hard you pull a small wheelie off a rain-slicked Bott's Dot while still leaned over, three cylinders of bottled impatience howling as you feed 120hp to the ground via a sticky rubber contact patch the size of a deck of cards[1] (Ah, Lanesplitting Pattern #4, on- and off-ramps are like tributaries in the traffic stream, they cause turbulence...) -rg [1] Part of my employment agreement is that I must checkpoint my code into source control a bit more frequently than my sane coworkers. -- 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 -- 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 -- Douglas Knudsen http://www.cubicleman.com this is my signature, like it? Yahoo! Groups Sponsor ~-- Fair play? Video games influencing politics. Click and talk back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/nhFolB/TM ~- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] To code-behind or not to code-behind?
This is an interesting approach. Let me see if I get this right:
1) create components that handle generic behaviour (eg a nav bar that remembers the currently selected link)
2) hide each component behind an interface
3) create mxml that lays out these components, adding visual assets etc as necessary
4) create helper objects that sit between the mxml and the components? So that the mxml interacts with the helper objects, the helper objects with the components and neither the components nor the mxml know anything about each other. Is that what you mean?
I had never thought about adding the helper objects level of indirection. I have so far tried to make my components define abstract behaviour and then use mxml for creating instances of them and assigning visual skins/styles. This is one reason why I've wanted to use code-behind: so that two different applications can define different graphics but both import the same actionscript. Perhaps I'm going about this the wrong way.
JesterXL, in your daily work is it or has it beena requirement for your components to be re-skinnable? If so, are you able to share how you accomplish this? I completely understand if you can't reveal such details!
Thanks everyone for their responses so far.
Jules
On 11/3/05, Roger Gonzalez [EMAIL PROTECTED] wrote:
?xml version=1.0 encoding=utf-8?mx:Application xmlns:mx=
http://www.macromedia.com/2005/mxmlxmlns=*VisToggle id=vis thing={words} /mx:Label id=words text=Hello, world! /mx:Button id=toggle label=toggle it click=
vis.toggle() //mx:Application// VisToggle.as: helper object for twiddling visibility of displayobjectspackage{import flash.display.DisplayObject;public class VisToggle
{ public function toggle() { thing.visible = !thing.visible; } public var thing:DisplayObject;}}Pretty lame example, but you get the idea.I like to make classes (perhaps even a custom base for the application)
that implement interfaces, and then have helper objects that know how tooperate on those interfaces, and don't know anything about theapplication itself.I have a pet theory that if you use mx.core.Application.application
anywhere, you are building a messy nightmare that will be difficult tomaintain.YMMV.-rg -Original Message- From: flexcoders@yahoogroups.com
[mailto:flexcoders@yahoogroups.com] On Behalf Of JesterXL Sent: Wednesday, November 02, 2005 8:27 PM To:
flexcoders@yahoogroups.com Subject: Re: [flexcoders] To code-behind or not to code-behind? What's a helper object? - Original Message - From: Roger Gonzalez
[EMAIL PROTECTED] To: flexcoders@yahoogroups.com Sent: Wednesday, November 02, 2005 11:22 PM
Subject: RE: [flexcoders] To code-behind or not to code-behind? You might want to search the archives, we had a long chat about this recently. The conclusion that I personally push is to avoid relying on script
source inclusion but rather to either a) create custom base classes and derive your MXML components from them, and/or b) aggregate helper objects, and/or c) factor the MXML into metacomponents with well defined interfaces.
I find that inline OR external script snippets get messy and out of control, and you're generally better off following standard OO programming. Another way of looking at it is that if your MXML is looking more like
AS code than like MXML, you're probably better off refactoring things. When any given MXML class is down to 10-15 lines of script, things look pretty clean, and it seems better to just put it inline.
(personal opinions here, we argue this one internally quite a bit!) -rg -Original Message- From: flexcoders@yahoogroups.com
[mailto:flexcoders@yahoogroups.com] 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
Re: [flexcoders] To code-behind or not to code-behind?
Hah ignoring the inflamatory statements :-) The version numbering is a very good reason to keep them separate. One thing you might be happy about for Flex2 is that it gives intellisense/code hints within the same file (as you'd hope!) but also across included script files. So that's a bonus. I've run into problems naming the .as files the same as the mxml in FB2. Not sure if it's just my install, but the compiler almost seems to crash (internal error). This might get fixed for future releases I guess. Jules On 11/4/05, Clint Modien [EMAIL PROTECTED] wrote: I was also raised .NET / Java and keep my code files the same name as the component and put them in a mx:Script source=ComponentName.as / It's probably personal perference but Flex Builder and the Eclipse plugin for mxml can't help at all with *.as formatting or any sort of tag completion if you keep your script in the mxml file. That... plus I love being able tosee the versions of the mxml files apart from the script in source control... shows me where we messed up in designing the UI higher version number in an mxml file means bad design up front. And now for the inflamatory material IT'S JUST CLEANER... WHY WOULDN'T YOU KEEP YOUR CODE FILE SEPARATE???!?!?!?!?? *snickers* On 11/2/05, Julian Suggate [EMAIL PROTECTED] wrote: 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 thegrain. 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 hintswould be appreciated! TIA, Jules--Flexcoders Mailing ListFAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 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. --Flexcoders Mailing ListFAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txtSearch Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 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. -- 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 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.
Re: [flexcoders] To code-behind or not to code-behind?
Robert, I completely agree with everything you just said! If we can't see a clear winner, we'll just pick one way, any way as long as it works and refactor later if we have to. But since our team's at an early stage of Flex dev it seems like a good idea to pick up as many tips as we can before we get started :-) BTW I think Flash could be in trouble without 3D too. Jules On 11/3/05, Robert Thompson [EMAIL PROTECTED] wrote: So what's the best practices for this process ofseperating the MXML and AS?I'm just getting up to speed with Cairngorm so I figure it would be good to get into the right habitsnow.I would like to note, however, that one can go into aresursive perceived optimization extrme with justabout any model, until the effort at not ever repeating anything actually becomes a burden initself...so I don't believe there is apurest/extremist view that should be applied to anymodel.There's a threshold of waiting in the wings while designing where it just becomes the right time toseperate into an abstractino; granted, I realizecode-behind isn't necessarily exactly like an actualpure design (but then again after 3 years of ASP.Net I realize how overkill it can be and I'm finding muchmore comfort in Java designs; webservices).I've didan IBuySpy store and found after considering it'simplementation after 2 years to be just outrightun-elegant.C#.Net and VB.Net is more elegant as faras what .Net can really do...and Web Services isreally the best target for that and I find MXMLconsumes them quite well thank you.The way I see it, the majority of the future is Web Services WDSL and Flex Presentation Tier (long termeven as long as there is a 3D modelling project forthe future of Flash).-r--- Matt Horn [EMAIL PROTECTED] wrote: Guilty. The examples in the Flex documentation usually mix AS and MXML... but we do this mostly for readability. Plus, we want people to be able to just copy a sample out of the doc and paste it into a file and run it -- without worrying about file structures, relative vs absolute paths, etc. This doesn't mean we shouldn't try to improve on the samples somehow... matt horn flex docs From: flexcoders@yahoogroups.com [mailto: flexcoders@yahoogroups.com] On Behalf Of Julian Suggate Sent: Wednesday, November 02, 2005 10: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 YAHOO! GROUPS LINKS *Visit your group flexcoders http://groups.yahoo.com/group/flexcoders on the web. *To unsubscribe from this group, send an email to: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]?subject=Unsubscribe *Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service http://docs.yahoo.com/info/terms/ . __Yahoo! FareChase: Search multiple travel sites in one click.http://farechase.yahoo.com Yahoo! Groups Sponsor ~-- Get Bzzzy! (real
Re: [flexcoders] To code-behind or not to code-behind?
Unfortunately, no. A lot of what I'm doing is
being utilized on internal apps to generate data; creating forms for people to
input specific releavant data associated with existing data.
Therefore, design is of the least bit
importance. Granted, even by doing nothing but using the haloTheme, and
extending the base Flex classes, my app still looks better than an HTML
equivalent; at least done in the same time frame with the same amount of man
hours, so that's cool I guess.
The component sets I used to create, however, were
for designers, so I just made it dead simple for them since that was my
audience, not developers, and gave every graphical symbol there for the
editing. This made it very easy to break if the changed the thumb
ofa slider to something really big and a sliderbar to something really
small; so I just made my measurement code flexible.
On the flipside, making things code friendly in
Flex/ActionScript isn't too bad either; just copy what mx.controls.Button does;
place skin variables as public up top, and make everything an asset instead of
runtime drawing. Case in point ActionStep, the open source Flash component
framework based on the OpenStep framework is drawin entirely in
ActionScript. While this is great from a pure coding standpoint, it
doesn't really help those traditional designers who have assets already, or
designs created that couldn't be created with a drawing API alone. Again,
my target audience is production artists that have insane designs given to them
from Photoshop/AfterEffects/Illustrator, and are expected to implement them into
Flex. So, if everything's an asset, just make a new asset.
...again, since I'm extending the base classes, I
still get all the base CSS styles for free.
All of this is moot since Flash Player 8.5 makes
things insanely easier and WAYYY more dynamic.
- Original Message -
From: Julian Suggate
To: flexcoders@yahoogroups.com
Sent: Thursday, November 03, 2005 4:40 PM
Subject: Re: [flexcoders] To code-behind or not to
code-behind?
This is an interesting approach. Let me see if I get this right:
1) create components that handle generic behaviour (eg a nav bar that
remembers the currently selected link)
2) hide each component behind an interface
3) create mxml that lays out these components, adding visual assets etc as
necessary
4) create "helper objects" that sit between the mxml and the components? So
that the mxml interacts with the helper objects, the helper objects with the
components and neither the components nor the mxml know anything about each
other. Is that what you mean?
I had never thought about adding the "helper objects" level of indirection.
I have so far tried to make my components define abstract behaviour and then use
mxml for creating instances of them and assigning visual skins/styles. This is
one reason why I've wanted to use code-behind: so that two different
applications can define different graphics but both import the same
actionscript. Perhaps I'm going about this the wrong way.
JesterXL, in your daily work is it or has it beena requirement for
your components to be re-skinnable? If so, are you able to share how you
accomplish this? I completely understand if you can't reveal such details!
Thanks everyone for their responses so far.
Jules
On 11/3/05, Roger
Gonzalez [EMAIL PROTECTED]
wrote:
?xml
version="1.0" encoding="utf-8"?mx:Application xmlns:mx="
http://www.macromedia.com/2005/mxml"xmlns="*"VisToggle
id="vis" thing="{words}" /mx:Label id="words" text="Hello, world!"
/mx:Button id="toggle" label="toggle it" click=" vis.toggle()"
//mx:Application// VisToggle.as: helper object for
twiddling visibility of displayobjectspackage{import
flash.display.DisplayObject;public class VisToggle{
public function toggle()
{ thing.visible =
!thing.visible; } public var
thing:DisplayObject;}}Pretty lame example, but you get the
idea.I like to make classes (perhaps even a custom base for the
application) that implement interfaces, and then have helper objects that
know how tooperate on those interfaces, and don't know anything about
theapplication itself.I have a pet theory that if you use
mx.core.Application.application anywhere, you are building a messy
nightmare that will be difficult
tomaintain.YMMV.-rg -Original
Message- From: flexcoders@yahoogroups.com
[mailto:flexcoders@yahoogroups.com] On
Behalf Of JesterXL Sent: Wednesday, November 02, 2005 8:27 PM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] To code-behind or not to
code-behind? What's a helper object? -
Original Message - From: "Roger Gonzalez" [EMAIL PROTECTED]
To: flexcoders@yahoogroups.com
Sent: Wednesday, November 02, 2005 11:22 PM Subject: RE: [flexcoders]
Re: [flexcoders] To code-behind or not to code-behind?
Stephen, Thanks for taking the time to reply. I agree thatthe iterativeapproach 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, preferablywithout 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 asthose you mentionbut 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: flexcoders@yahoogroups.com [mailto: flexcoders@yahoogroups.com] On Behalf Of Damon E. FarnhamSent: 03 November 2005 03:48To: flexcoders@yahoogroups.comSubject: 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
RE: [flexcoders] To code-behind or not to code-behind?
Yeah, that's mostly what I mean. I think the important bit is to keep
peers from knowing about each other.
For example, imagine an app something like this:
Application
Scoreboard id=s /
Player id=p1 scoreboard={s} /
Player id=p2 scoreboard={s} /
Game id=g players={[p1, p2]} scoreboard={s} /
/Application
It might be easy to add a third player, because its parameterized. Or
maybe you have an IPlayer interface, and you write a different
implementation that talks to a multiplayer server. Think about how much
more of a pain it would be if deep inside Game something was calling
mx.core.Applicaiton.application.p1.getName() or something.
Its possible to do a lot of handing out references in a totally
declarative manner like this, but sometimes you might need to have a
creationComplete or initialize handler to call methods to pass around
handles (i.e. g.addPlayer( p1 ) or something).
-rg
-Original Message-
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Julian Suggate
Sent: Thursday, November 03, 2005 1:40 PM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] To code-behind or not to code-behind?
This is an interesting approach. Let me see if I get this right:
1) create components that handle generic behaviour (eg a nav
bar that remembers the currently selected link)
2) hide each component behind an interface
3) create mxml that lays out these components, adding visual
assets etc as necessary
4) create helper objects that sit between the mxml and the
components? So that the mxml interacts with the helper
objects, the helper objects with the components and neither
the components nor the mxml know anything about each other.
Is that what you mean?
I had never thought about adding the helper objects level
of indirection. I have so far tried to make my components
define abstract behaviour and then use mxml for creating
instances of them and assigning visual skins/styles. This is
one reason why I've wanted to use code-behind: so that two
different applications can define different graphics but both
import the same actionscript. Perhaps I'm going about this
the wrong way.
JesterXL, in your daily work is it or has it been a
requirement for your components to be re-skinnable? If so,
are you able to share how you accomplish this? I completely
understand if you can't reveal such details!
Thanks everyone for their responses so far.
Jules
On 11/3/05, Roger Gonzalez [EMAIL PROTECTED] wrote:
?xml version=1.0 encoding=utf-8?
mx:Application xmlns:mx=
http://www.macromedia.com/2005/mxml
http://www.macromedia.com/2005/mxml
xmlns=*
VisToggle id=vis thing={words} /
mx:Label id=words text=Hello, world! /
mx:Button id=toggle label=toggle it click=
vis.toggle() /
/mx:Application
// VisToggle.as: helper object for twiddling visibility
of display
objects
package
{
import flash.display.DisplayObject;
public class VisToggle
{
public function toggle()
{
thing.visible = !thing.visible;
}
public var thing:DisplayObject;
}
}
Pretty lame example, but you get the idea.
I like to make classes (perhaps even a custom base for
the application)
that implement interfaces, and then have helper objects
that know how to
operate on those interfaces, and don't know anything about the
application itself.
I have a pet theory that if you use
mx.core.Application.application
anywhere, you are building a messy nightmare that will
be difficult to
maintain. YMMV.
-rg
-Original Message-
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of JesterXL
Sent: Wednesday, November 02, 2005 8:27 PM
To: flexcoders@yahoogroups.com
mailto:flexcoders@yahoogroups.com
Subject: Re: [flexcoders] To code-behind or not to
code-behind?
What's a helper object?
- Original Message -
From: Roger Gonzalez [EMAIL PROTECTED]
To: flexcoders@yahoogroups.com
Sent: Wednesday, November 02, 2005 11:22 PM
Subject: RE: [flexcoders] To code-behind or not to
code-behind?
You might want to search the archives, we had a long
chat about this
recently.
The conclusion that I personally push is to avoid
relying on script
source inclusion but rather to either
a) create custom base classes and derive your MXML components
from them,
and/or
b) aggregate helper objects, and/or
c) factor the MXML into metacomponents with well
defined interfaces.
I find that inline OR external script snippets get
messy and out
Re: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?)
ps no offense about comparing you to my ex-girlfriend's mother lol ;-) i'm sure you're not a crazy feminist lesbian On 11/4/05, Julian Suggate [EMAIL PROTECTED] wrote: Damn that wasgood! Perhaps we should start calling you Speedy Gonzalez :-) You sound like my ex-girlfriend's mother. She was totally sick on a bike. Used to get off the back of her wheels with legs like spaghetti and a head full of thunderous ear-splitting panic. Took me right back. Mate that used to wake me up in the mornings that's for sure. Cheers, Jules On 11/4/05, Roger Gonzalez [EMAIL PROTECTED] wrote: OK, we're analysing this to a level it was never meant to be analysed at.This often seems to happen, though.I find design patterns to be incredibly useful for attaching names to common code constructs (bothfor describing how something was implemented or how it could/should beimplemented) but I find them unhelpful whenever they're wedged into a context where the potential user of the pattern hasn't previously workedon the problem and personally experienced the pain of coding themselvesinto a corner.They get locked up in a terror that they aren'tfollowing the pattern to the letter, and freak out when the pattern isn't a 100% match for what they're trying to do.I once saw some codethat had a class factory that produced class factories, for no reasonother than they didn't dare put two factory methods on the same object, because the pattern didn't say that was ok.To bring it back to an area near and dear to my heart, its likeexplaining lanesplitting techniques to a motorcyclist who lives in arural area with no traffic.Sure, there are lots of best practices and potential gotchas and what-to-do-when, but they're only interesting froma theoretical perspective if you're never in that situation.However,they'll make a lot more sense -after- a cell-phone-babbling soccer mom in a Maibatsu Monstrosity suddenly realizes she needs to exit soon andcuts you off, forcing you to threshold brake, release, swerve a fulllanes-width in front of a bus to the next gap between lanes, and then accelerate so hard you pull a small wheelie off a rain-slicked Bott'sDot while still leaned over, three cylinders of bottled impatiencehowling as you feed 120hp to the ground via a sticky rubber contactpatch the size of a deck of cards[1](Ah, Lanesplitting Pattern #4, on- and off-ramps are like tributaries in the traffic stream, they causeturbulence...)-rg[1] Part of my employment agreement is that I must checkpoint my codeinto source control a bit more frequently than my sane coworkers. Yahoo! Groups Sponsor ~--Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM~---Flexcoders Mailing ListFAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txtSearch Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/* To unsubscribe from this group, send an email to: [EMAIL PROTECTED]* Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ -- 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 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.
Re: helper object? what's that? (was Re: [flexcoders] To code-behind or not to code-behind?)
Damn that wasgood! Perhaps we should start calling you Speedy Gonzalez :-) You sound like my ex-girlfriend's mother. She was totally sick on a bike. Used to get off the back of her wheels with legs like spaghetti and a head full of thunderous ear-splitting panic. Took me right back. Mate that used to wake me up in the mornings that's for sure. Cheers, Jules On 11/4/05, Roger Gonzalez [EMAIL PROTECTED] wrote: OK, we're analysing this to a level it was never meant to be analysed at.This often seems to happen, though.I find design patterns to be incredibly useful for attaching names to common code constructs (bothfor describing how something was implemented or how it could/should beimplemented) but I find them unhelpful whenever they're wedged into a context where the potential user of the pattern hasn't previously workedon the problem and personally experienced the pain of coding themselvesinto a corner.They get locked up in a terror that they aren'tfollowing the pattern to the letter, and freak out when the pattern isn't a 100% match for what they're trying to do.I once saw some codethat had a class factory that produced class factories, for no reasonother than they didn't dare put two factory methods on the same object, because the pattern didn't say that was ok.To bring it back to an area near and dear to my heart, its likeexplaining lanesplitting techniques to a motorcyclist who lives in arural area with no traffic.Sure, there are lots of best practices and potential gotchas and what-to-do-when, but they're only interesting froma theoretical perspective if you're never in that situation.However,they'll make a lot more sense -after- a cell-phone-babbling soccer mom in a Maibatsu Monstrosity suddenly realizes she needs to exit soon andcuts you off, forcing you to threshold brake, release, swerve a fulllanes-width in front of a bus to the next gap between lanes, and then accelerate so hard you pull a small wheelie off a rain-slicked Bott'sDot while still leaned over, three cylinders of bottled impatiencehowling as you feed 120hp to the ground via a sticky rubber contactpatch the size of a deck of cards[1](Ah, Lanesplitting Pattern #4, on- and off-ramps are like tributaries in the traffic stream, they causeturbulence...)-rg[1] Part of my employment agreement is that I must checkpoint my codeinto source control a bit more frequently than my sane coworkers. Yahoo! Groups Sponsor ~--Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM~---Flexcoders Mailing ListFAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txtSearch Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/* To unsubscribe from this group, send an email to: [EMAIL PROTECTED]* Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ -- 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 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.
RE: [flexcoders] To code-behind or not to code-behind?
Jules, Many thanks for your replyto cut to the quick So what we are really wondering is, bearing in mind that our goals are the same asthose you mentionbut that we also require flexibility and the ability to reskin our own custom controls, should we be using code behind or inline AS? So I'm not quite understanding your challenge here; how the existence of ActionScript inline orin a code-behind class is impacting upon how you skin your controls ? Is there a snippet you can share that might elaborate ? We've skinned some pretty non-Flex looking applications (check out the mortgage calculator at www.if.com for example) where a huge majority of the skinning is achieved through the use of CSS styles, the rest through many of the usual HTML-esque tricks of getting margins right,and dropping background images in places where we need a graphic rather than a colour. The existence of ActionScript code in the MXML file or not, has never impacted on the strategy for skinning. Do you havean example you could give so we could have a more concrete discussion ? I'm out of office mostof tomorrow, so forgive me ifI don't get a reply to you... Best, Steven -- Steven Webster Practice Director (Rich Internet Applications) Macromedia Consulting EMEA Office: + 44 (0) 131 338 6108 Mobile: +44 (0) 7917 428 947 -- 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 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.
Re: [flexcoders] To code-behind or not to code-behind?
Gah! This is nail-biting stuff. I thought I was going to make this easy switch from the Flash IDE to mxml but the feeling has been growing on me for the past few days, and what you say just confirms it, that rather than being only a tool for laying out visual assets,mxml is actually an entirely new programming construct that I can lean on.
My eval of Flex2 is kinda premature because we can't start porting from Flash to Flex until the beta comes out at least, so within a week or two I'll have to move back onto Flash for a few months, but I can see that I'm going to be spending a lot of early mornings coming to grips with this new powerful environment :-)
baffled at smiling about early mornings/
Jules
On 11/4/05, Roger Gonzalez [EMAIL PROTECTED] wrote:
Yeah, that's mostly what I mean.I think the important bit is to keeppeers from knowing about each other.
For example, imagine an app something like this:ApplicationScoreboard id=s /Player id=p1 scoreboard={s} /Player id=p2 scoreboard={s} /
Game id=g players={[p1, p2]} scoreboard={s} //ApplicationIt might be easy to add a third player, because its parameterized.Ormaybe you have an IPlayer interface, and you write a different
implementation that talks to a multiplayer server.Think about how muchmore of a pain it would be if deep inside Game something was callingmx.core.Applicaiton.application.p1.getName() or something.Its possible to do a lot of handing out references in a totally
declarative manner like this, but sometimes you might need to have acreationComplete or initialize handler to call methods to pass aroundhandles (i.e. g.addPlayer( p1 ) or something).-rg
--
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
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.
Re: [flexcoders] To code-behind or not to code-behind?
Thanks for this JesterXL (I continually write your handle as JesterXML heh). We will definitely be extending the base classes ourselves also so that gives us styles for free. I'm wondering how to create custom List-based controls that don't look like Lists (mostly for the dataProvider functionality) but without the source code I'm kinda fumbling in the dark here.
All good Ithink I've started rambling better start coding :-) Thanks for your advice everyone, this has been a great thread.
CHeers,
Jules
On 11/4/05, JesterXL [EMAIL PROTECTED] wrote:
Unfortunately, no. A lot of what I'm doing is being utilized on internal apps to generate data; creating forms for people to input specific releavant data associated with existing data.
Therefore, design is of the least bit importance. Granted, even by doing nothing but using the haloTheme, and extending the base Flex classes, my app still looks better than an HTML equivalent; at least done in the same time frame with the same amount of man hours, so that's cool I guess.
The component sets I used to create, however, were for designers, so I just made it dead simple for them since that was my audience, not developers, and gave every graphical symbol there for the editing. This made it very easy to break if the changed the thumb ofa slider to something really big and a sliderbar to something really small; so I just made my measurement code flexible.
On the flipside, making things code friendly in Flex/ActionScript isn't too bad either; just copy what mx.controls.Button does; place skin variables as public up top, and make everything an asset instead of runtime drawing. Case in point ActionStep, the open source Flash component framework based on the OpenStep framework is drawin entirely in ActionScript. While this is great from a pure coding standpoint, it doesn't really help those traditional designers who have assets already, or designs created that couldn't be created with a drawing API alone. Again, my target audience is production artists that have insane designs given to them from Photoshop/AfterEffects/Illustrator, and are expected to implement them into Flex. So, if everything's an asset, just make a new asset.
...again, since I'm extending the base classes, I still get all the base CSS styles for free.
All of this is moot since Flash Player 8.5 makes things insanely easier and WAYYY more dynamic.
- Original Message -
From: Julian Suggate
To: flexcoders@yahoogroups.com
Sent: Thursday, November 03, 2005 4:40 PM
Subject: Re: [flexcoders] To code-behind or not to code-behind?
This is an interesting approach. Let me see if I get this right:
1) create components that handle generic behaviour (eg a nav bar that remembers the currently selected link)
2) hide each component behind an interface
3) create mxml that lays out these components, adding visual assets etc as necessary
4) create helper objects that sit between the mxml and the components? So that the mxml interacts with the helper objects, the helper objects with the components and neither the components nor the mxml know anything about each other. Is that what you mean?
I had never thought about adding the helper objects level of indirection. I have so far tried to make my components define abstract behaviour and then use mxml for creating instances of them and assigning visual skins/styles. This is one reason why I've wanted to use code-behind: so that two different applications can define different graphics but both import the same actionscript. Perhaps I'm going about this the wrong way.
JesterXL, in your daily work is it or has it beena requirement for your components to be re-skinnable? If so, are you able to share how you accomplish this? I completely understand if you can't reveal such details!
Thanks everyone for their responses so far.
Jules
On 11/3/05, Roger Gonzalez [EMAIL PROTECTED]
wrote:
?xml version=1.0 encoding=utf-8?mx:Application xmlns:mx=
http://www.macromedia.com/2005/mxmlxmlns=*VisToggle id=vis thing={words} /mx:Label id=words text=Hello, world! /mx:Button id=toggle label=toggle it click=
vis.toggle() //mx:Application// VisToggle.as: helper object for twiddling visibility of displayobjectspackage{import flash.display.DisplayObject;public class VisToggle
{ public function toggle() { thing.visible = !thing.visible; } public var thing:DisplayObject;}}Pretty lame example, but you get the idea.I like to make classes (perhaps even a custom base for the application)
that implement interfaces, and then have helper objects that know how tooperate on those interfaces, and don't know anything about theapplication itself.I have a pet theory that if you use mx.core.Application.application
anywhere, you are building a messy nightmare that will be difficult tomaintain.YMMV.-rg -Original Message- From:
flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of JesterXL Sent: Wednesday, November 02, 2005 8:27 PM
Re: [flexcoders] To code-behind or not to code-behind?
Thanks for your time everyone. Because we have barely scratched the surface with Flex, I am asking stupid questions probably ... apologies if it's coming across as obtuse. I think I wasgetting confused because mxml is the class. Call me slow on the uptake! I only just clicked that separating the code from the mxml makes no difference semantically-- seems more of an ideological debate than anything else. I'm not a big fan of those!I can see why Steven's initial response was kind of blase. I think we'll go with the grain on this one and just stuff AS into our mxml. If it bites us later we'll just refactor. On 11/4/05, Steven Webster [EMAIL PROTECTED] wrote: The existence of ActionScript code in the MXML file or not, has never impacted on the strategy for skinning. Good to hear. For the psycho-analytically inclined, you can see the process of paradigm-shifting going on in glorious technicolour as I continue to ask silly questions and then back down ;-) But you're probably accustomed to that on this list. 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 Software design and development Macromedia flex Software development best practice 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.
Re: [flexcoders] To code-behind or not to code-behind?
Took me 3 weeks to get that the root MXML tag was actually the class I was extending. That through me for a loop. - Original Message - From: Julian Suggate To: flexcoders@yahoogroups.com Sent: Thursday, November 03, 2005 10:02 PM Subject: Re: [flexcoders] To code-behind or not to code-behind? Thanks for your time everyone. Because we have barely scratched the surface with Flex, I am asking stupid questions probably ... apologies if it's coming across as obtuse. I think I wasgetting confused because "mxml is the class". Call me slow on the uptake! I only just clicked that separating the code from the mxml makes no difference semantically-- seems more of an ideological debate than anything else. I'm not a big fan of those!I can see why Steven's initial response was kind of blase. I think we'll go with the grain on this one and just stuff AS into our mxml. If it bites us later we'll just refactor. On 11/4/05, Steven Webster [EMAIL PROTECTED] wrote: The existence of ActionScript code in the MXML file or not, has never impacted on the strategy for skinning. Good to hear. For the psycho-analytically inclined, you can see the process of paradigm-shifting going on in glorious technicolour as I continue to ask silly questions and then back down ;-) But you're probably accustomed to that on this list. Jules -- 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 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.
Re: [flexcoders] To code-behind or not to code-behind?
Dude, you should see the shiz I put together for work. Custom form elements as list items. Look into DataSelector; he worked great in Flash, and works great in Flex too. Basically, it's an API to make your main (abstract) class have the power of a List. You get dataProvider integration, and all the dataProvider events when things change. From there you, can display the list data however your imagination can imagine. I've been working on a blog entry #4 about it that actually shows it because it's so cool what you can do with it. For now, check the old entries, and think of "doing whatever you want"; don't think "list item"; that's too small. Think "whatever the heck I want!". http://www.jessewarden.com/archives/2005/06/dataselector_da.html http://www.jessewarden.com/archives/2005/10/using_dataselec.html http://www.jessewarden.com/archives/2005/10/using_dataselec.html - Original Message - From: Julian Suggate To: flexcoders@yahoogroups.com Sent: Thursday, November 03, 2005 6:45 PM Subject: Re: [flexcoders] To code-behind or not to code-behind? Thanks for this JesterXL (I continually write your handle as JesterXML heh). We will definitely be extending the base classes ourselves also so that gives us styles for free. I'm wondering how to create custom List-based controls that don't look like Lists (mostly for the dataProvider functionality) but without the source code I'm kinda fumbling in the dark here. All good Ithink I've started rambling better start coding :-) Thanks for your advice everyone, this has been a great thread. CHeers, Jules On 11/4/05, JesterXL [EMAIL PROTECTED] wrote: Unfortunately, no. A lot of what I'm doing is being utilized on internal apps to generate data; creating forms for people to input specific releavant data associated with existing data. Therefore, design is of the least bit importance. Granted, even by doing nothing but using the haloTheme, and extending the base Flex classes, my app still looks better than an HTML equivalent; at least done in the same time frame with the same amount of man hours, so that's cool I guess. The component sets I used to create, however, were for designers, so I just made it dead simple for them since that was my audience, not developers, and gave every graphical symbol there for the editing. This made it very easy to break if the changed the thumb ofa slider to something really big and a sliderbar to something really small; so I just made my measurement code flexible. On the flipside, making things code friendly in Flex/ActionScript isn't too bad either; just copy what mx.controls.Button does; place skin variables as public up top, and make everything an asset instead of runtime drawing. Case in point ActionStep, the open source Flash component framework based on the OpenStep framework is drawin entirely in ActionScript. While this is great from a pure coding standpoint, it doesn't really help those traditional designers who have assets already, or designs created that couldn't be created with a drawing API alone. Again, my target audience is production artists that have insane designs given to them from Photoshop/AfterEffects/Illustrator, and are expected to implement them into Flex. So, if everything's an asset, just make a new asset. ...again, since I'm extending the base classes, I still get all the base CSS styles for free. All of this is moot since Flash Player 8.5 makes things insanely easier and WAYYY more dynamic. - Original Message - From: Julian Suggate To: flexcoders@yahoogroups.com Sent: Thursday, November 03, 2005 4:40 PM Subject: Re: [flexcoders] To code-behind or not to code-behind? This is an interesting approach. Let me see if I get this right: 1) create components that handle generic behaviour (eg a nav bar that remembers the currently selected link) 2) hide each component behind an interface 3) create mxml that lays out these components, adding visual assets etc as necessary 4) create "helper objects" that sit between the mxml and the components? So that the mxml interacts with the helper objects, the helper objects with the components and neither the components nor the mxml know anything about each other. Is that what you mean? I had never thought about adding the "helper objects" level of indirection. I have so far tried to make my components define abstract behaviour and then use mxml for creating instances of them and assigning visual skins/styles. This is one reason why I've wanted to use code-behind: so that two different applications can define different graphics but both import the same actionscript. Perhaps I'm going about this the wrong way. JesterXL, in your daily work is it or has it beena requirement for your
Re: [flexcoders] To code-behind or not to code-behind?
BLEH! BTW, skinning, to me, does not mean CSS margins. Skinning to me means abadoning Halo, and replacing every visual element with your own, typically created by a designer. For now, this consists of: - embed asset in inline AS - create control manually OR set skin invalidate as necessarey Flex 2 as well as Flash Player 8.5 make this sick. With just AS3, you can do this at RUNTIME, as well as supporting dynamic skins. While the concept of "user configurable themes" only works on utility applications, there are still clients who will pay for it, regardless of it actually adds any value to the app, and as such, this is now possible. Flex 2 also has way more fantastic skinning via CSS as well as some really nice base classes. In short; INLINE ALL THE WAY BABY! - Original Message - From: Julian Suggate To: flexcoders@yahoogroups.com Sent: Thursday, November 03, 2005 10:02 PM Subject: Re: [flexcoders] To code-behind or not to code-behind? Thanks for your time everyone. Because we have barely scratched the surface with Flex, I am asking stupid questions probably ... apologies if it's coming across as obtuse. I think I wasgetting confused because "mxml is the class". Call me slow on the uptake! I only just clicked that separating the code from the mxml makes no difference semantically-- seems more of an ideological debate than anything else. I'm not a big fan of those!I can see why Steven's initial response was kind of blase. I think we'll go with the grain on this one and just stuff AS into our mxml. If it bites us later we'll just refactor. On 11/4/05, Steven Webster [EMAIL PROTECTED] wrote: The existence of ActionScript code in the MXML file or not, has never impacted on the strategy for skinning. Good to hear. For the psycho-analytically inclined, you can see the process of paradigm-shifting going on in glorious technicolour as I continue to ask silly questions and then back down ;-) But you're probably accustomed to that on this list. 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 Software design and development Macromedia flex Software development best practice 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.
[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 thegrain. 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 hintswould 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 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.
Re: [flexcoders] To code-behind or not to code-behind?
This sucked royally in 1.5. You had to make your AS file a class, AND you had to define the control variables in the AS; meaning, if you used a button with an id of "my_pb", you had to import the mx.controls.Button class, and define the private var my_pb:Button up top... for every damn control. Lame. I know a lot of people find this way of development extremely alien, ecspecially from a Flash development background, but you fall in love eventually. The Cairngorm work my fellow employee's use, however, uses the same approach; external AS filesfor a lot of MXML files. Me personally, in 1.5 land, enjoy AS MXML in one file. I don't, currently, utilize ViewHelpers on any project and had to work into getting used to this. However, it feels great to have my controls my code that handles their event dispatching right there. Guys at work use a lot of code seperation, mainly with very simple ViewHelpers. When it was shown to me, it made a lot of sense as to why you would do that, but I still have the feeling that, for me, my business delegates to massage the data into a globally usable format; an array of objects. So, ViewHelpers, at least currently, seem very unusable to me, thus, I'd still keep AS inline. Things could change. Additionally, most of my projects are new, fresh, and disposable. If we ever were to add features to any of the project(s) I'm working on, it'd be a re-write, so maintaence isn't a consideration. When I compare the amount of Views I have compared with some of the existing applications I've seen at the company I'm contracting with, I realize I'm making extremely complex components that fit into larger applications, so maybe my skillset as a Flash component developer is making me subjective in the maintance realm. ...all I know is, I can open old MXML files I've done in the past, and 1 file clearly shows how it works to me; at least for Views; Application.mxml Controller classes are usually tied into ARP or Cairngorm, so you have to do more digging, but that's usually a lot of ActionScript anyway. Personally, I feel we are still developing best practices. Originally, most Flex developers I felt were Enterprise JSP/Java developers who had a paradigm of thinking and Cairngorm worked well in that. With the influx of .NET/ASP, Flash, and traditional web developers, I think things may keep changing for awhile. - Original Message - From: Julian Suggate To: flexcoders@yahoogroups.com Sent: Wednesday, November 02, 2005 10:31 PM 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 thegrain. 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 hintswould 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
RE: [flexcoders] To code-behind or not to code-behind?
Guilty. The examples in the Flex documentation usually mix AS and MXML... but we do this mostly for readability.Plus, we want people to be able to just copy a sample out of the doc and paste it into a file and run it -- without worrying about file structures, relative vs absolute paths, etc. This doesn't mean we shouldn't try to improve on the samples somehow... matt horn flex docs From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Julian SuggateSent: Wednesday, November 02, 2005 10:31 PMTo: flexcoders@yahoogroups.comSubject: [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 thegrain. 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 hintswould 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.
RE: [flexcoders] To code-behind or not to code-behind?
You might want to search the archives, we had a long chat about this recently. The conclusion that I personally push is to avoid relying on script source inclusion but rather to either a) create custom base classes and derive your MXML components from them, and/or b) aggregate helper objects, and/or c) factor the MXML into metacomponents with well defined interfaces. I find that inline OR external script snippets get messy and out of control, and you're generally better off following standard OO programming. Another way of looking at it is that if your MXML is looking more like AS code than like MXML, you're probably better off refactoring things. When any given MXML class is down to 10-15 lines of script, things look pretty clean, and it seems better to just put it inline. (personal opinions here, we argue this one internally quite a bit!) -rg -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 YAHOO! GROUPS LINKS * Visit your group flexcoders http://groups.yahoo.com/group/flexcoders on the web. * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service http://docs.yahoo.com/info/terms/ . Yahoo! Groups Sponsor ~-- Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM ~- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] To code-behind or not to code-behind?
What's a helper object? - Original Message - From: Roger Gonzalez [EMAIL PROTECTED] To: flexcoders@yahoogroups.com Sent: Wednesday, November 02, 2005 11:22 PM Subject: RE: [flexcoders] To code-behind or not to code-behind? You might want to search the archives, we had a long chat about this recently. The conclusion that I personally push is to avoid relying on script source inclusion but rather to either a) create custom base classes and derive your MXML components from them, and/or b) aggregate helper objects, and/or c) factor the MXML into metacomponents with well defined interfaces. I find that inline OR external script snippets get messy and out of control, and you're generally better off following standard OO programming. Another way of looking at it is that if your MXML is looking more like AS code than like MXML, you're probably better off refactoring things. When any given MXML class is down to 10-15 lines of script, things look pretty clean, and it seems better to just put it inline. (personal opinions here, we argue this one internally quite a bit!) -rg -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 YAHOO! GROUPS LINKS * Visit your group flexcoders http://groups.yahoo.com/group/flexcoders on the web. * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service http://docs.yahoo.com/info/terms/ . -- 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 Yahoo! Groups Sponsor ~-- Fair play? Video games influencing politics. Click and talk back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/nhFolB/TM ~- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
RE: [flexcoders] To code-behind or not to code-behind?
?xml version=1.0 encoding=utf-8?
mx:Application xmlns:mx=http://www.macromedia.com/2005/mxml;
xmlns=*
VisToggle id=vis thing={words} /
mx:Label id=words text=Hello, world! /
mx:Button id=toggle label=toggle it click=vis.toggle() /
/mx:Application
// VisToggle.as: helper object for twiddling visibility of display
objects
package
{
import flash.display.DisplayObject;
public class VisToggle
{
public function toggle()
{
thing.visible = !thing.visible;
}
public var thing:DisplayObject;
}
}
Pretty lame example, but you get the idea.
I like to make classes (perhaps even a custom base for the application)
that implement interfaces, and then have helper objects that know how to
operate on those interfaces, and don't know anything about the
application itself.
I have a pet theory that if you use mx.core.Application.application
anywhere, you are building a messy nightmare that will be difficult to
maintain. YMMV.
-rg
-Original Message-
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of JesterXL
Sent: Wednesday, November 02, 2005 8:27 PM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] To code-behind or not to code-behind?
What's a helper object?
- Original Message -
From: Roger Gonzalez [EMAIL PROTECTED]
To: flexcoders@yahoogroups.com
Sent: Wednesday, November 02, 2005 11:22 PM
Subject: RE: [flexcoders] To code-behind or not to code-behind?
You might want to search the archives, we had a long chat about this
recently.
The conclusion that I personally push is to avoid relying on script
source inclusion but rather to either
a) create custom base classes and derive your MXML components
from them,
and/or
b) aggregate helper objects, and/or
c) factor the MXML into metacomponents with well defined interfaces.
I find that inline OR external script snippets get messy and out of
control, and you're generally better off following standard OO
programming.
Another way of looking at it is that if your MXML is looking more like
AS code than like MXML, you're probably better off refactoring things.
When any given MXML class is down to 10-15 lines of script,
things look
pretty clean, and it seems better to just put it inline.
(personal opinions here, we argue this one internally quite a bit!)
-rg
-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
YAHOO! GROUPS LINKS
* Visit your group flexcoders
http://groups.yahoo.com/group/flexcoders on the web.
* To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
mailto
