On Tue, Apr 29, 2008 at 2:44 PM, John Patterson <[EMAIL PROTECTED]> wrote:
>
> 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.
Who wouldn't agree with this ;)
>
> 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
> > {
> > public SomeComponent getComponent(String id,someParams)
> > {
> > SomeComponent c=new MyCustomComponent(id,someParams);
> > c.init();
> > return c;
> > }
> > }
> >
> > public class MyPage extends webPage
> > {
> > public MyPage()
> > {
> > add(factory.getComponent("id",foo);
> > }
> > }
> >
> >
>
> What a huge amount of bloat to simply give the *option* to customise
> components.
Exactly what i have been saying. Overridable methods was already
mentioned i simply mentioned an alternative that also had come up in
earlier posts.
> 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?
No, i use an init method to attach overridable subcomponents. all
subclasses have to trigger the init method themself in there
constructor. It is not perfect but works for me.
>
>
>
>
> 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 the framework 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 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 way to do it.
>
>
>
> Mr Mean wrote:
> >
> >> Is this issue even documented yet? I will create a page for it but
> >> waiting
> >> until this discussion closes
> >>
> > Well this particular issue has been around on the mailing list a few
> > times, so in a way it is self documented ;)
> > I honestly have not looked if there is wiki page for this or if it is
> > mentioned in the api doc.
> >
>
> Is this feature of wicket useful? Damn yes. So it should be paraded about
> and
>
>
>
> 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
Wow, you make it sound like i am singlehandedly responsible for
bringing progress in this matter to a grinding halt.
I am not, i want to solve this in a simple and elegant matter too.
Maurice
>
> --
> View this message in context:
> http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16959612.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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
