[deepamehta-users] Address Model in DM Webclient

[Juergen Neumann]

Hi Jörg,

I understand the general apsect of the specific issue. In my case I want
to create new persons via the REST API. I have implemented a check if an
address topic alread exists. If so, I want to reassign this very address
to the newly created person. 

So my question is, if I change the assoc type from composition def to
aggregation def for the entire address, will it break anyting (in the
webclient) or can I just try it, to see how it goes ...

Thx,

JuergeN 

Am Samstag, den 21.02.2015, 16:48 +0100 schrieb Jörg Richter:
> Hi JuergeN,
> 
> we could define that association as Aggregation Definition but this would not make the Webclient automatically share Address objects between several parents.
> 
> Currently the Webclient has no notion of weather a *composite* object as edited in the detail panel represents the same thing (semantic-wise) as any object already existing in the DB. How could such a logic be implemented (in a performant way)? How could an universal GUI be designed? To me these are hard questions and the 2nd one seems not even solvable in the scope of the DM Webclient.
> 
> When I'm editing e.g. a person in the Webclient's detail panel it can't differentiate between these 2 cases:
> 	- I want edit a shared address and thus affect all involved persons.
> 	- I want assign just the person being edited a new address.
> From my point of view these are 2 different (domain-specific) use cases that can not be handled at the same time by the (domain-unspecific) Webclient which have no sense of "use cases" but manipulates the data directly.
> 
> Sharing e.g. an address object between several parents and editing them with the Webclient comes at the risk of unwanted semantic side-effects. This is a long lasting basic problem discussed in https://trac.deepamehta.de/ticket/337
> 
> That's why the Contacts/Address model is as it is.
> 
> Cheers,
> Jörg
> 
> 
> On Feb 21, 2015, at 15:09, Juergen Neumann wrote:
> 
> > Dear Jörg,
> > 
> > I was just wondering why on type level the association between
> > Address_Entry and Address is modelled as a composition definition? An
> > address is very well described with country, city, code and street. So
> > if all these match, it is probably the very same address (in real life).
> > 
> > Are there any specfic reasons, why you chose to do it this way?
> > Otherwise I would suggest to change it into an aggregation definition.
> > 
> > Thx,
> > 
> > JuergeN
> > 
> > -- 
> > users mailing list
> > users at lists.deepamehta.de
> > http://lists.deepamehta.de/mailman/listinfo/users-lists.deepamehta.de
>