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
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]
