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]

Reply via email to