30 Apr
2017
30 Apr
'17
5:35 p.m.
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>
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
1 May
1 May
8:57 a.m.
New subject: QCMagritte: QCObject vs. QCParentObject
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
11:12 a.m.
New subject: QCMagritte: QCObject vs. QCParentObject
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
deleted.
> Regards,
So the suggestion is QCModelPart instead of QCParentObject.
Regards,
Diego
12:38 p.m.
New subject: QCMagritte: QCObject vs. QCParentObject
Sounds good to me
Stephan
Verstuurd vanaf mijn iPhone
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
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
2821
days inactive
2822
days old
3 comments
4 participants
participants (4)
-
Diego Lont -
Esteban A. Maringolo -
Stephan Eggermont -
Udo Schneider