[Arp] Child Form .. Child Form ... Structuring in Arp
Tien Nguyen
sufibaba at gmail.com
Wed Jan 11 10:50:48 PST 2006
Hi Sam,
Thanks for your input, it seems that we are taking a similar path. However,
I am not very clear as to your implementation explanation. Can you send me
a sample file so I can better see the structure.
Cheers
On 1/11/06, Sam Shrefler <sshrefler at gmail.com> wrote:
>
> Tien:
>
> I just posted this on the message detailing uses for Arp: I haven't
> gotten Aral's response about it yet, but this is how I handle subControllers
>
> I didn't exactly implement a controller for every form. I have a feeling
> that my approach was similar to yours becuase I had some help from Darron.
> I didn't choose to use *external* forms because my project is not that big
> and I'm working on it alone, so every form was developed in one swf using
> flashIDE (i'll refer to this as my application swf). I then have a loader
> swf which simply loads the entire application. My application does the
> _proto root hack to have my Application class control the root timeline. I
> then have a controller for each direct form placed on my root timeline.
>
> An example of my layout is as follows
>
> Application (root)
> - Parent1
> -Child1
> -Child2
> -Child3
> - Parent2
> -Child4
> -Child5
> -Parent3
>
> Therefore, Application has a controller that handles Parent1, Parent2, and
> Parent3. Parent1 has a controller that handles Child1, Child2, Child3.
> Parent2 has a controller that handles Child4, Child5 and so on. I believe
> I could just as easily make Parent1 an *external* form similar to what you
> described.
>
> On 1/11/06, Tien Nguyen <sufibaba at gmail.com > wrote:
> >
> > Very Clear explanation Aral,
> >
> > I'll give it a go. In terms of Controllers, would it be advisable to
> > create sub-controllers; I was thinking about one controller for each Parent,
> > instead of using the main Controller.as for everything.
> >
> > Cheers,
> >
> >
> >
> > On 1/11/06, Aral Balkan <aral at ariaware.com > wrote:
> > >
> > > Hi Tien,
> > >
> > > > ///// CASE1///////
> > > >
> > > > App
> > > > --- Form (onload, gets data from database, populate combo boxes in
> > > > form 1 and form 2)
> > >
> > > //
> > > // Untested code
> > > // In Form:
> > > function onLoad()
> > > {
> > > dispatchEvent ( { type: GET_THIS_FORMS_DATA_EVENT } );
> > > }
> > >
> > > //
> > > // Called from Command on success
> > > // "theData" set in the Model in the Command
> > > //
> > > function onGetThisFormsDataSuccess ()
> > > {
> > > var theData:TypeOfModel = ModelLocator.getModel("theData");
> > > form1.updateData( theData );
> > > form2.updateData( theData );
> > > }
> > >
> > > Then the updateData methods in the child forms will handle population
> > > of
> > > the components. This is with the ModelLocator currently in SVN. Now,
> > > with the ModelLocator in Arp 3 (based on Christophe's), form1 and
> > > form2
> > > would listen for changes on the "theData" directly. You can see how
> > > this
> > > is a much better method as it does away with the ugly method
> > > onGetThisFormsDataSuccess() whose only purpose is to move around data.
> > > (You can still have a success handler that actually updates the View
> > > and
> > > handles View logic.)
> > >
> > > > ////CASE2//////
> > > >
> > > > App
> > > > --- Form (onload, get data from database, call form1retrievedata() )
> > > > ----- form1 ( form1retrievedata(); gets data from database and
> > > > populate combox box in form1)
> > >
> > > Combine both data calls into one -- pass one VO back (to Form). Then
> > > see
> > > example above.
> > >
> > > hth,
> > > Aral
> > >
> > > _______________________________________________
> > > Arp mailing list
> > > Arp at ariaware.com
> > > http://ariaware.com/mailman/listinfo/arp_ariaware.com
> > >
> >
> >
> > _______________________________________________
> > Arp mailing list
> > Arp at ariaware.com
> > http://ariaware.com/mailman/listinfo/arp_ariaware.com
> >
> >
> >
>
> _______________________________________________
> Arp mailing list
> Arp at ariaware.com
> http://ariaware.com/mailman/listinfo/arp_ariaware.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ariaware.com/pipermail/arp_ariaware.com/attachments/20060111/72f23574/attachment.htm
More information about the Arp
mailing list