replacing duplicate object on client

[VisionSet]

Client Server - client is MVC server holds objects of same type as are
contained in the M of clients MVC

For the sake of this thread lets assume this is a reasonable design for my
system.

Object arrives at client and is equivalent but obviously more upto date than
one already held by client.
Client wants to replace the old one with the new one.

Does it:

a/ copy all the observers out of the old one into the new one and replace
the object
b/ copy the data out of the new one into the old one
c/ replace the object and let some other observer mechanism sort refresh
whatever
d/ something else I haven't considered.

TIA

 

[Danno]

How do we know what it does? You programmed it. Unless this is some
sort of brand-named server you forgot to mention?

Let us know.

 

[Oliver Wong]

Client Server - client is MVC server holds objects of same type as are
contained in the M of clients MVC

For the sake of this thread lets assume this is a reasonable design for my
system.

Object arrives at client and is equivalent but obviously more upto date
than
one already held by client.
Client wants to replace the old one with the new one.

Does it:

a/ copy all the observers out of the old one into the new one and replace
the object
b/ copy the data out of the new one into the old one
c/ replace the object and let some other observer mechanism sort refresh
whatever
d/ something else I haven't considered.

I would go with 'b'. For your client-side model object, I'd have a
method "updateFrom(Model m)" or something like that, so all you have to do
is pass in the new Model object into the old one, then discard the new Model
object. The updateFrom() method should take care of only sending
notifications for the fields that actually did change.

- Oliver

 

[VisionSet]

How do we know what it does?

http://en.wikipedia.org/wiki/Abstraction

 

[Chris Uppal]

a/ copy all the observers out of the old one into the new one and replace
the object
b/ copy the data out of the new one into the old one
c/ replace the object and let some other observer mechanism sort refresh
whatever
d/ something else I haven't considered.

Probably (c) and/or (d). You already have code that connects your client code
to a model (or how come it is already observing the old model). Run that code
again with the new model. If it takes more than one line of new code then
you've done something wrong ;-)

-- chris

 

[VisionSet]

Probably (c) and/or (d). You already have code that connects your client code
to a model (or how come it is already observing the old model). Run that code
again with the new model. If it takes more than one line of new code then
you've done something wrong ;-)

I guess that is the best general approach, just that the 1st time the object
is installed on the client an observer mechanism causes new gui components
to be created to render it. Subsequent updates shouldn't create new GUI
elements or even have any gui component destruction/creation effect, just
trigger paint updates. Just need to think a bit harder about this one. I
guess it will be a case of firing an insert or an update sort of event and
letting the gui figure it out.

 

[Thomas Hawtin]

a/ copy all the observers out of the old one into the new one and replace
the object
b/ copy the data out of the new one into the old one
c/ replace the object and let some other observer mechanism sort refresh
whatever
d/ something else I haven't considered.

You probably want to keep the object identity intact if there are users
of it. So I would tend towards b.

Replication is quite difficult. If you can guarantee good enough quality
of communication, thing become easier if you can make sure that all
modifications are done either in one place or with distributed locks
enforced. A handy strategy is to replay the actions that caused the
mutations, rather than trying to compare data.

Another useful (and indeed have good performance from the client view of
things) approach is to forget about small scale listeners and just sync
the whole lot. It can mean much less code without all those listeners.
It has good performance because there isn't the high set up time and in
the case of lots changing there aren't all those events, just a single
process. It's much slower on smaller updates, but who cares about
performance of what will be fast anyway.

Tom Hawtin

 

[Danno]

So what does this have to do with your post?

 

[Oliver Wong]

So what does this have to do with your post?

I think VisionSet is saying you don't need to know what his program does
to answer the specific design question of how to synchronize two different
model objects.

- Oliver

 

[Danno]

An attempt at good grammar goes a long way I guess.
Sounded like he already had a server, and wanted to know how it worked.

 

[Luc The Perverse]

An attempt at good grammar goes a long way I guess.
Sounded like he already had a server, and wanted to know how it worked.

You should quote who you are replying to.

That goes a long way too

 

[Danno]

Yep. FYI, I was referring to the original post.

<copy>
Client Server - client is MVC server holds objects of same type as are
contained in the M of clients MVC

For the sake of this thread lets assume this is a reasonable design for
my
system.

Object arrives at client and is equivalent but obviously more upto date
than
one already held by client.
Client wants to replace the old one with the new one.

Does it:

a/ copy all the observers out of the old one into the new one and
replace
the object
b/ copy the data out of the new one into the old one
c/ replace the object and let some other observer mechanism sort
refresh
whatever
d/ something else I haven't considered.

TIA