Menu
▾
▴
Re: [Rails-devel] Rails2.0: Observer and Formatter
|
From: Erik V. <eri...@xs...> - 2012-07-12 09:36:47
|
Stefan,
OK, I understand your reasoning.
>From your proposals, Presenter sounds best to me, but I leave it entirely to
you.
Erik.
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Thursday, July 12, 2012 10:09 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Rails2.0: Observer and Formatter
>
> Erik:
> as in the previous cases I prefer generic (short) names for the basic
> Interfaces and Abstract Classes.
>
> Main reason is that usually the specialization implies adding another word
to
> that, e.g. State and BooleanState.
>
> However there is no major reason to use ObservableFormatter and then
> replace Observable by the specializaton e.g. BooleanFormatter.
> Only disadvantage is more typing:
>
> Example:
> BooleanFormatter extends ObservableFormatter<BooleanState>
>
> instead of
>
> BooleanFormatter extends Formatter<BooleanState>
>
> As there are no other Formatters exist in Rails and I have no intention to
add
> one, I would prefer to stick with the shorter name.
>
> I used the label "View" for implementations of an Observer.
>
> Using View (as view in a MVC context) would be misleading for the
> Formatter as the Formatter acts more like the upper level of the Model.
>
> One could consider them as Adapter or Presenter in a MVA/MVP framework
> (check Wikipedia for short explanations). All three names Formatter,
Adapter
> and Presenter are ok with me, so I would follow your recommendation.
>
> Stefan
>
>
> On 07/12/2012 09:45 AM, Erik Vos wrote:
> > Stefan,
> >
> > This looks absolutely fine to me.
> >
> > Just one remark: 'Formatter' is a rather generic name, but it seems to
> > me that its usage is restricted to wrapping Observables.
> > If that is true, shouldn't we try to find a more descriptive name?
> > ObservableFormatter is a bit longish, perhaps just Viewer (or
> > ObservableViewer) would do? (as you use xxxViewer in some examples).
> >
> > Erik.
> >
> >> -----Original Message-----
> >> From: Stefan Frey [mailto:ste...@we...]
> >> Sent: Thursday, July 12, 2012 12:06 AM
> >> To: Development list for Rails: an 18xx game
> >> Subject: [Rails-devel] Rails2.0: Observer and Formatter
> >>
> >> After the recent discussion I have finalized the Observer Interface.
> >> Related to this I present the Formatter (Abstract) Class that allows
> >> for different type of output from the identical Observable object.
> >>
> >> As usual comments are very welcome, as things can still be changed
> easily.
> >>
> >> Stefan
> >>
> >>
> >> *** Observer
> >> I took two major decisions that (on a first glance) limits the
> > flexibility,
> >> however simplifies the structure.
> >>
> >> 1. Each observer is only allowed to observe one Observable (reminder:
> >> this is either a State or a Model). However an observable can have
> >> many observers (so it is a n:1 relation).
> >>
> >> 2. The data transferred is always a String.
> >>
> >> However this makes the Observer interface straightforward. There is
only
> >> ...
> >>
> >> (public) void update(String text);
> >>
> >> ... one method with one argument containing the updated data from the
> >> observed Observable.
> >>
> >> This is called only once per ChangeSet activity (committing a new,
> >> undo, redo), and only if the Observable is changed by the ChangeSet(s)
> executed.
> >>
> >> * Usage:
> >>
> >> Adding an observer to an observable uses the following method:
> >> observable.addObserver(observer);
> >>
> >> It is possible to remove it:
> >> observable.removeObserver(observer);
> >>
> >> or to get a set with all attached observers
> >> observable.getObservers()
> >>
> >> * Remark:
> >>
> >> The two assumptions above are not as restrictive as it might appear:
> >>
> >> 1. It is easy to build a Class that contains several Observers as
> >> inner
> > classes
> >> that observe multiple Observable. (Similar to Listeners in Swing).
> >>
> >> 2. It is possible that the String could contain XML, Json or another
> > serialized
> >> representation of a more complex data structure.
> >> As long as no true client/server separation is done, direct callbacks
> >> are possible (and later one could still add some RMI technology).
> >>
> >> *** Formatter
> >>
> >> A class that extends the abstract Formatter class can act as a
> >> wrapper
> > around
> >> an Observable to change the output text specific for different
observers.
> >> Usually the text delivered to the update method of the observers is
> >> the
> > one
> >> defined by the observerText() method of the Observable.
> >> A Formatter now allows to
> >>
> >> * Example: Share Portfolio
> >>
> >> Assume that you have a Model that represents the SharePortfolio of a
> > Player
> >> (labelled CertificateModel).
> >> Now there could be two Observers in the GUI for that SharePortfolio:
> >> One could display the total percentage of the shares for one company
> (e.g.
> >> 40%, labelled percentViewer), whereas the other (called
> >> toolTipViewer) displays the exact compositon (20%P+1*10%+2*5%).
> >>
> >> To achieve this one creates a Formatter<CertificateModel> that take
> >> the CertificateModel as one argument to its constructor and the
> >> required type
> > of
> >> output as the other argument (e.g. verbose=true/false).
> >>
> >> Then the Observer would not be added to the Observable directly, but
> >> to
> > the
> >> Formatter objects, that wrap the Observable inside:
> >>
> >> detailedCertificates.addObserver(toolTipViewer)
> >> percentageCertificates.addObserver(percentViewer)
> >>
> >> * Another Example: BooleanState
> >>
> >> As Unit Test I have defined a simple Formatter for a BooleanState
> >> that instead the default text ("true" versus "false") simply delivers
> >> an
> > alternative
> >> text representation ("yes" versus "no")
> >>
> >> * Implementation / Usage
> >>
> >> Again it is pretty simple:
> >> There is the abstract method observerText which has to be
> >> overwritten,
> > e.g.
> >> in the case of BooleanState above:
> >>
> >> @Override
> >> public String observerText() {
> >> if (state.value()) {
> >> return "yes";
> >> } else {
> >> return "no";
> >> }
> >> }
> >>
> >> *** Current state of implementation
> >> Both Observer and Formatter are fully implemented and have unit tests
> >> attached.
> >>
> >>
> >>
> > ----------------------------------------------------------------------
> > ------
> > --
> >> Live Security Virtual Conference
> >> Exclusive live event will cover all the ways today's security and
> >> threat landscape has changed and how IT managers can respond.
> >> Discussions will include endpoint security, mobile security and the
> >> latest in malware threats.
> >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > ----------------------------------------------------------------------
> > --------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> > Discussions will include endpoint security, mobile security and the
> > latest in malware threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
>
>
>
>
----------------------------------------------------------------------------
--
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware
threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
|
