diagrams on paper. So, it's not "too late" for anything. The "hours/funny
money vs. consumables" thing is just coming from our use-case type
discussions. They seem vastly different to me. For example:
Hours: must be related to a day & task. need to be totaled by task, project,
and person. may be multiplied by a billing rate to figure cost, but might
not be. Total "cost" can be overwritten to be anything.
Consumables: must be described textually and related to a task. Do not need
to be related to a day, though can be. Cost is fixed and can't be
overridden. Not related to a "billing rate."
The only common things between them is that they're related to a task.
At the UML class I took, they said it's better to not try to force
inheritance where it doesn't really exist, and this seems like it would be
one of those cases.
Thoughts?
-Deanna
----- Original Message -----
From: "Dwayne Cole" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Tuesday, November 18, 2003 5:42 PM
Subject: Re: SOT: OO Design
> From a OO prospective both "funny Money" and Time may be considered
consumables and both would have a method called consume. You would then
model "funny Money" and "real" money as childern of the parent class
consumable. Well no need to transfer you Relational model to an OO one it's
probably to late that. The thing is how can you take advantage of the power
of elegance cfc's you can do that with out going OO. OO cfc's is good for
persistant objects and it sounds like you might be able to create a
persistant object called project. Task and Deliverables and Consumbles can
all have a .cfc or .cfm page that holds all functions related to their
database interaction. It's not a complete OO model but at least it gets you
moving in the right direction and alows you to leverage the component
framework.
>
>
>
> ---------- Original Message ----------------------------------
> From: "Deanna Schneider" <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Date: Tue, 18 Nov 2003 16:03:10 -0600
>
> >It's anything that costs actual money (as opposed to our time, which is
> >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]
