http://weblogs.java.net/blog/timboudreau/archive/2009/07/api_design_vs_a_1.html I guess he doesn't get why we did the rename. This reminds me that we *really* should improve our release docs before we finalize 1.4!!! Martijn -- -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
A good overall read, but he also seemed to miss the reason we have getModel**Object**. He doesn't think that's necessary, but misses that there is also getModel (without object) and the word does clarify the difference. Anyway, a good read on overall API design, though. I'd recommend it to others with the caveat that I also disagree with his last part about the rename. -- Jeremy Thomerson http://www.wickettraining.com On Mon, Jul 6, 2009 at 8:22 AM, Martijn Dashorst<martijn.dashorst@...> wrote: > http://weblogs.java.net/blog/timboudreau/archive/2009/07/api_design_vs_a_1.html > > I guess he doesn't get why we did the rename. This reminds me that we > *really* should improve our release docs before we finalize 1.4!!! > > Martijn > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > Apache Wicket 1.3.5 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. >
I understand the getModelObject() thing, but I not about the getDefaultModel(). Why is that? I've found an e-mail ( http://mail-archives.apache.org/mod_mbox/wicket-dev/200806.mbox/%3C23eb48360806190903y27f3baeaua2db57e39249743d-JsoAwUIsXosN+BqQ9rBEUg <at> public.gmane.org%3E) that states that it may be removed in 1.5. Why rename getModel to getDefaultModel just to take it out later? Not a critic, just trying to understand. Tetsuo On Mon, Jul 6, 2009 at 11:18 AM, Jeremy Thomerson <jeremy@... > wrote: > A good overall read, but he also seemed to miss the reason we have > getModel**Object**. He doesn't think that's necessary, but misses > that there is also getModel (without object) and the word does clarify > the difference. > > Anyway, a good read on overall API design, though. I'd recommend it > to others with the caveat that I also disagree with his last part > about the rename. > > -- > Jeremy Thomerson > http://www.wickettraining.com > >(Continue reading)
I've just read the explanation in a Tim's blog post comment. Oh, well, generics definitely isn't easy to grasp... I myself have observed that my (wicket) code is so much readable without most generics declarations. Even when using components that do have models (Textfield, for example) I didn't gain anything for adding the angle brackets, since the models in general use reflection (PropertyModel, CompoundPropertyModel, etc.), and don't make any use of the build-time validation at all. sigh... Tetsuo On Mon, Jul 6, 2009 at 3:35 PM, tetsuo <ronald.tetsuo@...> wrote: > I understand the getModelObject() thing, but I not about the > getDefaultModel(). Why is that? > > I've found an e-mail ( > http://mail-archives.apache.org/mod_mbox/wicket-dev/200806.mbox/%3C23eb48360806190903y27f3baeaua2db57e39249743d-JsoAwUIsXosN+BqQ9rBEUg <at> public.gmane.org%3E) > that states that it may be removed in 1.5. > > Why rename getModel to getDefaultModel just to take it out later? > > Not a critic, just trying to understand. > > Tetsuo > >(Continue reading)
What if Component was not generified, and had an 'Object getModel()' method instead of 'Object getDefaultModel()', and the components that do benefit from generics, simply override the method to return 'T' (then the component class would have a <T> type parameter)? The compiler accepts this just fine. Tetsuo On Mon, Jul 6, 2009 at 3:48 PM, tetsuo <ronald.tetsuo@...> wrote: > I've just read the explanation in a Tim's blog post comment. Oh, well, > generics definitely isn't easy to grasp... > > I myself have observed that my (wicket) code is so much readable without > most generics declarations. Even when using components that do have models > (Textfield, for example) I didn't gain anything for adding the angle > brackets, since the models in general use reflection (PropertyModel, > CompoundPropertyModel, etc.), and don't make any use of the build-time > validation at all. > > sigh... > > Tetsuo > > > > > On Mon, Jul 6, 2009 at 3:35 PM, tetsuo <ronald.tetsuo@...> wrote: > >> I understand the getModelObject() thing, but I not about the >> getDefaultModel(). Why is that?(Continue reading)
'IModel<?> getModel()' instead of 'Object getModel()', and 'IModel<T> getModel()' instead of 'T getModel()', sorry. And sorry for flooding the mailing list, this is the last one, I promise :) On Mon, Jul 6, 2009 at 3:54 PM, tetsuo <ronald.tetsuo@...> wrote: > What if Component was not generified, and had an 'Object getModel()' method > instead of 'Object getDefaultModel()', and the components that do benefit > from generics, simply override the method to return 'T' (then the component > class would have a <T> type parameter)? The compiler accepts this just fine. > > Tetsuo > > > > > On Mon, Jul 6, 2009 at 3:48 PM, tetsuo <ronald.tetsuo@...> wrote: > >> I've just read the explanation in a Tim's blog post comment. Oh, well, >> generics definitely isn't easy to grasp... >> >> I myself have observed that my (wicket) code is so much readable without >> most generics declarations. Even when using components that do have models >> (Textfield, for example) I didn't gain anything for adding the angle >> brackets, since the models in general use reflection (PropertyModel, >> CompoundPropertyModel, etc.), and don't make any use of the build-time >> validation at all. >> >> sigh...(Continue reading)
Problem is setDefaultModelObject(). If you have setModelObject(Object o) you can not override it in subclass and restrict the parameter. -Matej On Mon, Jul 6, 2009 at 8:58 PM, tetsuo<ronald.tetsuo@...> wrote: > 'IModel<?> getModel()' instead of 'Object getModel()', and 'IModel<T> > getModel()' instead of 'T getModel()', sorry. > > And sorry for flooding the mailing list, this is the last one, I promise :) > > > > On Mon, Jul 6, 2009 at 3:54 PM, tetsuo <ronald.tetsuo@...> wrote: > >> What if Component was not generified, and had an 'Object getModel()' method >> instead of 'Object getDefaultModel()', and the components that do benefit >> from generics, simply override the method to return 'T' (then the component >> class would have a <T> type parameter)? The compiler accepts this just fine. >> >> Tetsuo >> >> >> >> >> On Mon, Jul 6, 2009 at 3:48 PM, tetsuo <ronald.tetsuo@...> wrote: >> >>> I've just read the explanation in a Tim's blog post comment. Oh, well,(Continue reading)
Now I get it, thanks. Indeed, it's hard to think in a better solution (without ditching generics altogether). Tetsuo On Mon, Jul 6, 2009 at 4:19 PM, Matej Knopp <matej.knopp@...> wrote: > Problem is setDefaultModelObject(). > > If you have setModelObject(Object o) you can not override it in > subclass and restrict the parameter. > > -Matej > > On Mon, Jul 6, 2009 at 8:58 PM, tetsuo<ronald.tetsuo@...> wrote: > > 'IModel<?> getModel()' instead of 'Object getModel()', and 'IModel<T> > > getModel()' instead of 'T getModel()', sorry. > > > > And sorry for flooding the mailing list, this is the last one, I promise > :) > > > > > > > > On Mon, Jul 6, 2009 at 3:54 PM, tetsuo <ronald.tetsuo@...> wrote: > > > >> What if Component was not generified, and had an 'Object getModel()' > method > >> instead of 'Object getDefaultModel()', and the components that do(Continue reading)
Am 06.07.2009 um 16:18 schrieb Jeremy Thomerson: > A good overall read, but he also seemed to miss the reason we have > getModel**Object**. He doesn't think that's necessary, but misses > that there is also getModel (without object) and the word does clarify > the difference. > > Anyway, a good read on overall API design, though. I'd recommend it > to others with the caveat that I also disagree with his last part > about the rename. I did like the design part too. Wicket used to be in a lot better shape in that subject, hopefully time will be found to work on that in 1.5. mf > > -- > Jeremy Thomerson > http://www.wickettraining.com > > > > > On Mon, Jul 6, 2009 at 8:22 AM, Martijn > Dashorst<martijn.dashorst@...> wrote: >> http://weblogs.java.net/blog/timboudreau/archive/2009/07/api_design_vs_a_1.html >> >> I guess he doesn't get why we did the rename. This reminds me that we >> *really* should improve our release docs before we finalize 1.4!!!(Continue reading)
RSS Feed