Re: [Flashcoders] Writing code for big teams
Yes, something like a ViewLocator or a special SectionLocator. Regards Michael On 11/22/06, Ricardo Sánchez <[EMAIL PROTECTED]> wrote: But I need to pass them at least an intrinsic so they can register their class, wouldn't I? On 11/22/06, Ian Thomas <[EMAIL PROTECTED]> wrote: > > Personally I'd pass them interfaces rather than intrinsics (mostly > because interfaces are a standard OOP concept but intrinsics are a > Flash-specific 'hackette'), but that's a matter of personal choice. > > Ian > > On 11/22/06, Ricardo Sánchez <[EMAIL PROTECTED]> wrote: > > I forgot I'm thinking they should also have an intrinsic class for an > object > > with global properties and stuff (not sure about this) > > > > On 11/22/06, Ricardo Sánchez <[EMAIL PROTECTED]> wrote: > > > > > > > Do you think is a good idea to give them this 2 files, or should I > pass > > > them just an intrinsic class for them to extend, thus not allowin > their main > > > class to extend anything else. > ___ > Flashcoders@chattyfig.figleaf.com > To change your subscription options or search the archive: > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > Brought to you by Fig Leaf Software > Premier Authorized Adobe Consulting and Training > http://www.figleaf.com > http://training.figleaf.com > ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Writing code for big teams
Ah - that's because I don't do this with statics/getInstance(). :-) If I did, I'd probably do it with a minimal 'locator' class rather than an intrinsic. e.g. MyAppLocator.getApp() returns IApp IApp defines registerMe() That sort of thing. :-) But, at the end of the day, whatever works for you... Cheers, Ian On 11/22/06, Ricardo Sánchez <[EMAIL PROTECTED]> wrote: But I need to pass them at least an intrinsic so they can register their class, wouldn't I? On 11/22/06, Ian Thomas <[EMAIL PROTECTED]> wrote: > > Personally I'd pass them interfaces rather than intrinsics (mostly > because interfaces are a standard OOP concept but intrinsics are a > Flash-specific 'hackette'), but that's a matter of personal choice. > > Ian ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Writing code for big teams
But I need to pass them at least an intrinsic so they can register their class, wouldn't I? On 11/22/06, Ian Thomas <[EMAIL PROTECTED]> wrote: Personally I'd pass them interfaces rather than intrinsics (mostly because interfaces are a standard OOP concept but intrinsics are a Flash-specific 'hackette'), but that's a matter of personal choice. Ian On 11/22/06, Ricardo Sánchez <[EMAIL PROTECTED]> wrote: > I forgot I'm thinking they should also have an intrinsic class for an object > with global properties and stuff (not sure about this) > > On 11/22/06, Ricardo Sánchez <[EMAIL PROTECTED]> wrote: > > > > Do you think is a good idea to give them this 2 files, or should I pass > > them just an intrinsic class for them to extend, thus not allowin their main > > class to extend anything else. ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Writing code for big teams
Personally I'd pass them interfaces rather than intrinsics (mostly because interfaces are a standard OOP concept but intrinsics are a Flash-specific 'hackette'), but that's a matter of personal choice. Ian On 11/22/06, Ricardo Sánchez <[EMAIL PROTECTED]> wrote: I forgot I'm thinking they should also have an intrinsic class for an object with global properties and stuff (not sure about this) On 11/22/06, Ricardo Sánchez <[EMAIL PROTECTED]> wrote: > > Do you think is a good idea to give them this 2 files, or should I pass > them just an intrinsic class for them to extend, thus not allowin their main > class to extend anything else. ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Writing code for big teams
I forgot I'm thinking they should also have an intrinsic class for an object
with global properties and stuff (not sure about this)
On 11/22/06, Ricardo Sánchez <[EMAIL PROTECTED]> wrote:
Argh! Finally got it working! Thanks all.
I was missing some concepts in OOP for collaboration with teams, like
intrinsic classes and interfaces.
Ok, what I did for a try was having a method in my main class to register
third party movies' main classes. The I also have an interface they should
implement.
So I give them 2 files:
- an intrinsic copy of my main class only with the
definition of register and getInstance methods.
- an interface with the methods i'll call from my main
class
So in their class they do something like this
import lib.MainClass;
import lib.interface.InterfaceClass
class ThirdPartyClass implements InterfaceClass {
...
public function ThirdPartyClass () {
MainClass.getInstance().register(this);
}
... implement interface methods
}
Do you think is a good idea to give them this 2 files, or should I pass
them just an intrinsic class for them to extend, thus not allowin their main
class to extend anything else.
Again thakyou all, this is being of great help.
On 11/22/06, Michael Nisi <[EMAIL PROTECTED] > wrote:
>
> Forget about: Application.main(container_mc);
> > Application.main();
>
> M
>
> On 11/22/06, Michael Nisi <[EMAIL PROTECTED]> wrote:
> > Hey Ricardo,
> >
> > just to give you a ruff idea, there are bazillion ways of doing this.
> > You have two flas, shell.fla and section.fla. In each there's a clip
> > on Stage called container_mc.
> >
> > In shell.fla on _root you do:
> > Application.main(container_mc);
> >
> > In section.fla on _root you do:
> > var section:Section = new Section(container_mc);
> >
> > Here are the classes:
> > - Application
> > - ViewLocator
> > - Playable (Interface)
> > - Section
> >
> > import ViewLocator;
> > import Section;
> >
> > class Application
> > {
> > function Application()
> > {
> > var loader:MovieClipLoader = new MovieClipLoader();
> > loader.loadClip("section.swf", _root.container_mc);
> > }
> >
> > public static function main():Void
> > {
> > var application:Application = new Application();
> > }
> > }
> >
> > import Playable;
> > import Application;
> >
> > class ViewLocator
> > {
> > public static function register(section:Playable):Void
> > {
> > // Store section or whatever...
> > section.start();
> > }
> > }
> >
> > interface Playable
> > {
> > function start();
> > }
> >
> > import Playable;
> > import ViewLocator;
> >
> > class Section implements Playable
> > {
> > function Section(target:MovieClip)
> > {
> > ViewLocator.register(this);
> > }
> >
> > public function start()
> > {
> > trace("Section.start ");
> > }
> > }
> >
> > Regards
> > Michael
> >
> > On 11/22/06, Wade Arnold <[EMAIL PROTECTED]> wrote:
> > > Where would you place a your "global" properties? This is a question
> that
> > > has always got me.
> > >
> > > If the properties such as framerate, gatewayURL, styles, etc need to
> be in
> > > the class application. They have to be there for two reasons.
> > > 1. User defined inspectable properties.
> > > 2. variables must be available for proper instantiation.
> > >
> > >
> > > I have always wanted to have a config file, then a worker class that
> just
> > > handles all the get setters. However I have never been able to pull
> this off
> > > in order for the application class to wait for the variables to be
> > > populated. Any ideas? I assume I will try again in AS3.
> > >
> > > Wade
> > >
> > >
> > >
> > > On 11/22/06 1:56 AM, "Miguel Angel Sánchez" <[EMAIL PROTECTED]>
> wrote:
> > >
> > > > There is another approach to communicate those swfs:
> > > > - At your side:
> > > > 1. Class Application (singleton)
> > > > 2. Class LoadedSWF (or whatever), abstract class that every swf of
> the
> > > > team development will have to extend. This class could implement
> any
> > > > interface you like, and will have a constructor like this:
> > > >
> > > > public function LoadedSWF() {
> > > > Application.getInstance().register(this);
> > > > }
> > > >
> > > > 3. Your Application class will have a method register where you
> can
> > > > subscribe to LoadedSWF events, or even store a reference to the
> object
> > > > to call any of his methods.
> > > >
> > > > public function register(obj:LoadedSWF):Void {
> > > > obj.addEventListener("event", Delegate.create(this, onEvent));
> > > > }
> > > >
> > > > - At the team development side:
> > > > 1. intrinsic class Application
> > > > 2. intrinsic class LoadedSWF
> > > > 3. The class that controls the swf will have to extend LoadedSWF,
> and
> > > > call super() in its constructor
> > > > class Whatever extends LoadedSWF {
> > > > public function Whatever() {
> > > > super();
> > > >
Re: [Flashcoders] Writing code for big teams
Argh! Finally got it working! Thanks all.
I was missing some concepts in OOP for collaboration with teams, like
intrinsic classes and interfaces.
Ok, what I did for a try was having a method in my main class to register
third party movies' main classes. The I also have an interface they should
implement.
So I give them 2 files:
- an intrinsic copy of my main class only with the
definition of register and getInstance methods.
- an interface with the methods i'll call from my main
class
So in their class they do something like this
import lib.MainClass;
import lib.interface.InterfaceClass
class ThirdPartyClass implements InterfaceClass {
...
public function ThirdPartyClass () {
MainClass.getInstance().register(this);
}
... implement interface methods
}
Do you think is a good idea to give them this 2 files, or should I pass them
just an intrinsic class for them to extend, thus not allowin their main
class to extend anything else.
Again thakyou all, this is being of great help.
On 11/22/06, Michael Nisi <[EMAIL PROTECTED]> wrote:
Forget about: Application.main(container_mc);
> Application.main();
M
On 11/22/06, Michael Nisi <[EMAIL PROTECTED]> wrote:
> Hey Ricardo,
>
> just to give you a ruff idea, there are bazillion ways of doing this.
> You have two flas, shell.fla and section.fla. In each there's a clip
> on Stage called container_mc.
>
> In shell.fla on _root you do:
> Application.main(container_mc);
>
> In section.fla on _root you do:
> var section:Section = new Section(container_mc);
>
> Here are the classes:
> - Application
> - ViewLocator
> - Playable (Interface)
> - Section
>
> import ViewLocator;
> import Section;
>
> class Application
> {
> function Application()
> {
> var loader:MovieClipLoader = new MovieClipLoader();
> loader.loadClip("section.swf", _root.container_mc);
> }
>
> public static function main():Void
> {
> var application:Application = new Application();
> }
> }
>
> import Playable;
> import Application;
>
> class ViewLocator
> {
> public static function register(section:Playable):Void
> {
> // Store section or whatever...
> section.start();
> }
> }
>
> interface Playable
> {
> function start();
> }
>
> import Playable;
> import ViewLocator;
>
> class Section implements Playable
> {
> function Section(target:MovieClip)
> {
> ViewLocator.register(this);
> }
>
> public function start()
> {
> trace("Section.start");
> }
> }
>
> Regards
> Michael
>
> On 11/22/06, Wade Arnold <[EMAIL PROTECTED]> wrote:
> > Where would you place a your "global" properties? This is a question
that
> > has always got me.
> >
> > If the properties such as framerate, gatewayURL, styles, etc need to
be in
> > the class application. They have to be there for two reasons.
> > 1. User defined inspectable properties.
> > 2. variables must be available for proper instantiation.
> >
> >
> > I have always wanted to have a config file, then a worker class that
just
> > handles all the get setters. However I have never been able to pull
this off
> > in order for the application class to wait for the variables to be
> > populated. Any ideas? I assume I will try again in AS3.
> >
> > Wade
> >
> >
> >
> > On 11/22/06 1:56 AM, "Miguel Angel Sánchez" <[EMAIL PROTECTED]>
wrote:
> >
> > > There is another approach to communicate those swfs:
> > > - At your side:
> > > 1. Class Application (singleton)
> > > 2. Class LoadedSWF (or whatever), abstract class that every swf of
the
> > > team development will have to extend. This class could implement any
> > > interface you like, and will have a constructor like this:
> > >
> > > public function LoadedSWF() {
> > > Application.getInstance().register(this);
> > > }
> > >
> > > 3. Your Application class will have a method register where you can
> > > subscribe to LoadedSWF events, or even store a reference to the
object
> > > to call any of his methods.
> > >
> > > public function register(obj:LoadedSWF):Void {
> > > obj.addEventListener("event", Delegate.create(this, onEvent));
> > > }
> > >
> > > - At the team development side:
> > > 1. intrinsic class Application
> > > 2. intrinsic class LoadedSWF
> > > 3. The class that controls the swf will have to extend LoadedSWF,
and
> > > call super() in its constructor
> > > class Whatever extends LoadedSWF {
> > > public function Whatever() {
> > > super();
> > > ...
> > > }
> > > }
> > >
> > > This way everytime you load an external swf of your team development
it
> > > automatically notifies your Application class.
> > >
> > > PS: so many people from DMSTK around here these days :-)
> > >
> > > Ricardo Sánchez escribió:
> > >> Man! I must be very dumb, but I don't know how to refer to the
class that
> > >> implements the interface from the main swf.
> > >>
> > >>
> > >>
> > >> On 11/21/06, Ricardo Sánchez <[EMAIL PRO
Re: [Flashcoders] Writing code for big teams
Forget about: Application.main(container_mc);
Application.main();
M
On 11/22/06, Michael Nisi <[EMAIL PROTECTED]> wrote:
Hey Ricardo,
just to give you a ruff idea, there are bazillion ways of doing this.
You have two flas, shell.fla and section.fla. In each there's a clip
on Stage called container_mc.
In shell.fla on _root you do:
Application.main(container_mc);
In section.fla on _root you do:
var section:Section = new Section(container_mc);
Here are the classes:
- Application
- ViewLocator
- Playable (Interface)
- Section
import ViewLocator;
import Section;
class Application
{
function Application()
{
var loader:MovieClipLoader = new MovieClipLoader();
loader.loadClip("section.swf", _root.container_mc);
}
public static function main():Void
{
var application:Application = new Application();
}
}
import Playable;
import Application;
class ViewLocator
{
public static function register(section:Playable):Void
{
// Store section or whatever...
section.start();
}
}
interface Playable
{
function start();
}
import Playable;
import ViewLocator;
class Section implements Playable
{
function Section(target:MovieClip)
{
ViewLocator.register(this);
}
public function start()
{
trace("Section.start");
}
}
Regards
Michael
On 11/22/06, Wade Arnold <[EMAIL PROTECTED]> wrote:
> Where would you place a your "global" properties? This is a question that
> has always got me.
>
> If the properties such as framerate, gatewayURL, styles, etc need to be in
> the class application. They have to be there for two reasons.
> 1. User defined inspectable properties.
> 2. variables must be available for proper instantiation.
>
>
> I have always wanted to have a config file, then a worker class that just
> handles all the get setters. However I have never been able to pull this off
> in order for the application class to wait for the variables to be
> populated. Any ideas? I assume I will try again in AS3.
>
> Wade
>
>
>
> On 11/22/06 1:56 AM, "Miguel Angel Sánchez" <[EMAIL PROTECTED]> wrote:
>
> > There is another approach to communicate those swfs:
> > - At your side:
> > 1. Class Application (singleton)
> > 2. Class LoadedSWF (or whatever), abstract class that every swf of the
> > team development will have to extend. This class could implement any
> > interface you like, and will have a constructor like this:
> >
> > public function LoadedSWF() {
> > Application.getInstance().register(this);
> > }
> >
> > 3. Your Application class will have a method register where you can
> > subscribe to LoadedSWF events, or even store a reference to the object
> > to call any of his methods.
> >
> > public function register(obj:LoadedSWF):Void {
> > obj.addEventListener("event", Delegate.create(this, onEvent));
> > }
> >
> > - At the team development side:
> > 1. intrinsic class Application
> > 2. intrinsic class LoadedSWF
> > 3. The class that controls the swf will have to extend LoadedSWF, and
> > call super() in its constructor
> > class Whatever extends LoadedSWF {
> > public function Whatever() {
> > super();
> > ...
> > }
> > }
> >
> > This way everytime you load an external swf of your team development it
> > automatically notifies your Application class.
> >
> > PS: so many people from DMSTK around here these days :-)
> >
> > Ricardo Sánchez escribió:
> >> Man! I must be very dumb, but I don't know how to refer to the class that
> >> implements the interface from the main swf.
> >>
> >>
> >>
> >> On 11/21/06, Ricardo Sánchez <[EMAIL PROTECTED]> wrote:
> >>>
> >>> So, back to what you said earlier, this should be:
> >>>
> >>> container.loadMovie("externalMovie");
> >>> [after fully load]
> >>> container.section.config()
> >>> container.section.start();
> >>>
> >>> wouldn't it?
> >>>
> >>> On 11/21/06, Zárate <[EMAIL PROTECTED]> wrote:
>
> No man, that's not my point.
>
> You cannot make a swf implement an interface, but you can make the
> content of that swf implement it. Say you have in the _root of every
> section swf something like this:
>
> ---
>
> var section:SectionClass = new SectionClass(this);
>
>
>
> "SectionClass" implements the interface, so you know which methods and
> properties are going to be available in the "section" variable.
>
> You cannot "force" external developers in the strict mean of the word,
> you'll need to _ask_ them to do so. Simply refuse any external swf not
> implementing the interface.
>
> Makes more sense now?
>
> Cheers
>
> On 11/21/06, Ian Thomas <[EMAIL PROTECTED]> wrote:
> >> For example, ensure that the container can do something like:
> > Doh! I mean, of course, ensure that the _contained_ movie can do
> something like:
> >
> > On 11/21/06, Ian Thomas <[EMAIL PROTECTED]> w
Re: [Flashcoders] Writing code for big teams
Well, I think that there are different ways to accomplish this and every
developer will have his own way. You could store the config variables in
Application, or you could have a Config class that is set up when
Application starts, i.e. getting the configuration from an XML file, and
the rest of classes could access to its properties via
getInstance().getSomeProperty() or static properties/methods.
PS: sorry if you get this message twice, but it seems that the previous
message was rejected by the server for beeing so long.
Wade Arnold escribió:
Where would you place a your "global" properties? This is a question that
has always got me.
If the properties such as framerate, gatewayURL, styles, etc need to be in
the class application. They have to be there for two reasons.
1. User defined inspectable properties.
2. variables must be available for proper instantiation.
I have always wanted to have a config file, then a worker class that just
handles all the get setters. However I have never been able to pull this off
in order for the application class to wait for the variables to be
populated. Any ideas? I assume I will try again in AS3.
Wade
On 11/22/06 1:56 AM, "Miguel Angel Sánchez" <[EMAIL PROTECTED]> wrote:
There is another approach to communicate those swfs:
- At your side:
1. Class Application (singleton)
2. Class LoadedSWF (or whatever), abstract class that every swf of the
team development will have to extend. This class could implement any
interface you like, and will have a constructor like this:
public function LoadedSWF() {
Application.getInstance().register(this);
}
3. Your Application class will have a method register where you can
subscribe to LoadedSWF events, or even store a reference to the object
to call any of his methods.
public function register(obj:LoadedSWF):Void {
obj.addEventListener("event", Delegate.create(this, onEvent));
}
- At the team development side:
1. intrinsic class Application
2. intrinsic class LoadedSWF
3. The class that controls the swf will have to extend LoadedSWF, and
call super() in its constructor
class Whatever extends LoadedSWF {
public function Whatever() {
super();
...
}
}
This way everytime you load an external swf of your team development it
automatically notifies your Application class.
PS: so many people from DMSTK around here these days :-)
Ricardo Sánchez escribió:
Man! I must be very dumb, but I don't know how to refer to the class that
implements the interface from the main swf.
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
Re: [Flashcoders] Writing code for big teams
Hey Ricardo,
just to give you a ruff idea, there are bazillion ways of doing this.
You have two flas, shell.fla and section.fla. In each there's a clip
on Stage called container_mc.
In shell.fla on _root you do:
Application.main(container_mc);
In section.fla on _root you do:
var section:Section = new Section(container_mc);
Here are the classes:
- Application
- ViewLocator
- Playable (Interface)
- Section
import ViewLocator;
import Section;
class Application
{
function Application()
{
var loader:MovieClipLoader = new MovieClipLoader();
loader.loadClip("section.swf", _root.container_mc);
}
public static function main():Void
{
var application:Application = new Application();
}
}
import Playable;
import Application;
class ViewLocator
{
public static function register(section:Playable):Void
{
// Store section or whatever...
section.start();
}
}
interface Playable
{
function start();
}
import Playable;
import ViewLocator;
class Section implements Playable
{
function Section(target:MovieClip)
{
ViewLocator.register(this);
}
public function start()
{
trace("Section.start");
}
}
Regards
Michael
On 11/22/06, Wade Arnold <[EMAIL PROTECTED]> wrote:
Where would you place a your "global" properties? This is a question that
has always got me.
If the properties such as framerate, gatewayURL, styles, etc need to be in
the class application. They have to be there for two reasons.
1. User defined inspectable properties.
2. variables must be available for proper instantiation.
I have always wanted to have a config file, then a worker class that just
handles all the get setters. However I have never been able to pull this off
in order for the application class to wait for the variables to be
populated. Any ideas? I assume I will try again in AS3.
Wade
On 11/22/06 1:56 AM, "Miguel Angel Sánchez" <[EMAIL PROTECTED]> wrote:
> There is another approach to communicate those swfs:
> - At your side:
> 1. Class Application (singleton)
> 2. Class LoadedSWF (or whatever), abstract class that every swf of the
> team development will have to extend. This class could implement any
> interface you like, and will have a constructor like this:
>
> public function LoadedSWF() {
> Application.getInstance().register(this);
> }
>
> 3. Your Application class will have a method register where you can
> subscribe to LoadedSWF events, or even store a reference to the object
> to call any of his methods.
>
> public function register(obj:LoadedSWF):Void {
> obj.addEventListener("event", Delegate.create(this, onEvent));
> }
>
> - At the team development side:
> 1. intrinsic class Application
> 2. intrinsic class LoadedSWF
> 3. The class that controls the swf will have to extend LoadedSWF, and
> call super() in its constructor
> class Whatever extends LoadedSWF {
> public function Whatever() {
> super();
> ...
> }
> }
>
> This way everytime you load an external swf of your team development it
> automatically notifies your Application class.
>
> PS: so many people from DMSTK around here these days :-)
>
> Ricardo Sánchez escribió:
>> Man! I must be very dumb, but I don't know how to refer to the class that
>> implements the interface from the main swf.
>>
>>
>>
>> On 11/21/06, Ricardo Sánchez <[EMAIL PROTECTED]> wrote:
>>>
>>> So, back to what you said earlier, this should be:
>>>
>>> container.loadMovie("externalMovie");
>>> [after fully load]
>>> container.section.config()
>>> container.section.start();
>>>
>>> wouldn't it?
>>>
>>> On 11/21/06, Zárate <[EMAIL PROTECTED]> wrote:
No man, that's not my point.
You cannot make a swf implement an interface, but you can make the
content of that swf implement it. Say you have in the _root of every
section swf something like this:
---
var section:SectionClass = new SectionClass(this);
"SectionClass" implements the interface, so you know which methods and
properties are going to be available in the "section" variable.
You cannot "force" external developers in the strict mean of the word,
you'll need to _ask_ them to do so. Simply refuse any external swf not
implementing the interface.
Makes more sense now?
Cheers
On 11/21/06, Ian Thomas <[EMAIL PROTECTED]> wrote:
>> For example, ensure that the container can do something like:
> Doh! I mean, of course, ensure that the _contained_ movie can do
something like:
>
> On 11/21/06, Ian Thomas <[EMAIL PROTECTED]> wrote:
>> The alternative (one I use a lot) is to do it backwards.
>>
>> Make the contained movie register its 'main' class with a known
point
>> in the container.
>>
>> For example, ensure that the container can do something like:
>>
>> _parent.registerMe(MyControllingClass);
>>
>> where MyControllingC
Re: [Flashcoders] Writing code for big teams
Where would you place a your "global" properties? This is a question that
has always got me.
If the properties such as framerate, gatewayURL, styles, etc need to be in
the class application. They have to be there for two reasons.
1. User defined inspectable properties.
2. variables must be available for proper instantiation.
I have always wanted to have a config file, then a worker class that just
handles all the get setters. However I have never been able to pull this off
in order for the application class to wait for the variables to be
populated. Any ideas? I assume I will try again in AS3.
Wade
On 11/22/06 1:56 AM, "Miguel Angel Sánchez" <[EMAIL PROTECTED]> wrote:
> There is another approach to communicate those swfs:
> - At your side:
> 1. Class Application (singleton)
> 2. Class LoadedSWF (or whatever), abstract class that every swf of the
> team development will have to extend. This class could implement any
> interface you like, and will have a constructor like this:
>
> public function LoadedSWF() {
> Application.getInstance().register(this);
> }
>
> 3. Your Application class will have a method register where you can
> subscribe to LoadedSWF events, or even store a reference to the object
> to call any of his methods.
>
> public function register(obj:LoadedSWF):Void {
> obj.addEventListener("event", Delegate.create(this, onEvent));
> }
>
> - At the team development side:
> 1. intrinsic class Application
> 2. intrinsic class LoadedSWF
> 3. The class that controls the swf will have to extend LoadedSWF, and
> call super() in its constructor
> class Whatever extends LoadedSWF {
> public function Whatever() {
> super();
> ...
> }
> }
>
> This way everytime you load an external swf of your team development it
> automatically notifies your Application class.
>
> PS: so many people from DMSTK around here these days :-)
>
> Ricardo Sánchez escribió:
>> Man! I must be very dumb, but I don't know how to refer to the class that
>> implements the interface from the main swf.
>>
>>
>>
>> On 11/21/06, Ricardo Sánchez <[EMAIL PROTECTED]> wrote:
>>>
>>> So, back to what you said earlier, this should be:
>>>
>>> container.loadMovie("externalMovie");
>>> [after fully load]
>>> container.section.config()
>>> container.section.start();
>>>
>>> wouldn't it?
>>>
>>> On 11/21/06, Zárate <[EMAIL PROTECTED]> wrote:
No man, that's not my point.
You cannot make a swf implement an interface, but you can make the
content of that swf implement it. Say you have in the _root of every
section swf something like this:
---
var section:SectionClass = new SectionClass(this);
"SectionClass" implements the interface, so you know which methods and
properties are going to be available in the "section" variable.
You cannot "force" external developers in the strict mean of the word,
you'll need to _ask_ them to do so. Simply refuse any external swf not
implementing the interface.
Makes more sense now?
Cheers
On 11/21/06, Ian Thomas <[EMAIL PROTECTED]> wrote:
>> For example, ensure that the container can do something like:
> Doh! I mean, of course, ensure that the _contained_ movie can do
something like:
>
> On 11/21/06, Ian Thomas <[EMAIL PROTECTED]> wrote:
>> The alternative (one I use a lot) is to do it backwards.
>>
>> Make the contained movie register its 'main' class with a known
point
>> in the container.
>>
>> For example, ensure that the container can do something like:
>>
>> _parent.registerMe(MyControllingClass);
>>
>> where MyControllingClass implements the PluginMovie interface (or
>> whatever your interface is called) and you've set up
>> _parent.registerMe() as something like:
>>
>> public function registerMe(movie:PluginMovie):Void;
>>
>> Does that make sense? The other advantage of doing it 'backwards'
like
>> this is that you could put off registering until all your
>>> assets are
>> loaded or some other action has happened; your child movie has
>> complete control of when it's ready to talk to the container.
>>
>> Hope that helps,
>> Ian
> ___
> Flashcoders@chattyfig.figleaf.com
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
> Brought to you by Fig Leaf Software
> Premier Authorized Adobe Consulting and Training
> http://www.figleaf.com
> http://training.figleaf.com
>
--
Juan Delgado - Zárate
http://zarate.tv
http://dandolachapa.com
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http:/
Re: [Flashcoders] Writing code for big teams
There is another approach to communicate those swfs:
- At your side:
1. Class Application (singleton)
2. Class LoadedSWF (or whatever), abstract class that every swf of the
team development will have to extend. This class could implement any
interface you like, and will have a constructor like this:
public function LoadedSWF() {
Application.getInstance().register(this);
}
3. Your Application class will have a method register where you can
subscribe to LoadedSWF events, or even store a reference to the object
to call any of his methods.
public function register(obj:LoadedSWF):Void {
obj.addEventListener("event", Delegate.create(this, onEvent));
}
- At the team development side:
1. intrinsic class Application
2. intrinsic class LoadedSWF
3. The class that controls the swf will have to extend LoadedSWF, and
call super() in its constructor
class Whatever extends LoadedSWF {
public function Whatever() {
super();
...
}
}
This way everytime you load an external swf of your team development it
automatically notifies your Application class.
PS: so many people from DMSTK around here these days :-)
Ricardo Sánchez escribió:
Man! I must be very dumb, but I don't know how to refer to the class that
implements the interface from the main swf.
On 11/21/06, Ricardo Sánchez <[EMAIL PROTECTED]> wrote:
So, back to what you said earlier, this should be:
container.loadMovie("externalMovie");
[after fully load]
container.section.config()
container.section.start();
wouldn't it?
On 11/21/06, Zárate <[EMAIL PROTECTED]> wrote:
>
> No man, that's not my point.
>
> You cannot make a swf implement an interface, but you can make the
> content of that swf implement it. Say you have in the _root of every
> section swf something like this:
>
> ---
>
> var section:SectionClass = new SectionClass(this);
>
>
>
> "SectionClass" implements the interface, so you know which methods and
> properties are going to be available in the "section" variable.
>
> You cannot "force" external developers in the strict mean of the word,
> you'll need to _ask_ them to do so. Simply refuse any external swf not
> implementing the interface.
>
> Makes more sense now?
>
> Cheers
>
> On 11/21/06, Ian Thomas <[EMAIL PROTECTED]> wrote:
> > > For example, ensure that the container can do something like:
> > Doh! I mean, of course, ensure that the _contained_ movie can do
> something like:
> >
> > On 11/21/06, Ian Thomas <[EMAIL PROTECTED]> wrote:
> > > The alternative (one I use a lot) is to do it backwards.
> > >
> > > Make the contained movie register its 'main' class with a known
> point
> > > in the container.
> > >
> > > For example, ensure that the container can do something like:
> > >
> > > _parent.registerMe(MyControllingClass);
> > >
> > > where MyControllingClass implements the PluginMovie interface (or
> > > whatever your interface is called) and you've set up
> > > _parent.registerMe() as something like:
> > >
> > > public function registerMe(movie:PluginMovie):Void;
> > >
> > > Does that make sense? The other advantage of doing it 'backwards'
> like
> > > this is that you could put off registering until all your
assets are
> > > loaded or some other action has happened; your child movie has
> > > complete control of when it's ready to talk to the container.
> > >
> > > Hope that helps,
> > > Ian
> > ___
> > Flashcoders@chattyfig.figleaf.com
> > To change your subscription options or search the archive:
> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >
> > Brought to you by Fig Leaf Software
> > Premier Authorized Adobe Consulting and Training
> > http://www.figleaf.com
> > http://training.figleaf.com
> >
>
>
> --
> Juan Delgado - Zárate
> http://zarate.tv
> http://dandolachapa.com
> ___
> Flashcoders@chattyfig.figleaf.com
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
> Brought to you by Fig Leaf Software
> Premier Authorized Adobe Consulting and Training
> http://www.figleaf.com
> http://training.figleaf.com
>
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
Re: [Flashcoders] Writing code for big teams
They have to extend the MovieClip class in order to be able to do that, am I
wrong?
I mean, If I load an swf with loadMovie (instead of creating an instance
with new) nothing assures me they are going to implement that class.
I'm a little lost in the relationship between movies and classes because I
always do composition, so I don't know how to load a movie and pass that
movie an interface.
On 11/9/06, Zárate <[EMAIL PROTECTED]> wrote:
My 0.2,
Basically it really depends on what are they doing. Say you have a
player or main movie. You're tipically going to load different movies
or sections on it. And you want all sections to have a common list of
public properties and methods. Define that list and make it an
interface. Then, you can tell anyone: "do whatever you want BUT you
have to implement this interface"
If they compile against that interface you know that _at least_ some
properties and methods are going to be there for your calls. So within
your main movie you can do something like:
container.loadMovie("externalMovie");
[after fully load]
container.config()
container.start();
Of course if you have defined those methods in your interface. You
won't need to recompile anything.
Makes sense?
Cheers,
On 11/8/06, Glen Pike <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Whilst this suggestion is not good practice if you can get in at the
> start of a project - I would recommend doing things the way others have
> said, by using interfaces, I was given a very nice workaround for a
> situation I got stuck in recently.
>
> I was given about 20 SWF & FLA files, where all the animation was
> done on the root timeline - not in a movieclip. These were to be loaded
> into a shell application and I needed to have some control over the
> playback of the animations, know when they finished or hit certain
> frames etc. It would have been perfect if the animations were each
> contained within a MovieClip that was linked to a class of my choosing,
> but I did not get to speak to the animators as I was lower down in the
> food chain for this job. As I did not wish to copy and paste thousands
> of frames of animation into child clips with the correct class linkage,
> I asked for some help and was told, I could "recast" the loaded SWF
> movieclips into a class of my choosing. This worked beautifully and
> saved me hours of extra work,
>
> Credit to [EMAIL PROTECTED] for his solution below -thanks a
million!
>
> "Hi,
>
> I think adding to the prototype would be the easiest way of recasting an
> external swf into a class. It's like setting up a class linkage in the
> library except you can't do that with external swfs (as you already
> know).
>
> Once you got the swf loaded into external_mc you can:
>
> // recast it as NewClass
> external_mc.__proto__ = NewClass.prototype;
> external_mc.__constructor__ = NewClass;
> external_mc.__constructor__.apply(external_mc);
>
> If you wanted to pass arguments into the constructor you can change last
> line to:
> external_mc.__constructor__.apply(external_mc, arg1, arg2, ..., argN);
>
> It might not look nice, but it works nice. The external swf functions
> and behaves just like a symbol would be if you loaded it from your
> library and the class linkage was setup.
>
> Hope this helps.
>
> Matthew Jacobi
> "
> Adobe Consulting - EMEA - MAD
>
> ___
> Flashcoders@chattyfig.figleaf.com
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
> Brought to you by Fig Leaf Software
> Premier Authorized Adobe Consulting and Training
> http://www.figleaf.com
> http://training.figleaf.com
>
--
Juan Delgado - Zárate
http://zarate.tv
http://dandolachapa.com
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
Re: [Flashcoders] Writing code for big teams
My 0.2,
Basically it really depends on what are they doing. Say you have a
player or main movie. You're tipically going to load different movies
or sections on it. And you want all sections to have a common list of
public properties and methods. Define that list and make it an
interface. Then, you can tell anyone: "do whatever you want BUT you
have to implement this interface"
If they compile against that interface you know that _at least_ some
properties and methods are going to be there for your calls. So within
your main movie you can do something like:
container.loadMovie("externalMovie");
[after fully load]
container.config()
container.start();
Of course if you have defined those methods in your interface. You
won't need to recompile anything.
Makes sense?
Cheers,
On 11/8/06, Glen Pike <[EMAIL PROTECTED]> wrote:
Hi,
Whilst this suggestion is not good practice if you can get in at the
start of a project - I would recommend doing things the way others have
said, by using interfaces, I was given a very nice workaround for a
situation I got stuck in recently.
I was given about 20 SWF & FLA files, where all the animation was
done on the root timeline - not in a movieclip. These were to be loaded
into a shell application and I needed to have some control over the
playback of the animations, know when they finished or hit certain
frames etc. It would have been perfect if the animations were each
contained within a MovieClip that was linked to a class of my choosing,
but I did not get to speak to the animators as I was lower down in the
food chain for this job. As I did not wish to copy and paste thousands
of frames of animation into child clips with the correct class linkage,
I asked for some help and was told, I could "recast" the loaded SWF
movieclips into a class of my choosing. This worked beautifully and
saved me hours of extra work,
Credit to [EMAIL PROTECTED] for his solution below -thanks a million!
"Hi,
I think adding to the prototype would be the easiest way of recasting an
external swf into a class. It's like setting up a class linkage in the
library except you can't do that with external swfs (as you already
know).
Once you got the swf loaded into external_mc you can:
// recast it as NewClass
external_mc.__proto__ = NewClass.prototype;
external_mc.__constructor__ = NewClass;
external_mc.__constructor__.apply(external_mc);
If you wanted to pass arguments into the constructor you can change last
line to:
external_mc.__constructor__.apply(external_mc, arg1, arg2, ..., argN);
It might not look nice, but it works nice. The external swf functions
and behaves just like a symbol would be if you loaded it from your
library and the class linkage was setup.
Hope this helps.
Matthew Jacobi
"
Adobe Consulting - EMEA - MAD
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
--
Juan Delgado - Zárate
http://zarate.tv
http://dandolachapa.com
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
Re: [Flashcoders] Writing code for big teams
Hi, Whilst this suggestion is not good practice if you can get in at the start of a project - I would recommend doing things the way others have said, by using interfaces, I was given a very nice workaround for a situation I got stuck in recently. I was given about 20 SWF & FLA files, where all the animation was done on the root timeline - not in a movieclip. These were to be loaded into a shell application and I needed to have some control over the playback of the animations, know when they finished or hit certain frames etc. It would have been perfect if the animations were each contained within a MovieClip that was linked to a class of my choosing, but I did not get to speak to the animators as I was lower down in the food chain for this job. As I did not wish to copy and paste thousands of frames of animation into child clips with the correct class linkage, I asked for some help and was told, I could "recast" the loaded SWF movieclips into a class of my choosing. This worked beautifully and saved me hours of extra work, Credit to [EMAIL PROTECTED] for his solution below -thanks a million! "Hi, I think adding to the prototype would be the easiest way of recasting an external swf into a class. It's like setting up a class linkage in the library except you can't do that with external swfs (as you already know). Once you got the swf loaded into external_mc you can: // recast it as NewClass external_mc.__proto__ = NewClass.prototype; external_mc.__constructor__ = NewClass; external_mc.__constructor__.apply(external_mc); If you wanted to pass arguments into the constructor you can change last line to: external_mc.__constructor__.apply(external_mc, arg1, arg2, ..., argN); It might not look nice, but it works nice. The external swf functions and behaves just like a symbol would be if you loaded it from your library and the class linkage was setup. Hope this helps. Matthew Jacobi " Adobe Consulting - EMEA - MAD ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
RE: [Flashcoders] Writing code for big teams
> -Original Message- > From: [EMAIL PROTECTED] [mailto:flashcoders- > [EMAIL PROTECTED] On Behalf Of Michael Nisi > Sent: Wednesday, November 08, 2006 11:38 AM > To: Flashcoders mailing list > Subject: Re: [Flashcoders] Writing code for big teams > > Same here. Can't imagine to develop without testing anymore. Test > while you code, not afterwards. It let's you design your objects in a > transparent way. Yes. I highly recommend this book: http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201 485672/sr=8-1/qid=1163021817/ref=pd_bbs_sr_1/002-6548398-2158405?ie=UTF8 &s=books It really opened my eyes to the utility of unit-testing, and how paying some time up front can allow your code to be more stable and more flexible down the road. (Yes, the examples are in Java, but it's extremely similar to AS.) ― Mike Keesey ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Writing code for big teams
Same here. Can't imagine to develop without testing anymore. Test while you code, not afterwards. It let's you design your objects in a transparent way. Regards Michael On 11/8/06, Steven Sacks | BLITZ <[EMAIL PROTECTED]> wrote: Something else I recommend is have somebody who is in charge of integration and they make sure that everyone who hands them code thoroughly tests it first. This is how I write my apps when it's just me, as well, and as a result my code is pretty much bug-free. If their code can't be tested independently, then they're not writing it correctly. Any class or component should be able to run bug-free on its own outside the realms of the rest of the application before integration. It doesn't need to be so dynamic that it will accept anything. Build it against the data model it expects from the app, just feed it fake data (and bad data) to ensure it's working correctly and handles exceptions well. If not, then it needs to be fixed before it gets integrated. http://www.asunit.com/ AS Unit can be really helpful in this regard. Good luck! ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Writing code for big teams
You'll probably have a container class which manages loading, etc. It
loads swfs. In the swf a class implements your Interface.The class get
initialized inside the loaded clip, so you don't have to know anything
about it.
interface ricardo.Loadable
{
public function doSomething(Void):Void
}
Your Container or ViewManager or whatever calls doSomething();
Another approach could maybe a Factory, but, hm no not really in this
case. It's a bad idea to initialize view widgets by someone else from
the outside. It really depends on what's going on in these loaded
clips.
class ricardo.ClassFactory
{
public static function getClass(name:String, args:Object):Object
{
return new Function(eval(name))(args ? args : []);
}
}
Regards,
Michael
On 11/8/06, Ricardo Sánchez <[EMAIL PROTECTED]> wrote:
I'm sorry, I'll explain mysel.
If I make an interface that I want their movies to implement... How do I
load an external movie? To load it instanciating the class I'll have to
compile it... am I wrong?
Can you show some code? I'm pretty lost.
Thanks all.
On 11/8/06, Michael Nisi <[EMAIL PROTECTED]> wrote:
>
> Hi Ricardo, why do you think using Interface or Interfaces will force
> you to compile the collaborators code. I don't get the point. They can
> compile your Interfaces into their swfs and you can compile them into
> yours. That's what interfaces are for. No?
>
> Regards
> Michael
>
> On 11/8/06, Ricardo Sánchez <[EMAIL PROTECTED]> wrote:
> > By registration code you mean register to a class? As in
> Object.registerClass()
> > ?
> >
> > On 11/8/06, Janis Radins <[EMAIL PROTECTED]> wrote:
> > >
> > > just force them to execute some registration code on first frame of
> theyr
> > > movie and pass instance which will accept all those calls according to
> > > predefined communication interface
> > >
> > > 2006/11/8, Ricardo Sánchez <[EMAIL PROTECTED]>:
> > > >
> > > > Hi!
> > > >
> > > > Where I work we are about to begin a pretty big project
> collaborating
> > > with
> > > > some other agencies.
> > > >
> > > > The thing is we are going to develop the main movie with the menus
> and
> > > > other
> > > > stuff where every other movie any agency develops is going to be
> loaded.
> > > >
> > > > I was thinking about writing an interface class and give it to our
> > > > collaborators so their main class would have to implement some
> specific
> > > > methods (like start, finish, resize...)
> > > >
> > > > But then I thought that doing it this way will probably force us to
> > > > compile
> > > > their fla ourselves, and that's something we want to avoid. Every
> movie
> > > > has
> > > > to be independent and compile on itself, and then the swf should fit
> in
> > > > our
> > > > proyect.
> > > >
> > > > Does this make any sense? Can anyone help?
> > > >
> > > > Thanks.
> > > > ___
> > > > Flashcoders@chattyfig.figleaf.com
> > > > To change your subscription options or search the archive:
> > > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > > >
> > > > Brought to you by Fig Leaf Software
> > > > Premier Authorized Adobe Consulting and Training
> > > > http://www.figleaf.com
> > > > http://training.figleaf.com
> > > >
> > > ___
> > > Flashcoders@chattyfig.figleaf.com
> > > To change your subscription options or search the archive:
> > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > >
> > > Brought to you by Fig Leaf Software
> > > Premier Authorized Adobe Consulting and Training
> > > http://www.figleaf.com
> > > http://training.figleaf.com
> > >
> > ___
> > Flashcoders@chattyfig.figleaf.com
> > To change your subscription options or search the archive:
> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >
> > Brought to you by Fig Leaf Software
> > Premier Authorized Adobe Consulting and Training
> > http://www.figleaf.com
> > http://training.figleaf.com
> >
> ___
> Flashcoders@chattyfig.figleaf.com
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
> Brought to you by Fig Leaf Software
> Premier Authorized Adobe Consulting and Training
> http://www.figleaf.com
> http://training.figleaf.com
>
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://
RE: [Flashcoders] Writing code for big teams
Something else I recommend is have somebody who is in charge of integration and they make sure that everyone who hands them code thoroughly tests it first. This is how I write my apps when it's just me, as well, and as a result my code is pretty much bug-free. If their code can't be tested independently, then they're not writing it correctly. Any class or component should be able to run bug-free on its own outside the realms of the rest of the application before integration. It doesn't need to be so dynamic that it will accept anything. Build it against the data model it expects from the app, just feed it fake data (and bad data) to ensure it's working correctly and handles exceptions well. If not, then it needs to be fixed before it gets integrated. http://www.asunit.com/ AS Unit can be really helpful in this regard. Good luck! ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Writing code for big teams
I'm sorry, I'll explain mysel. If I make an interface that I want their movies to implement... How do I load an external movie? To load it instanciating the class I'll have to compile it... am I wrong? Can you show some code? I'm pretty lost. Thanks all. On 11/8/06, Michael Nisi <[EMAIL PROTECTED]> wrote: Hi Ricardo, why do you think using Interface or Interfaces will force you to compile the collaborators code. I don't get the point. They can compile your Interfaces into their swfs and you can compile them into yours. That's what interfaces are for. No? Regards Michael On 11/8/06, Ricardo Sánchez <[EMAIL PROTECTED]> wrote: > By registration code you mean register to a class? As in Object.registerClass() > ? > > On 11/8/06, Janis Radins <[EMAIL PROTECTED]> wrote: > > > > just force them to execute some registration code on first frame of theyr > > movie and pass instance which will accept all those calls according to > > predefined communication interface > > > > 2006/11/8, Ricardo Sánchez <[EMAIL PROTECTED]>: > > > > > > Hi! > > > > > > Where I work we are about to begin a pretty big project collaborating > > with > > > some other agencies. > > > > > > The thing is we are going to develop the main movie with the menus and > > > other > > > stuff where every other movie any agency develops is going to be loaded. > > > > > > I was thinking about writing an interface class and give it to our > > > collaborators so their main class would have to implement some specific > > > methods (like start, finish, resize...) > > > > > > But then I thought that doing it this way will probably force us to > > > compile > > > their fla ourselves, and that's something we want to avoid. Every movie > > > has > > > to be independent and compile on itself, and then the swf should fit in > > > our > > > proyect. > > > > > > Does this make any sense? Can anyone help? > > > > > > Thanks. > > > ___ > > > Flashcoders@chattyfig.figleaf.com > > > To change your subscription options or search the archive: > > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > > > Brought to you by Fig Leaf Software > > > Premier Authorized Adobe Consulting and Training > > > http://www.figleaf.com > > > http://training.figleaf.com > > > > > ___ > > Flashcoders@chattyfig.figleaf.com > > To change your subscription options or search the archive: > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > Brought to you by Fig Leaf Software > > Premier Authorized Adobe Consulting and Training > > http://www.figleaf.com > > http://training.figleaf.com > > > ___ > Flashcoders@chattyfig.figleaf.com > To change your subscription options or search the archive: > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > Brought to you by Fig Leaf Software > Premier Authorized Adobe Consulting and Training > http://www.figleaf.com > http://training.figleaf.com > ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Writing code for big teams
Hi Ricardo, why do you think using Interface or Interfaces will force you to compile the collaborators code. I don't get the point. They can compile your Interfaces into their swfs and you can compile them into yours. That's what interfaces are for. No? Regards Michael On 11/8/06, Ricardo Sánchez <[EMAIL PROTECTED]> wrote: By registration code you mean register to a class? As in Object.registerClass() ? On 11/8/06, Janis Radins <[EMAIL PROTECTED]> wrote: > > just force them to execute some registration code on first frame of theyr > movie and pass instance which will accept all those calls according to > predefined communication interface > > 2006/11/8, Ricardo Sánchez <[EMAIL PROTECTED]>: > > > > Hi! > > > > Where I work we are about to begin a pretty big project collaborating > with > > some other agencies. > > > > The thing is we are going to develop the main movie with the menus and > > other > > stuff where every other movie any agency develops is going to be loaded. > > > > I was thinking about writing an interface class and give it to our > > collaborators so their main class would have to implement some specific > > methods (like start, finish, resize...) > > > > But then I thought that doing it this way will probably force us to > > compile > > their fla ourselves, and that's something we want to avoid. Every movie > > has > > to be independent and compile on itself, and then the swf should fit in > > our > > proyect. > > > > Does this make any sense? Can anyone help? > > > > Thanks. > > ___ > > Flashcoders@chattyfig.figleaf.com > > To change your subscription options or search the archive: > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > Brought to you by Fig Leaf Software > > Premier Authorized Adobe Consulting and Training > > http://www.figleaf.com > > http://training.figleaf.com > > > ___ > Flashcoders@chattyfig.figleaf.com > To change your subscription options or search the archive: > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > Brought to you by Fig Leaf Software > Premier Authorized Adobe Consulting and Training > http://www.figleaf.com > http://training.figleaf.com > ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
RE: [Flashcoders] Writing code for big teams
When working on a collaborative team on a big project, design patterns are your best friend. You should check out the Composite design pattern and/or MVC. http://www.asserttrue.com/articles/2006/10/27/max-2006 After attending their workshop, I went out and bought the book they recommended and I also recommend it. http://tinyurl.com/ygcnxs ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Writing code for big teams
By registration code you mean register to a class? As in Object.registerClass() ? On 11/8/06, Janis Radins <[EMAIL PROTECTED]> wrote: just force them to execute some registration code on first frame of theyr movie and pass instance which will accept all those calls according to predefined communication interface 2006/11/8, Ricardo Sánchez <[EMAIL PROTECTED]>: > > Hi! > > Where I work we are about to begin a pretty big project collaborating with > some other agencies. > > The thing is we are going to develop the main movie with the menus and > other > stuff where every other movie any agency develops is going to be loaded. > > I was thinking about writing an interface class and give it to our > collaborators so their main class would have to implement some specific > methods (like start, finish, resize...) > > But then I thought that doing it this way will probably force us to > compile > their fla ourselves, and that's something we want to avoid. Every movie > has > to be independent and compile on itself, and then the swf should fit in > our > proyect. > > Does this make any sense? Can anyone help? > > Thanks. > ___ > Flashcoders@chattyfig.figleaf.com > To change your subscription options or search the archive: > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > Brought to you by Fig Leaf Software > Premier Authorized Adobe Consulting and Training > http://www.figleaf.com > http://training.figleaf.com > ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Writing code for big teams
just force them to execute some registration code on first frame of theyr movie and pass instance which will accept all those calls according to predefined communication interface 2006/11/8, Ricardo Sánchez <[EMAIL PROTECTED]>: Hi! Where I work we are about to begin a pretty big project collaborating with some other agencies. The thing is we are going to develop the main movie with the menus and other stuff where every other movie any agency develops is going to be loaded. I was thinking about writing an interface class and give it to our collaborators so their main class would have to implement some specific methods (like start, finish, resize...) But then I thought that doing it this way will probably force us to compile their fla ourselves, and that's something we want to avoid. Every movie has to be independent and compile on itself, and then the swf should fit in our proyect. Does this make any sense? Can anyone help? Thanks. ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
[Flashcoders] Writing code for big teams
Hi! Where I work we are about to begin a pretty big project collaborating with some other agencies. The thing is we are going to develop the main movie with the menus and other stuff where every other movie any agency develops is going to be loaded. I was thinking about writing an interface class and give it to our collaborators so their main class would have to implement some specific methods (like start, finish, resize...) But then I thought that doing it this way will probably force us to compile their fla ourselves, and that's something we want to avoid. Every movie has to be independent and compile on itself, and then the swf should fit in our proyect. Does this make any sense? Can anyone help? Thanks. ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
