Thanks, I think it did. And I think I figured out basically what you have suggested, once I thought about my problem a bit more.

 

I should first clarify that this is not a Calendar of events or appointments.  It is a report of how many blood donors where/are scheduled, collected and the daily goal for each day, shown in a monthly format.  That is a big reason, I wanted my data object to be created once, used by many.  There is going to be a fair amount of data crunching to come up with these various figures.  They will be coming from different systems and need to be calculated and integrated together.  This is not something I want, or should need to be, done repeatedly or individually as users view and move through the calendar.

 

What I have done is created my DataCFC in the application scope, which at the moment is just creating dummy data for a wire frame of the User Interface.  I then pass a reference to the application scope into the init function of my DisplayCFC as an argument.

 

I’m not sure how OOP vs structured this is, but I don’t think it’s too bad for a first attempt.


--------------
Ian Skinner
Web Programmer
BloodSource
www.BloodSource.org
Sacramento, CA

 

"C code. C code run. Run code run. Please!"
- Cynthia Dunning

-----Original Message-----
From: Gary Menzel [mailto:[EMAIL PROTECTED]
Sent: Monday, June 27, 2005 2:39 PM
To: [email protected]
Subject: Re: [CFCDev] Where to put the data?

 

Depending on how your Calendar object is built (I would be assuming it at least remembers the month from request to request so it knows where the user is up to) then I would suggest you store the DATA in the application scope, create an instance of the Calendar for each user (either in Session scope or in a Session-keyed Application structure), then initialise the Calendar object with the DATA.

 

The other thing you might also want to consider is how the Calendar can be kept up to date (as I also assume that the external system that is populating the calendar may do so between user requests).  For this (hopeully) your calendar entries will have a "created" or "modified" dates.  Just remember the last one in your Application scoped calendar and each time any user accesses the calendar, see if there is anything more recent than that date (either created or modified) and then appropriate update or add to your Application scoped calendar.

 

Our CRM system has multiple calendars.  One for each user, one for each office, one for the enterprise - and any number of other "group-based" calendars.  Through permissioning, any user can see any set of calendars relevant to their authorisation/location/position, etc.  The added value in our system is that the calendars are also maintained by the same system (which means an update to one calendar can easily reflect for all users).
 

BIG NOTE HERE......

 

Virtually all of the obejcts we use work this way (data is stored either in Application or Session scope and each instnace of a component is initialised with a reference to the actual data.  We also use singletons (one-and-one-only instance of a class) to avoid having to create the objects over and over for each request.  These are all managed through a "factory" type class that maintains the instances and reuses what it has already created.


Lists are never a good place to provide a big tutorial on OOP, Patterns, Caching, etc. - but I hope this has helped some.

 

Regards,
Gary

 

 

 

On 6/28/05, Ian Skinner <[EMAIL PROTECTED]> wrote:

I'm still trying to figure out this OOP/CFC/Layered development concept.  I think I have a nice start.  I have a page (view?) that takes an array representing a calendar month of data plus tails.  It displays this calendar with controls to move up and down the year.

The calendar array and various other display-required information is built with a CFC.  I think this is working well, the CFC has methods to figure out the first day to display which is the Monday before the first day of the given month and the last day which is the Sunday after the last day of the month. As well as other display parameters.

I am planning on building a separate CFC to handle the data retrieval and manipulation from the database.  My thoughts is that I would like this data to be cached as it will be large and could take several seconds to retrieve and organize, easily 45 to 60 or more.  I also want all the viewers to share one data instance.  I don't need each one to have their own copy of the hefty piece of data.  This application does not update this data; it is a display/report only.  Information is entered into the system in other locations outside of this web application.

So the question is where do I put this CFC and how do I access it so that each user shares one instance of the data CFC?  Do I just create the data object in application scope and have the display cfc access it with #application.dataCFC.method()# calls.  Or would it be better to create a local pointer to the data in the display cfc: <cfcomponent...><cfset variables.dataCFC = application.dataCFC> .... <cfset something = variables.dataCFC.someMethod()>

Or is there some other technique that I am complete missing?

Thanks Ian

--------------
Ian Skinner
Web Programmer
BloodSource
www.BloodSource.org
Sacramento, CA

"C code. C code run. Run code run. Please!"
- Cynthia Dunning

Confidentiality Notice:  This message including any
attachments is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the
intended recipient, please contact the sender and
delete any copies of this message.




----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting ( www.cfxhosting.com).

CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm

An archive of the CFCDev list is available at www.mail-archive.com/[email protected]


----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm

An archive of the CFCDev list is available at www.mail-archive.com/[email protected]

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm

An archive of the CFCDev list is available at www.mail-archive.com/[email protected]

Reply via email to