|
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: [email protected]
> [mailto:[email protected]] On
Behalf Of JesterXL
> Sent: Wednesday, November 02, 2005 8:27 PM
>
To: [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]
>
> 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
YAHOO! GROUPS LINKS
|
