On Wed, Apr 15, 2009 at 8:50 PM, Jeff Squyres <jsquy...@cisco.com> wrote:
> On Apr 15, 2009, at 1:45 PM, Mike Dubman wrote: > > yep. correct. We can define only static attributes (which we know for sure >> should present in every object of given type and leave phase specific >> attributes to stay dynamic) >> >> Hmm. I would think that even in each phase, we have a bunch of fields >> that we *know* we want to have, right? >> >> correct, in gds terms they call it static attributes. >> > > I was more nit-picking your statement that we would only have a field > fields that would be available for every phase, and then use dynamic fields > for all phase-specific data. While GDS *can* handle that, wouldn't it be > better to have a model for each phase (similar to your mockup) that expects > a specific set of data for each phase? Extra data on top of that would be a > bonus, but wouldn't be necessary. More specifically: we *know* what data > should be available in each phase, so why not tell GDS about it in the model > (rather than using dynamic fields that we know will always be there)? > > Perhaps we're just getting confused by language and I should wait for your > next mock-up to see what you guys do... :-) > completely agree, the model for every phase object should contain mostly static fields, based on current mtt phases info. Also, we will have flexibility to expand phase objects without changing the model.
