> Sounds like you're on the right track. > > Regarding your sample approach below, I'd have to say that this depends on > how you want to code it, and what the requirements of your application > are. > You could have one event object that contains an array/collection of time > slots and venues, or you can have an array/collection that has a single > event which in turn has a single timeslot and venue.
That's an idea too... I like it. I'm still getting used to thinking in collections of references... But implementing the actual objects as simply as possible and abstracting the complexity to a series of specialized collection is definitely appealing. One aspect of this is that we're constantly trying to come up with new ways to group the data making it easier for people to find what they're looking for (searching by attributes like "outdoors" or "family friendly", creating custom lists, etc). > When I think about an event, I don't think of it having multiple times - I > think about each time being a separate event, and the schedule is a > collection of individual events. However, that's me. This sort of thing In this case "performance" may be a better term - but our "events" may be performances, exhibits, workshops, etc - but it sometimes helps to think of them as performances. > When I made reference to "query your data", the actual location of the > data > doesn't matter - if it's in memory, then your functions/methods will be > written to use the memory, if it's in a database, the functions/methods > will This is actually a goal (a personal one) for this - I want to be able, later, to add persistence data storage types easily (different databases, flat file, etc). Eventually I would like to spin this system off as a general purpose large-scale event planning tool so I'd like to lay the groundwork early. > Are you developing this in CFMX? If so, you can't do a FULL > implementation > of OO principles yet (it'd be nice if MX natively supported raising events > between objects), but you can get real close now. If you are developing Yup - CFMX. We're still on CF 5, actually, but now that our host is installing 6.1 we're moving up. This will end being a hybrid at first no matter how I end up - basically an OO-ish implementation in a procedural wrapper of sorts (I don't have time to do the entire site over yet). But I want to get it as close as possible so that I can learn this stuff if nothing else. > Once you get thinking in OO terms (and this IS a shift in thinking from > procedural languages), life will get easier, and you will have other > options > available to you. Like converting your CFMX objects into web services. > (yes, I know you can do this sort of thing with procedural languages too, > but I find it's much easier to understand if you understand OO > principles). That's something I may do soon... this is a pretty big event around here. One "nice to have" desire is to provide consumable feeds to the local media outlets. I had been doing this in a really primitive manner, but web services make infinitely more sense. > So, the bottom line is to look at your application in an OO manner, and > decide which object model makes the most sense for you. I can't tell you > this, but hopefully I've helped you understand things enough to be able to > make the choice. Definitely. Lots to think about. Thanks again for the time, Jim Davis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm?link=i:4:137638 Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
