1 May
2017
1 May
'17
8:57 a.m.
After reading the thread I did come up with the following strategy ...
not sure if it's the intended one though:
1) Every Model shown in the app (top navigation?) is a subclass of
QCParentObject. Even it it's "just" to be able to access the AppModel
easier.
2) If the Model's life is directly dependent on another object (see your
Invoice vs. InvoiceItem comment) then I set parent to this "owning"
object. Otherwise to AppModel (if not already set).
Is this a sound strategy or completely BS?
CU,
Udo
On 30/04/2017 17:35, Esteban A. Maringolo wrote:
This is why I call it "ModelPart", because
the parent/child relation is
alike but not always so. It's "part" of a whole (its owner), but not
necessarily a child.
Also the relation is of aggregation, the lifetime of the part is, as
much, as long as the lifetime of its owner.
I.e. an InvoiceIem is part of an Invoice but won't exist if the invoice
is deleted.
Regards,
El abr. 30, 2017 12:10 PM, "Stephan Eggermont" <stephan(a)stack.nl
<mailto:stephan@stack.nl>> escribió:
On 29/04/17 14:40, Diego Lont wrote:
Good point. When no one objects I will rename QCParentObject
into QCChildObject.
Hmm. Aren't they all children? Isn't the more important aspect
ownership? Let's iterate over the name some more.
Stephan
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.list.inf.unibe.ch/listinfo/smallwiki
<https://www.list.inf.unibe.ch/listinfo/smallwiki>
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.list.inf.unibe.ch/listinfo/smallwiki