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 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 > <mailto: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.t > xt <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/> . > > > > > > > > > ________________________________ > > > > > > > > > > > > > > -- > > Flexcoders Mailing List > > FAQ: > http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.t > xt <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 > > > > > > > > > > > > > > > > > ------------------------ 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 > <http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM> > > -------------------------------------------------------------- > ------~-> > > -- > Flexcoders Mailing List > FAQ: > http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.t > xt <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 > > > > > SPONSORED LINKS > Web site design development > <http://groups.yahoo.com/gads?t=ms&k=Web+site+design+developme > nt&w1=Web+site+design+development&w2=Software+design+and+devel > opment&w3=Macromedia+flex&w4=Software+development+best+practic > e&c=4&s=131&.sig=FkTWphZzV9mFulU7V3u7pQ> Software design > and development > <http://groups.yahoo.com/gads?t=ms&k=Software+design+and+devel > opment&w1=Web+site+design+development&w2=Software+design+and+d > evelopment&w3=Macromedia+flex&w4=Software+development+best+pra > ctice&c=4&s=131&.sig=w0jnvy4gyxC04c4dhRnw6A> > Macromedia flex > <http://groups.yahoo.com/gads?t=ms&k=Macromedia+flex&w1=Web+si > te+design+development&w2=Software+design+and+development&w3=Ma > cromedia+flex&w4=Software+development+best+practice&c=4&s=131& > .sig=XXu7YeegB3Vi-5Qngf6oNQ> > Software development best practice > <http://groups.yahoo.com/gads?t=ms&k=Software+development+best > +practice&w1=Web+site+design+development&w2=Software+design+an > d+development&w3=Macromedia+flex&w4=Software+development+best+ > practice&c=4&s=131&.sig=ZT_U6e_iPgXSriY_dI9nIg> > > ________________________________ > > 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/