Re: [Rails-devel] Rails2.0: States and Models as Observables

[Stefan F. <ste...@we...>]

Erik,
thanks for your comments. Answers see below.
Stefan

On 07/09/2012 12:11 AM, Erik Vos wrote:
>
> Wouldn't it be better to use different class/interface names, to avoid
> confusion with the standard Java names Observable and Observer?
> Not that I have any good proposals.
> Publisher/Subscriber aren't wrong but sound a bit pompously here.
> Perhaps ObservableItem and ObservingItem or ObservingElement?

No I do not think that there is any confusion: That is exactly what java 
namespaces are for.

Did you know that there are 4 other classes named State in packages 
delivered with the java jdk? What you suggest to not use "State" for 
that reason?

>
>> Currently an Observer only provides an update(Observable obs, String
>> text) method. The latter argument provides a text update for the standard
>> cases.
>
> Did you consider the cases where currently a ViewObject is passed?  This can
> (in theory) contain anything that can be serialized (currently to a String
> only).
>

I am aware of those cases, but as I stated, I have not fully decided how 
to replace them. My preference would be to still have only Strings 
passed, as this would keep the interface between Observer and 
Observables easy.

In the longer run, the Strings can be complex XML or JSON expression, so 
it is not a real restriction. As a dirty workaround until a true 
client/server separation one could even use direct callbacks from the 
observer to the observable to transmit complex data.

>> I am wondering if I should add a proxy approach, such that the Observer
> can
>> specify a function which has to be called that can be specific for each
>> Observable observed. Or if I should be more restrictive and allow each
>> Observer to observe ONLY one observable, thus dropping the need to
>> specify the Observable in the interface method.
>
> Not sure what you mean here.
>

For the latter part of my paragraph above see my answer to Brett.
A proxy or delegate approach would add a Delegate object that would 
subscribe itself to the observable (and would be called on update()). 
However at the creation of the delegate the true observer could specify 
that it would prefer to have a different method called.

The use case is the following:
Assume you have an Observer that observes two Observables called A and 
B: Then instead of having one method update(Observable obs) and using if 
statements inside, it is possible to have two methods update_from_A() 
and update_from_B() inside the observer.

But as I prefer to rule that out, there is no need for such an approach.