I actually was concerned about the HOW and the WHY. I wanted to find out why doing it that way was a good solution or why someone else's solution would be better or more viable. And if the proposed solution was good, was how I intended to implement that solution the right way.
I completely agree that having Abstract and Interface classes just to accomplish modularity is basically creating a code management problem. The only reason it was seriously being considered was to allow the development of seperate module swfs, that need to use the same base classes (ie models, command and value objects), without having to worry about code duplication and errors/conflicts when module swf are being loaded in the main shell application. I've had problems in the past with Flash and RSLs plus I still have some concerns about potential RSL caching and how to overcome that (I think it can be easily overcome with a proper rollout strategy), so I was a little hestitant to pursue that idea. However, from your post and Erik's (plus my own nagging suspicion), I think having the base code in an external SWC and using that as an RSL is the right was to go. Derrick --- In [email protected], "Anatole Tartakovsky" <[EMAIL PROTECTED]> wrote: > > Derreck > Your post concentrates around answers on HOW to use interfaces and > abstract classes to make large applications. I believe there is another > question that we sometimes forget to ask. > > WHY? The main reason for interfaces uses is to allow multiple > implementations. Abstract classes are also serving the same goal. You stated > you are in application development - I do not think multiple implementations > are typical - we do not use interfaces at all as they become additional > point of maintenance and errors. If you need to get stron typing to > application code you can use SWC in external link mode and get everything > resolved. After all, linking the external library with value object is > indistinguishable (short of errors) from linking interface to it. > > The second use of interfaces is to generalize access. Those interfaces > belong to the shared library. they are going to be minimal and closely > guarded. > > We are making generic ant task that includes Eric's suggestion on reducing > the RSL sizes. It works across modules and apps to reduce the sizes of RSLs > automatically. I will post a note when it is available. > > > Sincerely, > Anatole Tartakovsky > www.faratasystems.com > > > > > On 9/20/06, EECOLOR <[EMAIL PROTECTED]> wrote: > > > > Hello, > > > > the way we handle this is as follows: > > > > We have one library swc that holds our code base. We have an application > > file that contains all basic application code. This application is compiled > > with the option -link-report=linkreport.xml. All separate modules are > > compiled with the option -load-externs, this option allows you to have the > > required classes in your classpath for type checking, but leaves all > > available classes out (the ones in the basic application). > > > > > > Greetz Erik > > > > > > > -- 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/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> 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/
