On Sun, Apr 27, 2008 at 7:55 AM, John Patterson <[EMAIL PROTECTED]> wrote:
>
>
>
> 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);
}
}
>
>
>
> Mr Mean wrote:
> >
> > So why bloat our api with it?
> >
>
> 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.
>
> Would others agree that it is fairly common to allow subclasses to override
> some components? Or is this a corner case in wicket development?
Depends on the component, something like label or textfield is
unlikely to suffer from this problem. The more complex components like
datatable or paging navigation that are essentially a bunch of
components working together is much more likely to have this problem
if it tries to be as flexible as possible. 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.
>
>
>
> Mr Mean wrote:
> >
> > Not more confusing, just confusing. i can already see the mails
> > arriving on the mailing list. Documenting a behavior will only go so
> > far, as the current problem so elegantly shows ;)
> >
>
> 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.
>
>
> Mr Mean wrote:
> >
> > Don't get me wrong i am all in favor of finding a good solution for
> > this, but imho so far i have not yet heard a solution that provides a
> > significantly better approach.
> >
>
> Both your suggested factory method and the proposed onXXXXXX() method would
> need to solve the problems of
>
> 1 - Checking against adding components more than once
> 2 - requirement to call super.onBeforeRender()
>
> and so would be significantly better - especially if this is a common
> pattern.
Well depending on the solution you would yes, you are only describing
problems related to onXXX. a factory for instance does not have these
problems as it does not add the components it just create them. 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.
>
> John
> --
> View this message in context:
> http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16918361.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]
