I think the key point is - if extending components by overriding methods is a supported (and encouraged) pattern in wicket there should be a *standard* way to do it. Sure it is possible for each user to hack a unique solution but this provides no common ground when people run into issues.
If every user implements it in their own way (or ignores the problem - which, as we have seen, limits extensibility) then it will be harder to support and the learning curve will be steeper. One documented, supported approach makes sense. In my opinion, component extension by overriding methods is very powerful and should be made as simple as possible. Mr Mean wrote: > >> > Such an initialize method can easily be done by users them self with a >> > simple factory pattern. >> > >> >> Can you give an example of this? > > public class MyFactory > ... > What a lot of bloat to simply give the *option* to customise components. Overridable methods area much more obvious way to make a component extendible and require less effort from the developer. I imagine that is why none of the core wicket components use such component factories. And, be honest... have you used this pattern in a real component? Mr Mean wrote: > >> Building such extendable components seems to be a core feature of wicket >> and >> one of its major selling points. I have unwittingly built many >> components >> that suffer from this problem already and I imagine it is a fairly >> common >> situation. It only becomes obvious when your subclass needs to access >> constructor parameters that your component acts in bizarre ways when >> extended. Now that is confusing. > > I fully agree with you, however this is not a wicket limitation but > something that cannot be done as expected in the java language. That > is why people have to resort to using things like initialize methods > or factory patterns. > Java constructors work as expected. When users "have to resort to using things like initiialize methods" they should be helped by a framework or specification to do it consistently. Mr Mean wrote: > > So while this is a problem > that a significant amount of user could encounter at one time or > another, forcing everyone to use factories for components like labels > just to avoid problems with more complex components is not a good > idea. that is what i meant with api bloat. > As Igor said at the beginning of this discussion, it is still preferable to use the constructor for most cases. So no one will be "forced" to use factories - but if you want to provide overridable factory methods there is a simple recommended place to do it. Mr Mean wrote: > > But you have to be careful that the solution does not introduce other > problems or more work for the more standard usecases or anti-patterns. > Exactly why each use should not be left wondering how to approach the problem themselves - if they even recognise it as a problem. John -- View this message in context: http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16959777.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
