cfobjects-developers — Mailing list for core cfObject developers

further steps in tutorial

[Soleeroo <sol...@ya...>]

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

missing files in downloaded package

[Soleeroo <sol...@ya...>]

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

[cfobjects-developers] New initiatives

[Steve B. <Ste...@ef...>]

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

[cfobjects-developers] cfobjects-3.1.0

[Vladimir M. <MA...@WE...>]

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

[cfobjects-developers] cfObjects 3.1 bug

[Ben B. <be...@el...>]

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

RE: [cfobjects-developers] Super Object vs. instance properties

[Steven B. <or...@ms...>]

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 world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

RE: [cfobjects-developers] Super Object vs. instance properties

[Steven B. <or...@ms...>]

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] Super Object vs. instance properties

[Steven B. <or...@ms...>]

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] RE: cfoMVC

[Steven B. <or...@ms...>]

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 &copy; 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

[cfobjects-developers] Strange...

[Steven B. <or...@ms...>]

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.

[cfobjects-developers] Testing, testing 1..2..3...

[Steven B. <or...@ms...>]

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

[Cfobjects-developers] cfObjects 3.0 Released Today

[Steven B. <sbr...@mo...>]

[Cfobjects-developers] FW: Test

[Steven B. <or...@be...>]

-----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...
=======================