Op 1 mei 2017 om 11:12 heeft Diego Lont <diego.lont(a)delware.nl>
het volgende geschreven:
> On 01 May 2017, at 08:57, Udo Schneider <udo.schneider(a)homeaddress.de> wrote:
> 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.
Magritte, Pier and Related Tools ...