cfobjects-developers Mailing List for cfObjects Application Framework
Brought to you by:
orbwave
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
(2) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2003 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
From: Soleeroo <sol...@ya...> - 2004-12-14 10:11:33
|
Hi folks. Can anyone tell me where can I find further infos about the next steps in the tutorial? Now I'd like to implement the three hyperlinks on the homepage but no idea how to proceed... basically the buildNavigation.cfm has a reference to the handler.cfm but I have no handler.cfm (yet) thanks. S. __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 |
From: Soleeroo <sol...@ya...> - 2004-11-29 12:04:02
|
Hi Folks. couple of questions... what if my downloaded v.3.1 doesn't include the cfo_basetags.zip file which is referenced in the Getting Started section? is there some sort of tutorial available just to see the framework in action? Cheers, soleeroo __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail |
From: Steve B. <Ste...@ef...> - 2004-10-05 17:25:32
|
I'm hoping that there are still developers out there interested in = cfObjects. I've spent a lot of time in the past year making the framework more = solid, faster and more robust. I'm planning on releasing version 4.0 soon with = a lot of new features and was wondering if anyone on this list was still = active in using cfObjects. - Steve |
From: Vladimir M. <MA...@WE...> - 2003-01-21 16:55:02
|
Hi guys, I'm unsuccessfully trying to install CFObjects-3.1.0. The instructions on http://cfobjects.sourceforge.net/tutorial/step_01.html do not help. The download is the single zip file, but the tutorial references different ones. I'm definitely missing something. Please help. Thank you, Vladimir |
From: Ben B. <be...@el...> - 2002-03-18 18:20:18
|
If a class implements another class and you call a method that exists in the class's parent only, the method won't be found. The parent of a class is never searched if a class implements another class. Benjamin Bloodworth=20 Advanced Certified ColdFusion 5.0 Developer=20 ElectroNet <http://www.electronet.net> - 850.222.0229=20 |
From: Steven B. <or...@ms...> - 2002-03-02 01:51:55
|
Yeah, send it to me please. I'd like to take a look at it. >From: "Ben Bloodworth" <be...@el...> >To: "Steven Brownlee" <or...@ms...> >Subject: RE: [cfobjects-developers] Super Object vs. instance properties >Date: Fri, 1 Mar 2002 16:02:30 -0500 > >It doesn't force object to be the parent. If a superclass key is >identified or .notation is used, it overrides object as parent. Object >becomes the parent by default, if nothing is specified. The class is >applied to the copy of the object class, not the other way around. This >new class is then saved back to the class registry under the appropriate >name. Object will never have more keys than what is specified in the >object class file and other classes will have all of the keys of the >object class plus any that they define. > >While using .notation is nice for defining parents on the fly, I also >like being able to specify the parent in one spot, so that I don't have >to specify it every time. Also, if I decide to change inheritance of >classes I can change it in one spot and it applies it everywhere. > >What probably will work best is supporting both options. It's >definitely useful to be able to specify things on the fly. > >Do you want me to send you what I have done for reference purposes? > >-----Original Message----- >From: Steven Brownlee [mailto:or...@ms...] >Sent: Friday, March 01, 2002 3:30 PM >To: cfo...@li... >Subject: RE: [cfobjects-developers] Super Object vs. instance properties > > >Ah, I get it now. I thought all keys would get inserted into the Object > >class registration, but now I see that you are copying it and applying >the >copy to the class. > >The only thing that I still don't like is the forcing of Object to be >the >parent and superClass of the class being registered. To me, it just >seems >counterproductive to have developers set the superClass of each class in >the >definition file when we can have the framework do it for them by >default. >In addition, I think it helps non-OOP developers learn how setting up >their >directory structure can mimic inheritance. My goal is to make cfObjects >as >easy to learn and as quick to implement as possible. The less code the >better. > >That all said, I think you came up with a very innovative implementation >of >cfObjects - which is whole point. All ideas lead to making the >framework >better. > >Now that I consider it more, I think there's a way to combine what you >have >done into the current tag functionality. With the 3.0.6.2 patch I >uploaded, >there's an undocumented feature where you can specify implemented >classes on >the fly without needing to specify them in the class definition file. > ><cf_cfoCreateObject class="Class" implements="ParentClass,OtherClass"> > >By doing it this way, you eliminate the need for any code in the class >definition file altogether. I can also have cfoRegisterClass override >the >parent key when the structure is copied. > >Let me play around with it and let you know what I come up with. We can >try >to find a best-of-breed implementeation. > > > >From: "Ben Bloodworth" <be...@el...> > >To: "Steven Brownlee" <or...@ms...> > >Subject: RE: [cfobjects-developers] Super Object vs. instance >properties > >Date: Fri, 1 Mar 2002 14:25:15 -0500 > > > >Steven: > >I'll post some code snippets and hopefully things will be clearer: > > > >First the class.cfm for the object class: > >stClassDef = structNew(); > >stClassDef.className = "Object"; > >stClassDef.superclass = "Object"; > >stClassDef.parent = "Object"; > >stClassDef.lib = trim(lib); > >stClassDef.methods = StructNew(); > >stClassDef.implements = ArrayNew(1); > > > >These were keys, with the exception of implements, that all classes >were > >getting from cfoRegisterClass and set in the cfoClassRegistry variable. > >All I did was change where these keys are generated and when they are > >available to the framework. > > > >In the current version, in every class.cfm file you have to include the > >line: > > > >stClassDef = StructNew(); > > > >In my version this is eliminated for all class.cfm files except for > >object. > > > >In the current version, if you want to implement another classes > >methods, you have to add the line: > > > >stClassDef.implements = ArrayNew(1); > > > >In my version the need for this is eliminated. You can start adding to > >the array the objects you want to implement. For Example: > > > >stClassDef.implements[1] = "aClass"; > > > >In cfoRegisterClass, before it tries searching for the class.cfm file >of > >the object it is trying to create, it checks to see if the object class > >has already been registered. If it has, it makes a copy of it. When it > >does find the class.cfm for the current class, all keys defined in the > >class.cfm file override the keys defined in the copy of object. > > > >A sample class.cfm using my version could look like this: > > > ><cfscript> > >stClassDef.className = "aClass"; // this is still optional. > >stClassDef.implements[1] = "SomeOtherClass"; > >stClassDef.superclass = "aParentClass"; // optional. if not defined, >set > >to object > ></cfscript> > > > >In functionality, it's not really any different than what you have now. > >The same events happen, just in different places. It offers the >benefit > >of eliminating two lines from the class.cfm and easier expansion if you > >decide to add a key that expands the framework. You could add the key > >to object's class.cfm and it would be available to all objects, instead > >of having to edit cfoRegisterClass. It would also be available before > >the class.cfm was included. > > > >The cfsetting is more of a minor thing. I moved the cfsetting tags to > >wrap the whole call so that nothing is output without cfoutput, except > >for method code. There were areas where things were not being caught >by > >either cfsilent or cfsetting. > > > >Hopefully, this helps clear things up a little. > >-----Original Message----- > >From: Steven Brownlee [mailto:or...@ms...] > >Sent: Friday, March 01, 2002 10:56 AM > >To: cfo...@li... > >Subject: [cfobjects-developers] Super Object vs. instance properties > > > > > >Ben: > > > >Why would you want to have all keys inherited by all objects? Let me > >know > >if I'm reading that wrong. You state "You can add new keys to the > >object > >class that you want all objects to inherit, instead of having to add > >them to > >the cfoCreateObject tag." These are properties of the object, not keys > >of > >the class, so I'm confused about what you actually mean. If you take > >all > >object-scope properties and assign them to the object class instead, > >then > >you remove the distinctiveness of all objects. Again, let me know if > >I'm > >off base here on what you're saying. > > > >Also, the reason that I made the changes in 3.x was so that the class' > >namespace would dictate what its parent was - unless overriden. This > >makes > >the framework much more OO compliant IMO. It already makes object the > >oldest grandparent of every class, so I'm not sure what benefit your > >change > >provides by forcing object to be the parent of every class. > > > >I think I'm confused about what you've done. Could you provide some > >code > >examples and the benefits? > > > >Lastly, the <cfsetting> tag doesn't really remove a whole lot of white > >space. <cfsilent> seemed to do a much better job. At least with the > >tests > >I did. > > > >Thanks in advance. > > > >- Steve > > > >-----Original Message----- > >From: Ben Bloodworth [mailto:be...@el...] > >Sent: Friday, March 01, 2002 8:09 AM > >To: web...@or... > >Subject: RE: The cfobjects website is down > > > > > >Steven, > >I didn't know there was such a thing, so please subscribe me. > > > >I have some updates to the 3.0.6 release if you like me to send them to > >you. > > I'll highlight the changes I made below. > > > >Most of the keys that were assigned to a class during the register >class > > > >call have been moved to the class definition for the object class. > > > >When cfoRegisterClass is called, it first checks to see if the object > >class > >has already been registered. If it has been registered it creates a >copy > >of > >it and then keys from the class that is to be registered are copied >into > >it. > > If object isn't registered, it registers it first and then continues > >registering the class it was on. > > > >The combination of these two changes does a couple of things. You can > >add > >new keys to the object class that you want all objects to inherit, > >instead > >of having to add them to the cfoCreateObject tag. It also removed the > >need > >to specify stClassDef = StructNew() in all class.cfm files. In fact, > >unless > >that line is removed, it won't work. > > > >I made object's superclass object and put in a check when registering > >classes to stop registering a class if the superclass is the same as >the > > > >class. When combined with the change above, all classes will have > >object as > >their superclass unless superclass is overridden in the class.cfm file. > > > >I removed cfoutput call from the method include lines in > >cfoInvokeMethod. > >That should help speed things up. I removed all references to cfsilent > >and > >instead wrapped the cfoTags in cfsetting enablecfoutputonly=yes, which > >cuts > >way back on whitespace. > >-----Original Message----- > >From: Steven Brownlee [mailto:web...@or...] > >Sent: Thursday, February 28, 2002 5:02 PM > >To: Ben Bloodworth > >Subject: RE: The cfobjects website is down > > > > > >Ben I passed this message along. Also, would like to be subscribed to > >the > >cfobjects-developers mailing list? > >-----Original Message----- > >From: Ben Bloodworth [mailto:be...@el...] > >Sent: Thursday, February 28, 2002 3:57 PM > >To: web...@or... > >Subject: The cfobjects website is down > > > > > >To whom it concerns, > > > >I have been unable to reach the cfobjects website all week. If you >have > >any > >control over the cfobjects website, please check into why it is not > >responding. > > > > > >Benjamin Bloodworth > >Advanced Certified ColdFusion 5.0 Developer > >ElectroNet - 850.222.0229 > > > > > >_________________________________________________________________ > >Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > > >_______________________________________________ > >cfobjects-developers mailing list > >cfo...@li... > >https://lists.sourceforge.net/lists/listinfo/cfobjects-developers > > > > >_________________________________________________________________ >Join the world's largest e-mail service with MSN Hotmail. >http://www.hotmail.com > > >_______________________________________________ >cfobjects-developers mailing list >cfo...@li... >https://lists.sourceforge.net/lists/listinfo/cfobjects-developers _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com |
From: Steven B. <or...@ms...> - 2002-03-01 20:29:54
|
Ah, I get it now. I thought all keys would get inserted into the Object class registration, but now I see that you are copying it and applying the copy to the class. The only thing that I still don't like is the forcing of Object to be the parent and superClass of the class being registered. To me, it just seems counterproductive to have developers set the superClass of each class in the definition file when we can have the framework do it for them by default. In addition, I think it helps non-OOP developers learn how setting up their directory structure can mimic inheritance. My goal is to make cfObjects as easy to learn and as quick to implement as possible. The less code the better. That all said, I think you came up with a very innovative implementation of cfObjects - which is whole point. All ideas lead to making the framework better. Now that I consider it more, I think there's a way to combine what you have done into the current tag functionality. With the 3.0.6.2 patch I uploaded, there's an undocumented feature where you can specify implemented classes on the fly without needing to specify them in the class definition file. <cf_cfoCreateObject class="Class" implements="ParentClass,OtherClass"> By doing it this way, you eliminate the need for any code in the class definition file altogether. I can also have cfoRegisterClass override the parent key when the structure is copied. Let me play around with it and let you know what I come up with. We can try to find a best-of-breed implementeation. >From: "Ben Bloodworth" <be...@el...> >To: "Steven Brownlee" <or...@ms...> >Subject: RE: [cfobjects-developers] Super Object vs. instance properties >Date: Fri, 1 Mar 2002 14:25:15 -0500 > >Steven: >I'll post some code snippets and hopefully things will be clearer: > >First the class.cfm for the object class: >stClassDef = structNew(); >stClassDef.className = "Object"; >stClassDef.superclass = "Object"; >stClassDef.parent = "Object"; >stClassDef.lib = trim(lib); >stClassDef.methods = StructNew(); >stClassDef.implements = ArrayNew(1); > >These were keys, with the exception of implements, that all classes were >getting from cfoRegisterClass and set in the cfoClassRegistry variable. >All I did was change where these keys are generated and when they are >available to the framework. > >In the current version, in every class.cfm file you have to include the >line: > >stClassDef = StructNew(); > >In my version this is eliminated for all class.cfm files except for >object. > >In the current version, if you want to implement another classes >methods, you have to add the line: > >stClassDef.implements = ArrayNew(1); > >In my version the need for this is eliminated. You can start adding to >the array the objects you want to implement. For Example: > >stClassDef.implements[1] = "aClass"; > >In cfoRegisterClass, before it tries searching for the class.cfm file of >the object it is trying to create, it checks to see if the object class >has already been registered. If it has, it makes a copy of it. When it >does find the class.cfm for the current class, all keys defined in the >class.cfm file override the keys defined in the copy of object. > >A sample class.cfm using my version could look like this: > ><cfscript> >stClassDef.className = "aClass"; // this is still optional. >stClassDef.implements[1] = "SomeOtherClass"; >stClassDef.superclass = "aParentClass"; // optional. if not defined, set >to object ></cfscript> > >In functionality, it's not really any different than what you have now. >The same events happen, just in different places. It offers the benefit >of eliminating two lines from the class.cfm and easier expansion if you >decide to add a key that expands the framework. You could add the key >to object's class.cfm and it would be available to all objects, instead >of having to edit cfoRegisterClass. It would also be available before >the class.cfm was included. > >The cfsetting is more of a minor thing. I moved the cfsetting tags to >wrap the whole call so that nothing is output without cfoutput, except >for method code. There were areas where things were not being caught by >either cfsilent or cfsetting. > >Hopefully, this helps clear things up a little. >-----Original Message----- >From: Steven Brownlee [mailto:or...@ms...] >Sent: Friday, March 01, 2002 10:56 AM >To: cfo...@li... >Subject: [cfobjects-developers] Super Object vs. instance properties > > >Ben: > >Why would you want to have all keys inherited by all objects? Let me >know >if I'm reading that wrong. You state "You can add new keys to the >object >class that you want all objects to inherit, instead of having to add >them to >the cfoCreateObject tag." These are properties of the object, not keys >of >the class, so I'm confused about what you actually mean. If you take >all >object-scope properties and assign them to the object class instead, >then >you remove the distinctiveness of all objects. Again, let me know if >I'm >off base here on what you're saying. > >Also, the reason that I made the changes in 3.x was so that the class' >namespace would dictate what its parent was - unless overriden. This >makes >the framework much more OO compliant IMO. It already makes object the >oldest grandparent of every class, so I'm not sure what benefit your >change >provides by forcing object to be the parent of every class. > >I think I'm confused about what you've done. Could you provide some >code >examples and the benefits? > >Lastly, the <cfsetting> tag doesn't really remove a whole lot of white >space. <cfsilent> seemed to do a much better job. At least with the >tests >I did. > >Thanks in advance. > >- Steve > >-----Original Message----- >From: Ben Bloodworth [mailto:be...@el...] >Sent: Friday, March 01, 2002 8:09 AM >To: web...@or... >Subject: RE: The cfobjects website is down > > >Steven, >I didn't know there was such a thing, so please subscribe me. > >I have some updates to the 3.0.6 release if you like me to send them to >you. > I'll highlight the changes I made below. > >Most of the keys that were assigned to a class during the register class > >call have been moved to the class definition for the object class. > >When cfoRegisterClass is called, it first checks to see if the object >class >has already been registered. If it has been registered it creates a copy >of >it and then keys from the class that is to be registered are copied into >it. > If object isn't registered, it registers it first and then continues >registering the class it was on. > >The combination of these two changes does a couple of things. You can >add >new keys to the object class that you want all objects to inherit, >instead >of having to add them to the cfoCreateObject tag. It also removed the >need >to specify stClassDef = StructNew() in all class.cfm files. In fact, >unless >that line is removed, it won't work. > >I made object's superclass object and put in a check when registering >classes to stop registering a class if the superclass is the same as the > >class. When combined with the change above, all classes will have >object as >their superclass unless superclass is overridden in the class.cfm file. > >I removed cfoutput call from the method include lines in >cfoInvokeMethod. >That should help speed things up. I removed all references to cfsilent >and >instead wrapped the cfoTags in cfsetting enablecfoutputonly=yes, which >cuts >way back on whitespace. >-----Original Message----- >From: Steven Brownlee [mailto:web...@or...] >Sent: Thursday, February 28, 2002 5:02 PM >To: Ben Bloodworth >Subject: RE: The cfobjects website is down > > >Ben I passed this message along. Also, would like to be subscribed to >the >cfobjects-developers mailing list? >-----Original Message----- >From: Ben Bloodworth [mailto:be...@el...] >Sent: Thursday, February 28, 2002 3:57 PM >To: web...@or... >Subject: The cfobjects website is down > > >To whom it concerns, > >I have been unable to reach the cfobjects website all week. If you have >any >control over the cfobjects website, please check into why it is not >responding. > > >Benjamin Bloodworth >Advanced Certified ColdFusion 5.0 Developer >ElectroNet - 850.222.0229 > > >_________________________________________________________________ >Chat with friends online, try MSN Messenger: http://messenger.msn.com > > >_______________________________________________ >cfobjects-developers mailing list >cfo...@li... >https://lists.sourceforge.net/lists/listinfo/cfobjects-developers _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com |
From: Steven B. <or...@ms...> - 2002-03-01 15:56:17
|
Ben: Why would you want to have all keys inherited by all objects? Let me know if I'm reading that wrong. You state "You can add new keys to the object class that you want all objects to inherit, instead of having to add them to the cfoCreateObject tag." These are properties of the object, not keys of the class, so I'm confused about what you actually mean. If you take all object-scope properties and assign them to the object class instead, then you remove the distinctiveness of all objects. Again, let me know if I'm off base here on what you're saying. Also, the reason that I made the changes in 3.x was so that the class' namespace would dictate what its parent was - unless overriden. This makes the framework much more OO compliant IMO. It already makes object the oldest grandparent of every class, so I'm not sure what benefit your change provides by forcing object to be the parent of every class. I think I'm confused about what you've done. Could you provide some code examples and the benefits? Lastly, the <cfsetting> tag doesn't really remove a whole lot of white space. <cfsilent> seemed to do a much better job. At least with the tests I did. Thanks in advance. - Steve -----Original Message----- From: Ben Bloodworth [mailto:be...@el...] Sent: Friday, March 01, 2002 8:09 AM To: web...@or... Subject: RE: The cfobjects website is down Steven, I didn't know there was such a thing, so please subscribe me. I have some updates to the 3.0.6 release if you like me to send them to you. I'll highlight the changes I made below. Most of the keys that were assigned to a class during the register class call have been moved to the class definition for the object class. When cfoRegisterClass is called, it first checks to see if the object class has already been registered. If it has been registered it creates a copy of it and then keys from the class that is to be registered are copied into it. If object isn't registered, it registers it first and then continues registering the class it was on. The combination of these two changes does a couple of things. You can add new keys to the object class that you want all objects to inherit, instead of having to add them to the cfoCreateObject tag. It also removed the need to specify stClassDef = StructNew() in all class.cfm files. In fact, unless that line is removed, it won't work. I made object's superclass object and put in a check when registering classes to stop registering a class if the superclass is the same as the class. When combined with the change above, all classes will have object as their superclass unless superclass is overridden in the class.cfm file. I removed cfoutput call from the method include lines in cfoInvokeMethod. That should help speed things up. I removed all references to cfsilent and instead wrapped the cfoTags in cfsetting enablecfoutputonly=yes, which cuts way back on whitespace. -----Original Message----- From: Steven Brownlee [mailto:web...@or...] Sent: Thursday, February 28, 2002 5:02 PM To: Ben Bloodworth Subject: RE: The cfobjects website is down Ben I passed this message along. Also, would like to be subscribed to the cfobjects-developers mailing list? -----Original Message----- From: Ben Bloodworth [mailto:be...@el...] Sent: Thursday, February 28, 2002 3:57 PM To: web...@or... Subject: The cfobjects website is down To whom it concerns, I have been unable to reach the cfobjects website all week. If you have any control over the cfobjects website, please check into why it is not responding. Benjamin Bloodworth Advanced Certified ColdFusion 5.0 Developer ElectroNet - 850.222.0229 _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com |
From: Steven B. <or...@ms...> - 2002-03-01 02:49:34
|
Rocky: ******** On all future correspondance, let's use the cfobjects-developers mailing list to post our ideas. I like to have an archive of all meaningfull conversations about the framework, and since the cfObjects.com site is down, the mailing list is the only to do it. I added you to the subscribers list. ******** I get the concept, but I'll take a closer look at it to wrap my brain around more thoroughly. In fact, your concept isn't far off from the approach I take. I create a parent class called UIElement for every application I build. As children are things like - page, toolbar, navigation - among others whose sole responsibilities are creating the UI for the application. These contain 95% of the HTML for the application. Now, the event system's purpose is to do exactly what you are doing, and what I *should* be doing, but I rarely take the time to be 100% OO in my approach. Nor do I think it necessary to be 100% compliant. Here's an example of a completely event-based site's structure. The methods below are the ones that a designer would build and then pass off to the developers. It simply builds the HTML structure of the site. UIElement.Page.buildStructure method ------------------------------------ <--- Show the page definition tags (HTML, HEAD, TITLE, BODY, etc..) ---> <cf_cfoInvokeMethod object="#self#" method="buildDocumentHeader"> <cf_cfoRaiseEvent eventName="afterDocumentHeaderBuild"> <table width="780" border="0" cellspacing="0" cellpadding="0"> <tr> <td> <cf_cfoRaiseEvent eventName="beforePageHeaderBuild"> <cf_cfoInvokeMethod object="#self#" method="buildPageHeader"> <cf_cfoRaiseEvent eventName="afterPageHeaderBuild"></td> </tr> </table> <table width="780" border="0" cellspacing="0" cellpadding="0" id="mainbgcolor"> <tr> <td width="100%"> <table border="0" cellspacing="0" cellpadding="0" bgcolor="#ffffff"> <tr> <!--- BEGIN LEFT BAR SECTION ---> <td width="155" valign="top" class="leftSectionBody"> <cf_cfoRaiseEvent eventName="beforeLeftBarBuild"> <cf_cfoInvokeMethod object="#self#" method="buildLeftBar"> <cf_cfoRaiseEvent eventName="afterLeftBarBuild"> </td> <td width="6"><cfoutput><img src="#application.imageDir#blank.gif" width="6" height="1" border="0" alt=""></cfoutput></td> <!--- BEGIN MAIN CONTENT SECTION (RIGHT SIDE) ---> <td valign="top" width="619"> <cfoutput><img src="#application.topDir#images/blank.gif" width="126" height="5" alt="" border="0"></cfoutput><br> <cf_cfoRaiseEvent eventName="beforeContentDisplay"> UIElement.Page.destructor method -------------------------------- <cf_cfoRaiseEvent eventName="afterContentDisplay"> </td> </tr> </table> </td> </tr> </table> <cf_cfoRaiseEvent eventName="beforeFooterDisplay"> <cf_cfoInvokeMethod object="#self#" method="showFooter"> UIElement.Page.showFooter method -------------------------------- <!-- Footer --> <table width="760" border="0" cellspacing="10" cellpadding="0"> <tr> <td class="small"> <br><br><br> <div align="center" id="footer">All contents © 2000-2002 MyCompany.</div> </td> </tr> </table> <cf_cfoRaiseEvent eventName="afterFooterDisplay"> </body> </html> To build a web page, you simply need to create the page class. <cf_cfoCreateObject class="UIElement.page" title="Page Title"> As you can see, every element of the site is being passed off to a separate method, and an event is raised before and after each of these elements. This way, the developer can customize the functionality of the entire application without ever needing to worry about the design of the site. Data/output can be displayed anywhere she wishes. This leads to an incredible amount of flexibility. A designer can completely redesign the site and it wouldn't affect the work of the developers at all. Now this can be taken one step further and a designer can actually lay out the different views (as you have done), stuff them in methods of, say, the UIElement.view class. The developer only need to code the output and then pass the results to the view. User.showRandomData method -------------------------- <cfquery name="q_query_name"> {SQL Code Here} </cfquery> <cf_cfoInvokeMethod method="UIElement.view.multiRowOutput.buildRows" query="#q_query_name#" title="Random Data Output"> As I hope you can see, we achieve the same level of seperation of design and code, but we approach it in different ways. Designers never have to worry about breaking code and developers never have to worry about making their data look pretty. Either way, we both achieve the best possible environment for building applications for the Web. - Steve -----Original Message----- From: Rocky Palladino [mailto:roc...@us...] Sent: Thursday, February 28, 2002 8:27 PM To: web...@or... Subject: Re: cfoMVC > >> Please explain. I'd be interested to hear why you felt you >> couldn't >do it with the existing set of tags. I've built many sites already that >separate logic and design using the tags. I know that you've done a lot of work with the event handling system. I must confess to not spending much time using the associated tags. While it is likely that I could achieve the same result -- separation of logic and display -- using these tags, I haven't yet taken the time to investigate them thoroughly. It's one of the many things on my to-do list! I suspect, however, that cfoMVC offers a different, not necessarily better or worse (at least, I hope not!), means towards our stated end. The two approaches could possibly be used in combination to great effect. When I first started using cfobjects (back in the 1.0 days), the whole idea of OOP was new to me. I had taken a C++ class at university, but just barely passed and never suspected I'd end up as a programmer in any capacity. But here I am. At any rate, the idea of objects was something about which I had only a vague notion. Reading through Ralph's documentation, I became intrigued by the model-view-controller paradigm to which he referred often. The MVC paradigm formed the basis for the implementation of cfobjects as an application framework. The model end of the triad is well thought out, developed and tested; it was the primary motivation for creating cfobjects in the first place. The view and controller are, in my opinion, somewhat less well shaped. We have "view" pages corresponding to navigable files in a web directory and a controller mechanism ("handler.cfm") that merely selects one of these views based on the value of a url or form scoped variable ("event"). It is simply effective. But I found it lacking, and not completely in keeping, with respect to the separation of model, view and controller as I understood it. Keep that last thought in mind as you read on, because my entire conception of MVC may be off base. I have no experience with implementation of MVC in any language outside of coldfusion. Everything I know about OOP I learned from cfobjects. It is true that this original implementation achieved a separation between the model and the view, but I failed to grasp how to achieve a clear separation between the view and the controller. The problem for me was always this: Where should I put my html? Should html go in the method? Should it go in the view? Can it go in both? Does it matter? If one of the aims is to separate roles of designer and developer, how can I justify putting html in the method? Or conversely, putting cfo calls in the view? I couldn't. My typical cfobjects "view" page became a mix of cfoCreateObject, cfoInvokeMethod, etc. tags that controlled *what* data was to be displayed and of html and cfml tags that controlled *how* that data was to be displayed. I began to place all the cfobjects code up at the top of my template and all the html code underneath to approximate some (visual) separation between the two. This led me to the realization that everything in the top of the page (the cfo tag calls) could be taken out of the "view" and placed in a "controller" file that was somehow linked. Including a file on every page was one solution, but I figured it would be more messy than helpful. What I ended up with is much cleaner and makes use of existing mechanisms provided by the framework. For every application, I create a class that I label "app," although the specific name chosen is entirely unimportant. I add a method to this class (or its subclasses) for every view page in my application that I want to "control". In these methods I code the cfobjects calls that I need to get the data I want to display. Then, I return that data to the view. The view page contains only the html and cfml necessary to display the data. The view and controller are tied together using cfoMVC, which I designed to be placed in Application.cfm and called on each http request. I've found the processing overhead to be minimal and definitely worthy of the tradeoff with code maintainability. The tag determines what the current view is, invokes a corresponding method of a class that the developer can programmatically specify, and returns the data to the view. You could have a class hierarchy of controllers corresponding to the hierarchy of view directories, or put all the controllers in a single class, or some combination thereof. If there is no controller method for a particular view, (i.e. a cfo.Error.MethodNotFound error is thrown) then we just display the view and assume it knows what it is doing. The idea here is that using cfoMVC allows you to separate controller logic from the view, but doesn't *require* it. Some view pages may just display static data and need no controller. Some times it is just quicker to invoke a method and display the results all in the view. So why bother? I like this approach because I can code all the logic of an application in my "app" class(es) and build "dummy" views that simply show what data is passed to it from the controller. Then the designer (who also happens in most cases to be me, but never mind that...) can come in and code all the view pages knowing what data is present, but without knowing how or from whence any of it came. Or vice-versa, if you believe in building the UI before the application. I do not include a stitch of html in any of my model classes or any of the controller methods. As it should be, all html is in the view (or UI classes, see below for more on that). The model and the controllers only know about data: where it is, how to get it, and how to set it. The model has no idea that anyone is using its data for display purposes. It doesn't really care. The controller knows it's getting data from the model with the expressed intent of displaying it in a view. The only purpose of the view is to decide how to display the data it knows it will receive from the controller. It is possible that all of this could have been avoided by utilizing an extensive set of UI classes invoked in the view, but for the sake of processing speed, I decided against this early on. I don't know if you've had experience with using cfobjects on Solaris (which is what I primarily use), but until the recent versions, it was God-awfully slow. Any more than about 4-5 cfoInvokeMethods in any given request would be unbearable. Thus, I never used a Page object, or any such UI class. I use cfobjects *only* for modeling my data and use html, cfml, custom tags, includes, etc., for the display of it as they tend to process much more quickly. Anecdotally, this approach has already paid off in one case in a totally unintended way. Whilst working on an application, I accidentally deleted a directory (don't ask) that contained view pages. I hadn't yet imported the project into the CVS repository and had no backup of the files at all. But the class library was still intact, so I had all the controllers. It was a simple matter to rebuild each of the deleted pages just by looking at the controller and remembering how I displayed the data. Since most of the page layout is built from include files anyway (for the header, and footer, etc.), it took me only about an hour to recode about 20 view pages. If I had left the controller and view code all in the same page, I would have lost about 3 weeks of work. I shudder to think of the fallout that surely would have resulted from this stupid blunder had the application not been structure thusly. The experience taught me two lessons: 1) Daily CVS commits! 2) Having the view and the controller separate makes the code base much more maintainable. I also like it because it gets me thinking of the application itself as an object, not just a web page constructed of objects. Do I need to set some configuration settings for this application? Do it in the base application object constructor! What if these settings need to be user configurable? Simply create a file to store the user configurable settings and pass the path to it in as an attribute to the cfoCreateObject call, which we can do via cfoMVC. Want a simple, centralized way of handling custom application errors? No problem, just enclose the cfoMVC call in a cftry block and then cfcatch any custom errors thrown by the controllers. Building my applications in this way, I've found that the model classes I create become much more reusable, because they don't have any specific interface elements built into them. And my application classes can have multiple "faces," if necessary. If you've made it this far, I commend you. I didn't intend on writing a freakin' essay here, but it ended up that way. I hope the concepts make sense. I would be pleasantly surprised if you completely grasp it! I am including the code for cfoMVC and a sample Application.cfm that utilizes it. If you'd like, I can build a simple application that demonstrates the principles. I really have no idea how other cfobjects developers are building their applications. The cfobjects gallery started out with such promise but it seems to have been largely abandoned - and I'm just as guilty of this as anyone. I would be curious to hear what you think of this concept and please tell me if/how/why using the event handling mechanisms may be better suited to what we're attempting. Rocky Palladino _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com |
From: Steven B. <or...@ms...> - 2002-02-28 22:36:25
|
Ok, this is strange. I can send from my MSN email account, but not from my home account. Anyway, I released version 3.0.6.2 which has a few small patches in it for issues that Rocky Palladino found. I've also received some great ideas from a few of you guys over the past week and I can't wait to see some of them in action. - Steve _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. |
From: Steven B. <or...@ms...> - 2002-02-28 22:32:29
|
For some reason I can't send emails to the list. This is only a test. If this had been an actual email message, you would have been instructed to actually read something of value. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com |
From: Steven B. <sbr...@mo...> - 2001-11-29 16:18:54
|
From: Steven B. <or...@be...> - 2001-08-08 00:12:20
|
-----Original Message----- From: Steven Brownlee [mailto:or...@be...] Sent: Tuesday, August 07, 2001 8:08 PM To: 'cfO...@li...' Subject: Test ======================= Steven R. Brownlee CEO/President Orbwave Corporation 412.519.8607 web...@or... ======================= |