QCMagritte: QCObject vs. QCParentObject

> On 27 Apr 2017, at 22:19, Udo Schneider <[hidden email]> wrote:
>
> All,
>
> I can't really understand the difference between QCObject and QCParentObject and when to use which.
>
> From reading the source I can guess that a QCParentObject allows you to access the ApplicationModel using #model (through it's parent ivar). But is this all?
>
> CU,
>
> Udo
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.list.inf.unibe.ch/listinfo/smallwiki

> Hi Udo,
>
> Yes, the basic idea is that a QCParentObject is an object that is owned by a parent. For instance if you have in your domain model a todo list that belongs to a project, the todo list items should be derived from QCParentObject. This also allows to delegate certain things back to the parent, like accessing the model, that is the root the object belongs to. Another example is for properties like “canEdit” where one can decide to have user rights only for the parent object (the project) and not for the child objects (the todo items).
>
> For practical purposes I usually create a domain model that is an artificial owner: the model that is the owner of all objects, thus resulting in all objects, except the modeli, to be a subtype of QCParentObject. But one could easily make a different implementation to link the objects back to the model (i.e. creating a subclass that returns for the model always the singleton of a certain class)
>
> I hope this rationale helps.
>
> Regards,
> Diego
>
>> On 27 Apr 2017, at 22:19, Udo Schneider <[hidden email]> wrote:
>>
>> All,
>>
>> I can't really understand the difference between QCObject and QCParentObject and when to use which.
>>
>> From reading the source I can guess that a QCParentObject allows you to access the ApplicationModel using #model (through it's parent ivar). But is this all?
>>
>> CU,
>>
>> Udo
>>
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.list.inf.unibe.ch/listinfo/smallwiki
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.list.inf.unibe.ch/listinfo/smallwiki

> On 28 Apr 2017, at 14:02, Esteban A. Maringolo <[hidden email]> wrote:
>
> Maybe the naming is misleading. I'd expect QCParentObject to be the
> one that contains owned object (QCChildObject/QCOwnedObject).
>
> I have similar classes in my apps, named TsModel (your QCObject) and
> TsModelPart (your QCParentObject). ModelPart understands #owner and
> have certain behavior delegating back to Model.
>
> Regards!
>
> Esteban A. Maringolo
>
>
> 2017-04-28 6:45 GMT-03:00 Diego Lont <[hidden email]>:
>> Hi Udo,
>>
>> Yes, the basic idea is that a QCParentObject is an object that is owned by a parent. For instance if you have in your domain model a todo list that belongs to a project, the todo list items should be derived from QCParentObject. This also allows to delegate certain things back to the parent, like accessing the model, that is the root the object belongs to. Another example is for properties like “canEdit” where one can decide to have user rights only for the parent object (the project) and not for the child objects (the todo items).
>>
>> For practical purposes I usually create a domain model that is an artificial owner: the model that is the owner of all objects, thus resulting in all objects, except the modeli, to be a subtype of QCParentObject. But one could easily make a different implementation to link the objects back to the model (i.e. creating a subclass that returns for the model always the singleton of a certain class)
>>
>> I hope this rationale helps.
>>
>> Regards,
>> Diego
>>
>>> On 27 Apr 2017, at 22:19, Udo Schneider <[hidden email]> wrote:
>>>
>>> All,
>>>
>>> I can't really understand the difference between QCObject and QCParentObject and when to use which.
>>>
>>> From reading the source I can guess that a QCParentObject allows you to access the ApplicationModel using #model (through it's parent ivar). But is this all?
>>>
>>> CU,
>>>
>>> Udo
>>>
>>> _______________________________________________
>>> Magritte, Pier and Related Tools ...
>>> https://www.list.inf.unibe.ch/listinfo/smallwiki
>>
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.list.inf.unibe.ch/listinfo/smallwiki
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.list.inf.unibe.ch/listinfo/smallwiki

> 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" <[hidden email]
> <mailto:[hidden email]>> 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
>

> Op 1 mei 2017 om 11:12 heeft Diego Lont <[hidden email]> het volgende geschreven:
>
>
>> On 01 May 2017, at 08:57, Udo Schneider <[hidden email]> 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 deleted.
>>> Regards,
>
> So the suggestion is QCModelPart instead of QCParentObject.
>
> Regards,
> Diego
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.list.inf.unibe.ch/listinfo/smallwiki