Sir Issac(ha ha ha) IMHO...
If you look at the non static CFC, the first thing that happens is the initialization of the property instance.Roles="public". The method Sean calls is passing back the property to the place he invokes it. What's NOT happening is the output of the WriteOutput in the cfscript block....Notice the output... >> Roles: >> Results public Testing >> >> and this when refreshed: >> >> Roles:public Testing The only thing that's different between the two calls is the "Results" Writeoutput statement not firing. The property is being passed back and displayed fine. Thus, there is nothing wrong with persisting CFC via persistent scope vars( except outputting code back to the invocation) I agree that OO is not the only solution to everything, BUT with the idea of separating Business Logic from my front-End cool things start to happen. The GUI becomes, then, a skin. Let's say company X builds a site in HTML. Two years later, they finally realize the power of FlashMX or want to provide their content over wireless devices.... The ability to strip off the GUI without affecting the back-end business logic is huge. Think of the amount of time it would take to re-write the entire app vs re-skin it! I worked with Ben Elmore (while working for RemoteSite Technologies), pre CFMX(Beta), to assist MM with building Dynamic Publishing and Workflow components to drive the content for the new site. Then we wrote a book on how to implement Dynamic Publishing with CFMX(I authored 3 chapters)...Sean is a great guy, smart architect as well. Cheers. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of S. Isaac Dealey Sent: Saturday, March 01, 2003 11:51 PM To: [EMAIL PROTECTED] Subject: RE: CFC Bugs was Re: Problem with components as session variables I think the bigger issue ( the originator's larger issue ) was the ability to create persistent instances of a CFC, i.e. session.mycfc or application.mycfc The outputting from a CFC I think was a one-off related issue... Imho the inability to output from within the CFC methods is like saying "you can't bring that lamp in here (physically carry) because it's green". I've never understood why people think that OO programming features are really awesome "but only for business logic". If you want to separate business logic from presentation, sure, I think that's a great idea, but OO is just as applicable to display or presentation as it is to business logic. That being said, I don't necessarilly believe OO is or should be the answer to every problem. (To a man with a hammer, every problem looks like a nail. -- To the guy sacking your groceries, the milk jug with its own handle is something that needs a bag :P ). I've also built my own OO features into my CMS using only features avaialable in CF 5, and can and frequently do separate presentation from business logic _without_ OO features. So I tend to think that there are frequently relationships made or inferred between OO and the separation of presentation from business logic that don't really exist. The new site sounds cool. Should be really neat to see it come online. I had no idea you'd worked with MM directly. > Thanks for the info. > In my opinion, Sean is right in this regard that CFC's > were never meant to > be used to output content from within, that is now is the > Custom Tags role. > As we move toward the OO world, the separation of GUI from > backend business > logic becomes extremely important. Not that I am telling > you anything > new...:-). I am not sure that this Page Context error > will keep me from > using CFMX since the benefits out way the costs. I worked > with Sean in SF > on Macromedia's new site. I have seen the capabilities of > the app server > and what the new site is capable of....It rocks. The MM > new site is > predominantly Flash MX frontend to backend CFMX > components....Cool Stuff. > Keep the bugs comin' I like to hear of them....:-) > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of S. Isaac Dealey > Sent: Saturday, March 01, 2003 6:46 PM > To: [EMAIL PROTECTED] > Subject: Fw: CFC Bugs was Re: Problem with components as > session > variables > Hey Dan (etc), > This is one of those known bugs I mentioned before re: > CFC's being talked > about on the cf-talk list. > Just thought anyone on the list who's not on the cf-talk > list might find it > interresting. > --- START OF FORWARDED MESSAGE > ---------------------------------------------- > From: [EMAIL PROTECTED] (Sean A Corfield) > Date: 03-01-03, 1:36:46 PM > Subject: Re: Problem with components as session variables > The infamous "page context" bug! > A CFC stored in a shared scope cannot reference other > shared scopes or > use cfoutput. The bug is that when a CFC is first created, > the context > of the page request that created it is 'stamped' on the > CFC instance. > When the CFC is referenced from a subsequent page request, > the context > is no longer valid and thus it cannot reference anything > that depends > on the page context. > And I expect this will segue nicely into a long discussion > about how > outputting HTML from a CFC method is a Bad Thing(tm)... > On Saturday, Mar 1, 2003, at 13:06 US/Pacific, Andy > Ousterhout wrote: >> The following code produces this when session initiated >> >> Roles: >> Results public Testing >> >> and this when refreshed: >> >> Roles:public Testing >> >> Problem is that the write in the getRoles method does >> nothing the >> second time >> application.cfm calls roles. why? >> >> CODE: >> >> index.cfm: >> >> <cfoutput>Testing<c/foutput> >> >> application.cfm: >> >> <cfapplication name="omg" >> clientmanagement="no" >> sessionmanagement="yes" >> setclientcookies="no" >> setdomaincookies="no" >> sessiontimeout="#CreateTimeSpan(0,0,0,60)#"> >> >> <CFLOCK timeout="3" throwontimeout="Yes" scope="Session" >> type="EXCLUSIVE"> >> <CFSCRIPT> >> IF (NOT ISDEFINED("session.User")) { >> session.User = createObject("component", >> "user"); // >> Instantiate User >> } >> </CFSCRIPT> >> >> <cfoutput>Roles:#session.User.getroles()#</cfoutput> >> </cflock> >> >> user.cfc: >> >> <cfcomponent> >> >> <!--- Create a single handle for the instance data ... >> ---> >> <cfscript> >> instance.Roles="public"; >> </cfscript> >> >> <cffunction name="getRoles" access="public" >> returntype="string" >> output="true"> >> <cfscript> >> writeoutput ("<br>Results"); >> </cfscript> >> <cfreturn instance.roles/> >> </cffunction> >> >> </cfcomponent> > s. isaac dealey 954-776-0046 > new epoch http://www.turnkey.to > lead architect, tapestry cms http://products.turnkey.to > tapestry api is opensource http://www.turnkey.to/tapi > certified advanced coldfusion 5 developer > http://www.macromedia.com/v1/handlers/index.cfm?ID=21816 > ----------------------------------------------- > To post, send email to [EMAIL PROTECTED] > To unsubscribe: > Send UNSUBSCRIBE to [EMAIL PROTECTED] > To subscribe / unsubscribe: http://www.dfwcfug.org > ----------------------------------------------- > To post, send email to [EMAIL PROTECTED] > To unsubscribe: > Send UNSUBSCRIBE to [EMAIL PROTECTED] > To subscribe / unsubscribe: http://www.dfwcfug.org s. isaac dealey 954-776-0046 new epoch http://www.turnkey.to lead architect, tapestry cms http://products.turnkey.to tapestry api is opensource http://www.turnkey.to/tapi certified advanced coldfusion 5 developer http://www.macromedia.com/v1/handlers/index.cfm?ID=21816 ----------------------------------------------- To post, send email to [EMAIL PROTECTED] To unsubscribe: Send UNSUBSCRIBE to [EMAIL PROTECTED] To subscribe / unsubscribe: http://www.dfwcfug.org ----------------------------------------------- To post, send email to [EMAIL PROTECTED] To unsubscribe: Send UNSUBSCRIBE to [EMAIL PROTECTED] To subscribe / unsubscribe: http://www.dfwcfug.org
