re: _root vs this.. If you have different levels and such, _root won't cut it :) thats why the _root isn't a good idea.
I do OO for FlashMX and sometimes even though its supposed to be close to pure OOP, it still feels MM only (ie you couldn't universally deploy code in AS into say DHTML? even though AS and DHTML use DOM / ECMIA style of development Although i have found ways to switch a FlashMX UI development to DHTML with allot of ease :D (MC for DHTML is just a DIV with bolted on properties.. a div for FLashMX is just a MC with bolted on properties) Scott "Mark M" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > OOP rox, but man it sometimes gets on your nerves about what are the > > DO'S & > > DON'TS (much like SQL i suppose). > > Yes OOP does rock. > > I don't think it doesn't get on your nerves as much as semi-OOP. > > in OOP you HAVE to use OOP. You have no other choice. In semi-OOP you can > always cut out of it. Leaves you with so many new ways to totally screw a system > design/methedology. > > I find in semi-OOP, I always have this desire to cheat. > > Try programming OO Actionscript - I think you will see what I mean. Especially if > you stay totally away from global variables, and limit yourself to the only > actionscript allowed on frames is 'stop()'. You just sit there going.. I wanna just > go '_root....' rather than 'this....' > > Mark > > > > > > > Scott Barnes <[EMAIL PROTECTED]> wrote: > > > > Exactly > > > > Barry and I are pulling each others eyes out with "do we do it this > > way.. is > > it better if we do it that way".. Once you get the OOP way of CFMX > > down pat, > > its now a matter of finding out whats the cleaner methods to use in > > executing the OOP and what are the bads. > > > > I've adopted the MVC / MVP Model when using Application Development, > > and i'm > > looking at Fourq.org now and seeing how this can fit into our model > > here at > > Tourism Queensland. > > > > OOP rox, but man it sometimes gets on your nerves about what are the > > DO'S & > > DON'TS (much like SQL i suppose). > > > > Scott. > > > > > > "Grant Straker" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > > > > > > > I think Steve has a good point with number 3 regarding object > > instantiation. > > > > It was brought up as a keen point at MXDU that there is a lack of > > methodologies around building a site using CFC's - lots on how to > > build > > CFC's, just not on how to efficiently instantiate, inherit and > > persist > > them in a site architecture. > > > > We have been doing a lot of modeling and testing around efficient > > methodologies and even after 14 months working with CFMX are still > > learning, although we are getting closer. > > > > We are beta testing a very efficient CFMX object architecture at the > > moment and if it holds up in production I'll write a document ( or > > put > > up a site ) outlining our approach. > > > > In the meantime you could try using script to invoke > > > > > > <cfscript> > > mathObj = createObject("component","componentsDemo.components.maths") > > bla = mathObj.Average(numbers= "#numbers#"); > > Bla2 = mathObj.Calculation(Calculation= "#Calculate#"); > > > > > > // or chain > > bla = > > ers= "#numbers#") > > > > > > </cfscript> > > > > > > Again the issue is that if the object is now required in another part > > of > > your site it needs to be re-created which is not efficient if in the > > same user session. > > > > On top of this you also have the issue of how you get efficient > > object > > instantiation if called via the Flash gateway or as a web service. > > > > Many of these things do not become an issue until you have a lot of > > load > > on the server but need to taken into account early in my view. > > > > > > > > Grant Straker > > www.straker.com.au > > > > > > > > > > > > > > -----Original Message----- > > From: Steve Onnis [mailto:[EMAIL PROTECTED] > > Sent: Thursday, February 27, 2003 2:45 AM > > To: CFAussie Mailing List > > Subject: [cfaussie] Wishlist for CFCs > > > > > > I am here by starting a wishlist for CFCs > > > > Here are my few items. > > > > 1- Ability to declaire multiple types in the "Type" attribute of the > > CFARGUMENT tag. Either by using multiple tags or using a list within > > the > > attribute. > > > > 2- Ability to dynamicly populate the "ROLES" attribute of the > > CFFUNCTION > > tag. > > > > 3- Friendlier CFINVOKE syntax so you dont have to create the object > > ovewr > > and over for methods in the same CFC. > > eg. > > > > <cfinvoke component="componentsDemo.components.maths"> > > <cfinvokemethod method="Average" returnVar="Bla"> > > <cfinvokeargument name="Numbers" value="#Numbers#"> > > </cfinvokemethod> > > <cfinvokemethod method="Sum" returnVar="Bla2"> > > <cfinvokeargument name="Calculation" > > value="#Calculate#"> > > </cfinvokemethod> > > </cfinvoke> > > > > > > I know you can do this by using the CreateObject and <CFOBJECT > > methods, > > but > > if they give us these tags to use, maybe they should be a little more > > flexible > > > > my 2 cents > > > > Steve Onnis > > > > > > > > --- > > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] > > To unsubscribe send a blank email to > > [EMAIL PROTECTED] > > > > MX Downunder AsiaPac DevCon - http://mxdu.com/ > > > > > > > > > > --- > > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] > > To unsubscribe send a blank email to > > [EMAIL PROTECTED] > > > > MX Downunder AsiaPac DevCon - http://mxdu.com/ > > createObject("component","componentsDemo.components.maths").Average(n > > umb > > > -- > ICQ: 3094740 > [EMAIL PROTECTED] > > --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/
