On 01 May 2017, at 08:57, Udo Schneider
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?
That sounds like a sound strategy.
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
So the suggestion is QCModelPart instead of QCParentObject.