Sorry, type given to meta data key should be Boolean, not
IBeforeFirstRenderListener.
On Tue, Apr 29, 2008 at 8:55 AM, James Carman
<[EMAIL PROTECTED]> wrote:
> Would you like me to add something like this to the wiki?
>
> // The interface...
> public interface IBeforeFirstRenderListener
> {
> public void onBeforeFirstRender();
> }
>
> // The invoking listener...
> public class BeforeFirstRenderListenerInvoker implements
> IComponentOnBeforeRenderListener
> {
> public static final MetaDataKey META_KEY = new
> MetaDataKey(IBeforeFirstRenderListener.class)
> {
> private static final long serialVersionUID = -1545274527459326785L;
> };
>
> public void onBeforeRender(Component component)
> {
> if(component instanceof IBeforeFirstRenderListener &&
> component.getMetaData(META_KEY) == null)
> {
> ((IBeforeFirstRenderListener)component ).onBeforeFirstRender();
> component.setMetaData(META_KEY, Boolean.TRUE);
>
>
> }
> }
> }
>
>
> On Tue, Apr 29, 2008 at 8:44 AM, 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.
> >
> > 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. 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 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
> >
> > --
> > 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]
