tracked differently and is only "funny money"). For example, it's an outside
contractor's services (because we actually pay them) as well as blank disks
for a CD duplication job. You have to bill consumables to a particular task
which is part of a particular project. Make sense?
This is just one tiny piece of this whole wonky system. Don't even get me
started on how a budget isn't really required, but if there is one,
sometimes you bill out the whole budget even if we haven't provided services
or goods that meet the whole budget, and other times we go over and don't
bill at all. It's a university. What can I say.
-d
----- Original Message -----
From: "Dwayne Cole" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Tuesday, November 18, 2003 3:51 PM
Subject: Re: SOT: OO Design
> What is a consumable?
>
> Dwayne Cole, MS in MIS, MBA
> Florida A&M University
> Certified Advanced ColdFusion Developer
> 850-591-0212
>
> "It can truly be said that nothing happens until there is vision. But it
is equally true that a vision with no underlying sense of purpose, no
calling, is just a good idea - all "sound and fury, signifying nothing."
The Fifth Discipline - Peter Senge
>
>
>
> ---------- Original Message ----------------------------------
> From: Ben Doom <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Date: Tue, 18 Nov 2003 16:09:18 -0500
>
> >> Okay, so if I go with a two object model (grossly simplified, of
course),
> >> then I have a "consumables" object as an attribute of my task object?
Is
> >> that correct? So, if I instantiate a consumables object inside my task
> >> object, I can then call the method "getallConsumables" and get all the
> >> consumables for that task.
> >
> >In this case, does "get" imply that the Task goes and gets them, or that
> >the caller gets them from the Task?
> >
> >> Do I do all my new consumable creation from within my task object, too?
Or,
> >> do I instantiate outside the task object and just pass in a taskid when
I
> >> want to add a consumable (to the database)?
> >
> >Huh? First, let's ignore database storage for the moment.
> >
> >If you are using the Consumable as a portable object -- that is, other
> >things know about Consumables besides just Tasks, then I'd create an
> >object and pass the whole object into the Task. An example: You create
> >an object called a Project which contains Tasks. It has a function
> >which collects all Consumables from the contained Tasks and flags
> >duplicates. It needs to know what Consumables are. Therefore, it makes
> >a lot of sense for the Task to send and recieve Consumable data as
> >Consumable Objects. Does that make sense?
> >
> >Of course, create from data and accept object are not mutually
> >exclusive. You could certainly do either. And, of course, you can have
> >a third option: create from query.
> >
> >Which brings us back to the database. From this point out, I'm assuming
> >a one-Task to many-Consumables relationship, so two tasks never share a
> >Consumable.
> >
> >How you track Consumables as they relate to their Tasks is more of an
> >"ownership" relationship than a relational database one. How they are
> >stored in the DB is irrelevant, in many ways, to the relationship that
> >they have in your object model. Think of it more like XML, where a Task
> >is a container for zero or more Consumables. Does that help?
> >
> >If you have more questions, feel free to contact me off-list or on-list
> >as you please.
> >
> >--Ben
> >
> >
> >
> >
> >
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
