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

Thu, 03 Nov 2005 15:45:36 -0800

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 I think 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 of a 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 WAYYYYYYY more dynamic.
 
----- Original Message -----
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 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"
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: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-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/> .
> >
> >
> > ________________________________
> >
> >
>
>
>
> --
> 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
>
>
>
>
>
>
>


------------------------ 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/







--
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





--
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



Reply via email to