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]
