Quantcast

QCMagritte: QCObject vs. QCParentObject

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

QCMagritte: QCObject vs. QCParentObject

Udo Schneider
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: QCMagritte: QCObject vs. QCParentObject

DiegoLont
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: QCMagritte: QCObject vs. QCParentObject

Esteban A. Maringolo
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: QCMagritte: QCObject vs. QCParentObject

DiegoLont
Hi Esteban,

Good point. When no one objects I will rename QCParentObject into QCChildObject.

Regards,

> 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

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.list.inf.unibe.ch/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: QCMagritte: QCObject vs. QCParentObject

Stephan Eggermont
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: QCMagritte: QCObject vs. QCParentObject

Esteban A. Maringolo
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]> 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


_______________________________________________
Magritte, Pier and Related Tools ...
https://www.list.inf.unibe.ch/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: QCMagritte: QCObject vs. QCParentObject

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?

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" <[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
>


_______________________________________________
Magritte, Pier and Related Tools ...
https://www.list.inf.unibe.ch/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: QCMagritte: QCObject vs. QCParentObject

DiegoLont

> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: QCMagritte: QCObject vs. QCParentObject

Stephan Eggermont
Sounds good to me

Stephan

Verstuurd vanaf mijn iPhone

> 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

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.list.inf.unibe.ch/listinfo/smallwiki
Loading...