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
|