|
With Flex 2 interfaces are the mainstream approach
- however, with static linking it is catch-22 - you need to include
implementation at the same time you build "base" which pretty much erases
separation of the code. It minimizes the size of the distribution and eliminates
dependencies issues (DLL hell) at very high cost of full rebuild. Any sizable
project schedule would be affected as the project size grows .Finally, some
of us had a bit too much fun with dynamic properties and methods and would not
give up on these "bad habits" any time soon.
I believe that packaging is one of the sides of the
Flex that can seriously affect the development cycle - both in terms of
developers productivity and functionality of the final product. RSL and dynamic
code seemed to me as an only alternative to the conventional builds and
traditional development cycle toward RAD for large scale/multi-developers
projects.
However, for majority of the pilot/midsize projects
the interface approach is definetly preferable. Also, with true interface
implementations, it would be benefitial to use that approach along with
hierarchical RSLs.
Thank you
Anatole Tartakovsky
----- Original Message -----
Sent: Monday, February 13, 2006 2:34
PM
Subject: Re: [flexcoders] Spltting up
code (best practice)
>But my
favorite (which requires a bit more work) is to make your application
implement an interface that you define:
I think this is a very good way
also. As far as includes, don't laugh but, I would lean away from this
technique because Flex isn't C.
I have started using a Manager class to
'register' components on intertwined main apps.
public final class ExpressionsPaneManager
{
private static var
library:ExpressionsLibraryPane;
/**
*
*/
public
static function getLibraryPane():ExpressionsLibraryPane
{
return library;
}
/**
*
*/
public static
function
registerLibraryPane(value:ExpressionsLibraryPane):void
{
library = value;
}
}
I
know there are other ways but this seems to be a really fun way of doing it. I
really depends on your implementation. Just like in oop patterns, you can't
always apply a 'certain' pattern to a ceratin problem. You have to mix the
implementation abit.
This provides two major things for me;
1.
Even though static, it creates an interface for your main application. You are
defining your 'main' components/modules of the application. (obviously this
will not work in all situations)
2. You are creating a single acces
point for all components to share. There is no dependency on a setThis(this)
routine. (but I also use this in different situations) I would use the
setRef(this) when you are not dealing with aggragated components, more of a
smaller view into a single component or small app.
Anyway, I can't
bring myself to use include but, I have not programmed C either
:)
Peace, Mike
PS One other thing that starts to get interesting
is; your manager class could start to do things even more intelligent like
manage component transitions, positions, states. Real fun, look at is as the
center of the wheel and your application forms fan out around it like
spokes.
On 2/13/06, Anatole
Tartakovsky <[EMAIL PROTECTED]> wrote:
#include is the same format as C
ie
#include "../mycode/code.as"
HTH,
Anatole
-----
Original Message -----
Sent:
Monday, February 13, 2006 1:48 PM
Subject:
RE: [flexcoders] Spltting up code (best practice)
Got any place I
can read more about RSLs? And using the #include…how do you include in my
example?
So the form would have #include ../../main.mxml while the
main would have #include com/mine/form.mxml?
_________________________________________
Jonathan
Miranda
Flexible
Master of the Web
"In the game
of chess, it's important to never let your opponent see your
pieces."
You can use #include statement
the same way you would use it in C. That pretty much solves the issues of
code separation. The way you slice it is very much up to your
preferences - as it does not really serves the code partitioning, but
rather readability purposes.
The fun begins when you decide
to abandon static code linkage and go dynamic. That is important in the
event when you develop application thet would be dynamically configured by
the end-users. You need to package your software in a way it can be
assembled in the run-time - with minimal overhead.
That very much call for usage
of RSLs for large components, data-driven UI and ability to dynamically
create/cache compiled code. Depending if you are interested in
"readability" or "dynamics" of the code different solutions can be
derived
----- Original Message -----
Sent:
Monday, February 13, 2006 12:10 PM
Subject:
[flexcoders] Spltting up code (best practice)
Alright, I have a main.mxml
application file and an actionscript file that gets included. In the
application let's say I have a Form, that I want to pull out into
another file. What's the best practice for how this is accomplished if
the Form needs to reference id's in the main app, functions in the
actionscript file, and the app/as to the form.
I've already got
some bad habits with coldfusion, rather get into the habit of doing this
"the right way" – if there is one.
_________________________________________
Jonathan
Miranda
Flexible
Master of the Web
"In the game of chess, it's
important to never let your opponent see your
pieces."
--
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
|
