Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: AW: [riena-dev] Binding of Ridgets: Ridget-Setters obsolete?
Title: Re: AW: [riena-dev] Binding of Ridgets: Ridget-Setters obsolete?
... My precision was more generell and related to Stefans comment ‘...unless we are <1.0...’. I associated we == Riena. Sorry for this confusion.

The issue 234947 looks interesting and could help changes APIs until they become stable.

Alexander

Am 16.06.08 15:06 schrieb "Christian Campo" unter <christian.campo@xxxxxxxxxxxx>:

I was thinking of having that class deprecated until the next milestone is done. Since it is just an empty subclass that is deprecated it does not hurt much.....

IMHO

Not sure what you mean with precision Alex. The rules are pretty clear in Eclipse dont break any API unless you start a new major release number. New APIs are no problem. The problems are removed or changed APIs.

christian

Am 16.06.2008 um 14:46 schrieb Alexander Ziegler:

... I agree Stefan. But with a little bit more precision for each new API is *<1.0* not only as long as Riena is <1.0. I think after Riena 1.0 we will develop new APIs too :-)
 
 Alexander
 
 Am 16.06.08 14:30 schrieb "Stefan Liebig" unter <Stefan.Liebig@xxxxxxxxxxxx>:
 
 
Unless we are < 1.0 we should not deprecate anything. If things change announce it.
 Maybe https://bugs.eclipse.org/bugs/show_bug.cgi?id=234947 is of interest for us.
 
 Stefan
  
 Alexander Ziegler wrote:
 

 .... How long you expect to keep deprecated APIs in the HEAD? Is there some
 plan for Riena / us handle deprecated for Riena releases?
 
 Alexander
 
 
 Am 16.06.08 13:48 schrieb "Christian Campo" unter
 <christian.campo@xxxxxxxxxxxx> <mailto:christian.campo@xxxxxxxxxxxx> :
 
   
  
 

 I think its important that applications can get a quick notice if they
 are using the wrong BindingManager.
 
 If you just replace the new InjectAllAtOnceBindingManager into a
 scenario where you used to use the
 DefaultBindingManager it will probably compile and start to run. The
 thing you notice is that all the controller
 code that manipulates the ridgets cant work because the setter of the
 ridgets is never called. However what
 I dislike about this approach is that you dont get a deprecation
 warning and no compile error.
 
 So I had a short face to face with Carsten and we decided to remote
 DefaultBindingManager, Rename InjectAllAtOnceBindingManager to
 DefaultBindingManager and create an empty deprecated subclass under
 its old name
 
 and furthermore we extend the IRidgetContainer to implement
 configureRidgets. (Basically the original suggestion of Carsten)
 
 What will happen is that clients that used the old
 DefaultBindingManager will not compile (wasnt clear too me at the
 beginning)
 until they implement configureRidgets and in that process change many
 other things.
 
 christian
 Am 16.06.2008 um 13:39 schrieb Alexander Ziegler:
 
     
  
 

 ... Do we need deprecating this API? The API and component is still
 in developing and and no final releases exists in the past.
 
 Alexander
 
 
 
 Am 16.06.08 10:37 schrieb "Carsten Drossel" unter
 <Carsten.Drossel@xxxxxxxxxxxx> <mailto:Carsten.Drossel@xxxxxxxxxxxx> :
 
       
  
 

 Existing code should be no problem when it comes to the
 DefaultBindingManager,
 because it is created as a default by the framework. The
 InjectAllAtOnceBindingManager can be created by a View to override
 the default
 so this class should be kept as deprecated. Why not keep the
 InjectAllAtOnceBindingManager as it is? I think it is somewhat
 inaccurately
 named: it does not inject all ridgets at once but rather calls
 addRidget(..)
 repeatedly.
 
 Carsten
 
 -----Ursprüngliche Nachricht-----
 Von: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-bounces@xxxxxxxxxxx
 ] Im
 Auftrag von Christian Campo
 Gesendet: Montag, 16. Juni 2008 10:26
 An: Riena Developers list
 Betreff: Re: [riena-dev] Binding of Ridgets: Ridget-Setters obsolete?
 
 +1 in general....
 
 however what is the strategy for existing code. Do they get a compile
 or runtime error (not so nice) or
 can we rather deprecate the DefaultBindingManager (maybe display a
 message in the console that you
 are using a deprecated thing) and make the
 InjectAllAtOnceBindingManager the default. Is it necessary
 to call it DefaultBindingManager for that ?
 
 christian
 Am 16.06.2008 um 09:40 schrieb Alexander Ziegler:
 
         
  
 

 +1
 
 Alexander
 
 
 Am 13.06.08 16:26 schrieb "Carsten Drossel" unter
 <Carsten.Drossel@xxxxxxxxxxxx> <mailto:Carsten.Drossel@xxxxxxxxxxxx> :
 
           
  
 
 
 Hi there!
 
 When a View is bound to a ViewController for the first time, a
 Ridget is
 created for each UI widget and injected into the ViewController.
 The
 injection strategy is defined by an implementation of the interface
 IBindingManager. Currently there are 2 implementations:
 
 DefaultBindingManager
 - calls the method addRidget of the IRidgetContainer
 (IViewController)
 for each Ridget
 - calls a setter (it gets via reflection using the name property of
 the
 UI widget) for each Ridget
 
 InjectAllAtOnceBindingManager
 - calls the method addRidget of the IRidgetContainer
 (IViewController)
 for each Ridget
 - after all Ridgets are injected it calls the method
 configureRidgets()
 (of the interface IInjectAllRidgetsAtOnce which the
 IRidgetContainer
 must implement) to notify that all Ridgets were added
 
 The method addRidget was added later and appears to make the
 invokation
 of the setters in the DefaultBindingManager obsolete. The setters
 are a
 pretty good place for the individual initialization of a Ridget.
 But
 their invokation is error-prone since it depends on the matching
 of a
 String and a method name which cannot be checked by the compiler.
 
 I would suggest to keep only the InjectAllAtOnceBindingManager
 and to
 rename it to DefaultBindingManager. The interface
 IInjectAllRidgetsAtOnce should be removed and its method
 configureRidgets() moved to IRidgetContainer.
 
 Are there any objections? Otherwise I would open a bugzilla
 entry...
 
 Greetings,
 Carsten
 
 _______________________________________________
 riena-dev mailing list
 riena-dev@xxxxxxxxxxx
 https://dev.eclipse.org/mailman/listinfo/riena-dev
             
  
 
 
 _______________________________________________
 riena-dev mailing list
 riena-dev@xxxxxxxxxxx
 https://dev.eclipse.org/mailman/listinfo/riena-dev
           
  
 

 _______________________________________________
 riena-dev mailing list
 riena-dev@xxxxxxxxxxx
 https://dev.eclipse.org/mailman/listinfo/riena-dev
 _______________________________________________
 riena-dev mailing list
 riena-dev@xxxxxxxxxxx
 https://dev.eclipse.org/mailman/listinfo/riena-dev
         
  
 

 _______________________________________________
 riena-dev mailing list
 riena-dev@xxxxxxxxxxx
 https://dev.eclipse.org/mailman/listinfo/riena-dev
       
  
 

 _______________________________________________
 riena-dev mailing list
 riena-dev@xxxxxxxxxxx
 https://dev.eclipse.org/mailman/listinfo/riena-dev
     
  
 

 
 _______________________________________________
 riena-dev mailing list
 riena-dev@xxxxxxxxxxx
 https://dev.eclipse.org/mailman/listinfo/riena-dev
   
 

 
 
_______________________________________________
 riena-dev mailing list
 riena-dev@xxxxxxxxxxx
 https://dev.eclipse.org/mailman/listinfo/riena-dev
 

  _______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev


_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev

Back to the top