On Mon, Jun 2, 2008 at 3:54 PM, Martin Funk <[EMAIL PROTECTED]>
wrote:
> There are quite some methods that don't return the component,
> but its class. Maybe most prominently 'getHomePage()' in Application.
>
> This used to have the signature:
> public abstract Class getHomePage();
>
> And a popular implementation would be:
> public Class getHomePage() {
> return HomePage.class
> }
>
> So maybe in favor of that popular implementation its current signature is:
>
> Application: public abstract Class<? extends Page<?>> getHomePage();
>
> which is not a generic method but a method with a generified return
> parameter.
> But at least this works with the existing user code basis very well.
> But it also implies a circle I can't break up in my mind yet.
> This signature forces you to implement HomePage as a raw type, a class
> without type parameters, esp. not generic.
> Though on the other hand HomePage is a descendant of Component which is
> generic, of course.
> Which is a strong sign for HomePage to be generic too.
>
> I think both ends don't go together well.
>
> How is this going to be solved? Or, explained?
<shrug>
One could generify Application. ;-)
class Application<P extends Page> {
public abstract P getHomePage();
}
Generifying Component buys you no casting, at the expense of being hideously
verbose at times.
Generifying IModel buys you more obvious method signatures, particularly for
things like DropDownChoice.
The second is almost certainly worth doing. That said, I use PropertyModel
more often than anything else, and that doesn't allow you to make any
guarantees anyway. :-/
Al
