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: [email protected]
> [mailto:[EMAIL PROTECTED] On Behalf Of Julian Suggate
> Sent: Thursday, November 03, 2005 1:40 PM
> To: [email protected]
> 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: [email protected]
> > [mailto:[EMAIL PROTECTED] On Behalf Of JesterXL
> > Sent: Wednesday, November 02, 2005 8:27 PM
> > To: [email protected]
> <mailto:[email protected]>
> > Subject: Re: [flexcoders] To code-behind or not to
> code-behind?
> >
> > What's a helper object?
> >
> > ----- Original Message -----
> > From: "Roger Gonzalez" < [EMAIL PROTECTED]>
> > To: <[email protected]>
> > 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: [email protected]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of
> Julian Suggate
> > > Sent: Wednesday, November 02, 2005 7:31 PM
> > > To: [email protected]
> <mailto:[email protected]>
> > > Subject: [flexcoders] To code-behind or not to code-behind?
> > >
> > > Gidday everyone,
> > >
> > > Years back, I wrote php scripts with code embedded in the
> > > html and it led to maintenance hassles. Since then, I've
> > > migrated to Java and now .NET and what I liked about their
> > > models was the ability to separate the code into
> > > "code-behind", something done quite elegantly in ASP.NET.
> > > These eliminated a lot of the maintenance problems I'd
> > > encountered earlier with PHP.
> > >
> > > So when I saw macromedia's examples of mxml with
> > > <mx:Script>...</mx:Script> blocks embedded directly into the
> > > mxml, I immediately searched for a way to avoid
> this. I found
> > > that i could add a source=".." attribute to the mx:Script
> > > element and the AS code would be included by the compiler
> > > from an external file at compile time. The IDE was
> even smart
> > > enough that any elements I'd defined with id attributes in
> > > the mxml showed up with intellisense in the included AS file
> > > (I am using Flex Builder 2, not sure if FB1.5 had that
> > > feature or not).
> > >
> > > But now I'm having second thoughts. It kinda feels
> like going
> > > against the grain. I don't want to carry old biases into a
> > > new paradigm unnecessarily. I read an article by Aral Balkan
> > > (of ARP fame) endorsing the code-behind approach quite
> > > strongly, but by the same token, all sample apps from the
> > > Cairngorm team freely mix mxml and AS code, as do examples
> > > from macromedia themselves.
> > >
> > > I note though, that the Cairngorm framework itself is all
> > > pure AS; it is only the sample apps that use inline
> actionscript.
> > >
> > > I can't seem to find a best practice anywhere, because for
> > > every framework/example/article I find that seems to hint at
> > > one way of doing things, I find another one that
> suggests the
> > > opposite! Has anyone else with more Flex experience than me
> > > answered this question, particularly in terms of which
> > > approach is easier to maintain?
> > >
> > > At this stage, any hints would be appreciated!
> > >
> > > TIA,
> > > Jules
> > >
> > >
> > > --
> > > Flexcoders Mailing List
> > > FAQ:
> >
> http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.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/
