Re: Alternative method to initialise page
That is bad programming anyway. Why make a next page already?? On 4/30/08, John Patterson [EMAIL PROTECTED] wrote: I was thinking that another benefit of initialising the page after construction is less memory use when using redirect to render, when there are many invisible components, or in situations where a page instance is created to pass to another page as the next page or return page. igor.vaynberg wrote: heh, even though we switched to int we are pretty close to running out of flag bits already :) but oh well :) -igor -- View this message in context: http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16975470.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]
Re: Alternative method to initialise page
Well yeah, I don't do that... don't know how common redirect to render is either. Just thinking of how the delay in initialisation might effect memory. Prob not much for most apps. Johan Compagner wrote: That is bad programming anyway. Why make a next page already?? On 4/30/08, John Patterson [EMAIL PROTECTED] wrote: I was thinking that another benefit of initialising the page after construction is less memory use when using redirect to render, when there are many invisible components, or in situations where a page instance is created to pass to another page as the next page or return page. igor.vaynberg wrote: heh, even though we switched to int we are pretty close to running out of flag bits already :) but oh well :) -igor -- View this message in context: http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16975470.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] -- View this message in context: http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16983680.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]
Re: Alternative method to initialise page
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]
Re: Alternative method to initialise page
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]
Re: Alternative method to initialise page
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]
Re: Alternative method to initialise page
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
Re: Alternative method to initialise page
This approach breaks a components encapsulation because the listener must be
installed in the application. Even if IInitializers can be used to do this
once it ads an extra complication to creating reusable components.
Point-in-case: Should PagingNavigation use this technique to call its
factory methods?
jwcarman wrote:
Would you like me to add something like this to the wiki?
// The interface...
public interface IBeforeFirstRenderListener
{
public void onBeforeFirstRender();
}
--
View this message in context:
http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16961287.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]
Re: Alternative method to initialise page
First i dont want a boolen in the components that onFirstRender() is called. I want a boolean that it is not called. So in the constructor of component we set the flag and clear it when first rendered. Do remember that in onBeforeRende components/panels and all can be created again but i think this will go ok. Johan On 4/29/08, James Carman [EMAIL PROTECTED] wrote: On Tue, Apr 29, 2008 at 10:24 AM, John Patterson [EMAIL PROTECTED] wrote: This approach breaks a components encapsulation because the listener must be installed in the application. Even if IInitializers can be used to do this once it ads an extra complication to creating reusable components. Perhaps this could be added to core since it's a common enough pattern? That way, you wouldn't have to worry about the requirement of making sure that you add the listener in. It would be there automatically. Or, you can do this manually in your own Component class and not rely upon the listener to call it. You just do it in onBeforeRender() and slap that meta tag on the component after you perform the initialization. Or, we make a new callback method on Component called onBeforeFirstRender() or something. I don't know. I'm just trying to help come up with ideas here. In our application, the IBeforeFirstRenderListener approach is working because I'm not creating re-usable components to be consumed outside my application. - 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]
Re: Alternative method to initialise page
On Tue, Apr 29, 2008 at 3:59 PM, Johan Compagner [EMAIL PROTECTED] wrote: First i dont want a boolen in the components that onFirstRender() is called. I want a boolean that it is not called. So in the constructor of component we set the flag and clear it when first rendered. Are we thinking of adding this into core? You're talking about modifying the constructor of Component. Do remember that in onBeforeRende components/panels and all can be created again but i think this will go ok. Yes, each one of these components will each have to be rendered also, so they'd go through the same logic upon their first render, correct? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative method to initialise page
I am just saying if we make such a thing, that i dont want state after the fact in a components. But i guess we can then better use a bit i think we have a few left. On 4/30/08, James Carman [EMAIL PROTECTED] wrote: On Tue, Apr 29, 2008 at 3:59 PM, Johan Compagner [EMAIL PROTECTED] wrote: First i dont want a boolen in the components that onFirstRender() is called. I want a boolean that it is not called. So in the constructor of component we set the flag and clear it when first rendered. Are we thinking of adding this into core? You're talking about modifying the constructor of Component. Do remember that in onBeforeRende components/panels and all can be created again but i think this will go ok. Yes, each one of these components will each have to be rendered also, so they'd go through the same logic upon their first render, correct? - 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]
Re: Alternative method to initialise page
heh, even though we switched to int we are pretty close to running out of flag bits already :) but oh well :) -igor On Tue, Apr 29, 2008 at 7:07 PM, Johan Compagner [EMAIL PROTECTED] wrote: I am just saying if we make such a thing, that i dont want state after the fact in a components. But i guess we can then better use a bit i think we have a few left. On 4/30/08, James Carman [EMAIL PROTECTED] wrote: On Tue, Apr 29, 2008 at 3:59 PM, Johan Compagner [EMAIL PROTECTED] wrote: First i dont want a boolen in the components that onFirstRender() is called. I want a boolean that it is not called. So in the constructor of component we set the flag and clear it when first rendered. Are we thinking of adding this into core? You're talking about modifying the constructor of Component. Do remember that in onBeforeRende components/panels and all can be created again but i think this will go ok. Yes, each one of these components will each have to be rendered also, so they'd go through the same logic upon their first render, correct? - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative method to initialise page
I was thinking that another benefit of initialising the page after construction is less memory use when using redirect to render, when there are many invisible components, or in situations where a page instance is created to pass to another page as the next page or return page. igor.vaynberg wrote: heh, even though we switched to int we are pretty close to running out of flag bits already :) but oh well :) -igor -- View this message in context: http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16975470.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]
Re: Alternative method to initialise page
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 onXX() 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]
Re: Alternative method to initialise page
On Mon, Apr 28, 2008 at 5:57 AM, James Carman
[EMAIL PROTECTED] wrote:
On Sat, Apr 26, 2008 at 4:55 PM, Maurice Marrink [EMAIL PROTECTED] wrote:
Such an initialize method can easily be done by users them self with a
simple factory pattern. So why bloat our api with it?
Could one come up with their own interface which means they want
delayed intialization and use an IComponentInstantiationListener to
invoke the method?
public interface Initializable
{
public void initialize();
}
public class InitializableInstantiationListener implements
IComponentInstantiationListener
{
public void onInstantiation(Component component)
{
if(component instanceof Initializable)
{
( ( Initializable )component ).initialize();
}
}
}
Or, perhaps Wicket could add in some lifecycle method annotations?
One such annotation would mean that a method needs to be invoked
directly after the component is fully instantiated?
public class MyPanel extends Panel
{
@Initializer
public void init()
{
add(new Label(blah));
...
}
}
Then, one of the default component instantiation listeners merely
looks for methods annotated with this annotation and invokes it (and
optionally remembers what methods need to be invoked for what
component classes probably).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative method to initialise page
James Carman schrieb: Or, perhaps Wicket could add in some lifecycle method annotations? pleeease don´t! using annotations for this kind of lifecycle methods is a simple abuse of them. non-obvious order, inheritance etc... lesson learned from jpa,ejb3 etc... cu uwe -- THOMAS DAILY GmbH Adlerstraße 19 79098 Freiburg Deutschland T + 49 761 3 85 59 0 F + 49 761 3 85 59 550 E [EMAIL PROTECTED] www.thomas-daily.de Geschäftsführer/Managing Directors: Wendy Thomas, Susanne Larbig Handelsregister Freiburg i.Br., HRB 3947 Registrieren Sie sich unter http://morningnews.thomas-daily.de für die kostenfreien TD Morning News, eine Auswahl aktueller Themen des Tages morgens um 9:00 in Ihrer Mailbox. Hinweis: Der Redaktionsschluss für unsere TD Morning News ist täglich um 8:30 Uhr. Es werden vorrangig Informationen berücksichtigt, die nach 16:00 Uhr des Vortages eingegangen sind. Die Email-Adresse unserer Redaktion lautet [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative method to initialise page
On Sat, Apr 26, 2008 at 4:55 PM, Maurice Marrink [EMAIL PROTECTED] wrote:
Such an initialize method can easily be done by users them self with a
simple factory pattern. So why bloat our api with it?
Could one come up with their own interface which means they want
delayed intialization and use an IComponentInstantiationListener to
invoke the method?
public interface Initializable
{
public void initialize();
}
public class InitializableInstantiationListener implements
IComponentInstantiationListener
{
public void onInstantiation(Component component)
{
if(component instanceof Initializable)
{
( ( Initializable )component ).initialize();
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative method to initialise page
On Mon, Apr 28, 2008 at 6:27 AM, James Carman
[EMAIL PROTECTED] wrote:
Yes, this would involve making up some rules about the order in which
the parent class' initializer methods are invoked. A couple that come
to mind:
1. There should only be one initializer method declared per class (to
avoid the which do we call first problem).
2. Parent class' initializer methods should be invoked first.
I don't agree that marking lifecycle methods with annotations is an
abuse (of annotations?) at all. Perhaps this wouldn't belong in the
core, but I can see it as an extension or a wicketstuff project
maybe?
I actually played around with this a bit. I've created an annotation:
@Retention( RetentionPolicy.RUNTIME)
@Target( ElementType.METHOD)
public @interface Initialization
{
}
Then, I created the listener:
public class InitializationInstantiationListener implements
IComponentInstantiationListener
{
//**
// Fields
//**
private final MapClass, Initializer initializersMap = new
HashMapClass, Initializer();
//**
// IComponentInstantiationListener Implementation
//**
public void onInstantiation( Component component )
{
Initializer initializer = getInitializer(component);
initializer.initialize(component);
}
private synchronized Initializer getInitializer( Component component )
{
final Class? extends Component componentClass = component.getClass();
Initializer initializer = initializersMap.get(componentClass);
if( initializer == null )
{
final ListMethod initializationMethods =
getInitializationMethods(component);
initializer = createInitializer(componentClass,
initializationMethods);
initializersMap.put(componentClass, initializer);
}
return initializer;
}
//**
// Other Methods
//**
private synchronized ListMethod getInitializationMethods(
Component component )
{
ListMethod initializationMethods = new LinkedListMethod();
Class c = component.getClass();
while( c != null )
{
Method initializer = getInitializationMethod(c);
if( initializer != null )
{
initializationMethods.add(0, initializer);
}
c = c.getSuperclass();
}
return initializationMethods;
}
private Method getInitializationMethod( Class c )
{
SetMethod initializers = new HashSetMethod();
final Method[] declaredMethods = c.getDeclaredMethods();
for( Method declaredMethod : declaredMethods )
{
if( declaredMethod.getAnnotation(Initialization.class) != null )
{
if( Modifier.isPublic(declaredMethod.getModifiers())
Void.TYPE.equals(declaredMethod.getReturnType())
declaredMethod.getParameterTypes().length == 0 )
{
initializers.add(declaredMethod);
}
else
{
throw new WicketRuntimeException(Invalid
initializer method declared on class + c.getName() +
. Initializers must be public, have a
void return type, and take no parameters.);
}
}
}
switch( initializers.size() )
{
case 1:
return initializers.iterator().next();
case 0:
return null;
default:
throw new WicketRuntimeException(Class +
c.getName() + declares multiple ( + initializers.size() +
) initializer methods.);
}
}
protected Initializer createInitializer( Class componentClass,
ListMethod initializationMethods )
{
return initializationMethods.isEmpty() ? new NullInitializer()
: new ReflectionInitializer(initializationMethods);
}
//**
// Inner Classes
//**
protected static interface Initializer
{
public void initialize( Component component );
}
Re: Alternative method to initialise page
How well did you test this?
Because i think the biggest problem here is that the
IComponentInstantiationListener is invoked in the constructor of
Component and thus before any childclass constructor has run.
Maurice
On Mon, Apr 28, 2008 at 1:42 PM, James Carman
[EMAIL PROTECTED] wrote:
On Mon, Apr 28, 2008 at 6:27 AM, James Carman
[EMAIL PROTECTED] wrote:
Yes, this would involve making up some rules about the order in which
the parent class' initializer methods are invoked. A couple that come
to mind:
1. There should only be one initializer method declared per class (to
avoid the which do we call first problem).
2. Parent class' initializer methods should be invoked first.
I don't agree that marking lifecycle methods with annotations is an
abuse (of annotations?) at all. Perhaps this wouldn't belong in the
core, but I can see it as an extension or a wicketstuff project
maybe?
I actually played around with this a bit. I've created an annotation:
@Retention( RetentionPolicy.RUNTIME)
@Target( ElementType.METHOD)
public @interface Initialization
{
}
Then, I created the listener:
public class InitializationInstantiationListener implements
IComponentInstantiationListener
{
//**
// Fields
//**
private final MapClass, Initializer initializersMap = new
HashMapClass, Initializer();
//**
// IComponentInstantiationListener Implementation
//**
public void onInstantiation( Component component )
{
Initializer initializer = getInitializer(component);
initializer.initialize(component);
}
private synchronized Initializer getInitializer( Component component )
{
final Class? extends Component componentClass =
component.getClass();
Initializer initializer = initializersMap.get(componentClass);
if( initializer == null )
{
final ListMethod initializationMethods =
getInitializationMethods(component);
initializer = createInitializer(componentClass,
initializationMethods);
initializersMap.put(componentClass, initializer);
}
return initializer;
}
//**
// Other Methods
//**
private synchronized ListMethod getInitializationMethods(
Component component )
{
ListMethod initializationMethods = new LinkedListMethod();
Class c = component.getClass();
while( c != null )
{
Method initializer = getInitializationMethod(c);
if( initializer != null )
{
initializationMethods.add(0, initializer);
}
c = c.getSuperclass();
}
return initializationMethods;
}
private Method getInitializationMethod( Class c )
{
SetMethod initializers = new HashSetMethod();
final Method[] declaredMethods = c.getDeclaredMethods();
for( Method declaredMethod : declaredMethods )
{
if( declaredMethod.getAnnotation(Initialization.class) != null )
{
if( Modifier.isPublic(declaredMethod.getModifiers())
Void.TYPE.equals(declaredMethod.getReturnType())
declaredMethod.getParameterTypes().length == 0 )
{
initializers.add(declaredMethod);
}
else
{
throw new WicketRuntimeException(Invalid
initializer method declared on class + c.getName() +
. Initializers must be public, have a
void return type, and take no parameters.);
}
}
}
switch( initializers.size() )
{
case 1:
return initializers.iterator().next();
case 0:
return null;
default:
throw new WicketRuntimeException(Class +
c.getName() + declares multiple ( + initializers.size() +
) initializer methods.);
}
}
protected Initializer createInitializer( Class componentClass,
ListMethod initializationMethods )
{
return
Re: Alternative method to initialise page
On Mon, Apr 28, 2008 at 7:58 AM, Maurice Marrink [EMAIL PROTECTED] wrote: How well did you test this? Only whipped it up very quickly (based on obviously wrong assumptions :). Because i think the biggest problem here is that the IComponentInstantiationListener is invoked in the constructor of Component and thus before any childclass constructor has run. Oh! Nasty. I thought you guys were somehow waiting until the Component was fully instantiated for this notification to occur. If that's not true, then my method won't work either. Can we beef up the IComponentInstantiationListener notification mechanism somehow? Is there some hook in the request cycle that we can use to call the IComponentInstantiationListeners on all Components that have been instantiated? Of course, this notification could then, in turn, create more components. Yuck, this is quite an ugly problem. I guess the Components that are instantiated can append themselves to the queue which is being processed by all of the instantiation listeners? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative method to initialise page
On Mon, Apr 28, 2008 at 2:15 PM, James Carman [EMAIL PROTECTED] wrote: On Mon, Apr 28, 2008 at 7:58 AM, Maurice Marrink [EMAIL PROTECTED] wrote: How well did you test this? Only whipped it up very quickly (based on obviously wrong assumptions :). Because i think the biggest problem here is that the IComponentInstantiationListener is invoked in the constructor of Component and thus before any childclass constructor has run. Oh! Nasty. I thought you guys were somehow waiting until the Component was fully instantiated for this notification to occur. If Nope. One of the places where this is used, is for security (intercepting if a component is authorized to be instantiated) in that case you want to abort as soon as possible. that's not true, then my method won't work either. Can we beef up the IComponentInstantiationListener notification mechanism somehow? Is there some hook in the request cycle that we can use to call the IComponentInstantiationListeners on all Components that have been instantiated? That would only work (if at all) if we do that call between onBeforeRender and the actual rendering since components like listview will wait till the last possible time to create there components. Of course, this notification could then, in turn, create more components. Yuck, this is quite an ugly problem. I guess the Components that are instantiated can append themselves to the queue which is being processed by all of the instantiation listeners? yuck indeed. Maurice - 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]
Re: Alternative method to initialise page
On Mon, Apr 28, 2008 at 8:31 AM, Maurice Marrink [EMAIL PROTECTED] wrote: Oh! Nasty. I thought you guys were somehow waiting until the Component was fully instantiated for this notification to occur. If Nope. One of the places where this is used, is for security (intercepting if a component is authorized to be instantiated) in that case you want to abort as soon as possible. And the Spring listener actually makes @SpringBeans available during the subclass' constructor. So, that would break also. Perhaps we need an IAfterComponentInstantiationListener or something? Each Component would append itself to a queue to be processed by all of the after component instantiation listeners. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative method to initialise page
springbean is ok. although bends the rule rather then breaking it by not depending on any state of the super class. if we did it the other way then the dependencies would be null during the constructor call, which is obviously something we want to avoid. -igor On Mon, Apr 28, 2008 at 6:22 AM, James Carman [EMAIL PROTECTED] wrote: On Mon, Apr 28, 2008 at 8:31 AM, Maurice Marrink [EMAIL PROTECTED] wrote: Oh! Nasty. I thought you guys were somehow waiting until the Component was fully instantiated for this notification to occur. If Nope. One of the places where this is used, is for security (intercepting if a component is authorized to be instantiated) in that case you want to abort as soon as possible. And the Spring listener actually makes @SpringBeans available during the subclass' constructor. So, that would break also. Perhaps we need an IAfterComponentInstantiationListener or something? Each Component would append itself to a queue to be processed by all of the after component instantiation listeners. - 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]
Re: Alternative method to initialise page
2008/4/28 Uwe Schäfer [EMAIL PROTECTED]: James Carman schrieb: Or, perhaps Wicket could add in some lifecycle method annotations? pleeease don´t! using annotations for this kind of lifecycle methods is a simple abuse of them. non-obvious order, inheritance etc... lesson learned from jpa,ejb3 etc... no worries. we are not going to do this. at one point we had @OnBeforeRender, @OnAfterRender, @OnDetach and a couple of others all working in the 2.0 branch. we didnt like it. the code became a lot less self-documenting, and in the end you still ended up overriding existing methods a lot of the times so there was no benefit. -igor cu uwe -- THOMAS DAILY GmbH Adlerstraße 19 79098 Freiburg Deutschland T + 49 761 3 85 59 0 F + 49 761 3 85 59 550 E [EMAIL PROTECTED] www.thomas-daily.de Geschäftsführer/Managing Directors: Wendy Thomas, Susanne Larbig Handelsregister Freiburg i.Br., HRB 3947 Registrieren Sie sich unter http://morningnews.thomas-daily.de für die kostenfreien TD Morning News, eine Auswahl aktueller Themen des Tages morgens um 9:00 in Ihrer Mailbox. Hinweis: Der Redaktionsschluss für unsere TD Morning News ist täglich um 8:30 Uhr. Es werden vorrangig Informationen berücksichtigt, die nach 16:00 Uhr des Vortages eingegangen sind. Die Email-Adresse unserer Redaktion lautet [EMAIL PROTECTED] - 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]
Re: Alternative method to initialise page
On Mon, Apr 28, 2008 at 10:58 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: 2008/4/28 Uwe Schäfer [EMAIL PROTECTED]: James Carman schrieb: Or, perhaps Wicket could add in some lifecycle method annotations? pleeease don´t! using annotations for this kind of lifecycle methods is a simple abuse of them. non-obvious order, inheritance etc... lesson learned from jpa,ejb3 etc... no worries. we are not going to do this. at one point we had @OnBeforeRender, @OnAfterRender, @OnDetach and a couple of others all working in the 2.0 branch. we didnt like it. the code became a lot less self-documenting, and in the end you still ended up overriding existing methods a lot of the times so there was no benefit. That's true. Most folks would just pick a method name and stick with it for all initialization. So, this wouldn't buy you much. An interface-based approach might, though. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative method to initialise page
you can roll that, just use the beforerenderlistener you can install in the application subclass. -igor On Mon, Apr 28, 2008 at 8:03 AM, James Carman [EMAIL PROTECTED] wrote: On Mon, Apr 28, 2008 at 10:58 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: 2008/4/28 Uwe Schäfer [EMAIL PROTECTED]: James Carman schrieb: Or, perhaps Wicket could add in some lifecycle method annotations? pleeease don´t! using annotations for this kind of lifecycle methods is a simple abuse of them. non-obvious order, inheritance etc... lesson learned from jpa,ejb3 etc... no worries. we are not going to do this. at one point we had @OnBeforeRender, @OnAfterRender, @OnDetach and a couple of others all working in the 2.0 branch. we didnt like it. the code became a lot less self-documenting, and in the end you still ended up overriding existing methods a lot of the times so there was no benefit. That's true. Most folks would just pick a method name and stick with it for all initialization. So, this wouldn't buy you much. An interface-based approach might, though. - 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]
Re: Alternative method to initialise page
On Mon, Apr 28, 2008 at 11:05 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: you can roll that, just use the beforerenderlistener you can install in the application subclass. We just have to make sure we only initialize an instance one time. The IComponentOnBeforeRenderListeners are called every time the component is rendered. Can't a specific component instance be rendered more than one time? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative method to initialise page
yes of course. you have to keep a boolean in the metadata to mark if the handler has been called already. -igor On Mon, Apr 28, 2008 at 8:12 AM, James Carman [EMAIL PROTECTED] wrote: On Mon, Apr 28, 2008 at 11:05 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: you can roll that, just use the beforerenderlistener you can install in the application subclass. We just have to make sure we only initialize an instance one time. The IComponentOnBeforeRenderListeners are called every time the component is rendered. Can't a specific component instance be rendered more than one time? - 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]
Re: Alternative method to initialise page
On Mon, Apr 28, 2008 at 11:45 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: yes of course. you have to keep a boolean in the metadata to mark if the handler has been called already. Ok, gotcha! I need to keep that metadata stuff in my head. That's a nifty little trick for adding ad-hoc properties to components on the fly. I was thinking about keeping a stupid hashset of all components I've initialized, but that would be just plain stupid! :) Thanks, Igor! You da man! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative method to initialise page
On Sat, Apr 26, 2008 at 10:55 PM, John Patterson [EMAIL PROTECTED] wrote: 1 - Checking against adding components more than once to be fair this one doesnt apply. wicket throws a pretty descriptive exception if you forget to call super.onbeforerender(), also its javadoc mentions that overrides must call super. too bad there isnt an annotation yet that checks this at compile time. -igor 2 - requirement to call super.onBeforeRender() and so would be significantly better - especially if this is a common pattern. 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]
Re: Alternative method to initialise page
John Patterson wrote: Hi, I am extending the PagingNavigatation and need to access some member variables to create my page links. Because these links are created in PagingNavigatation's constructor me subclasses newPagingNavigationLink() method is called before my subclasses member variables are initialised. I realised that this situation must occur quite often when extending any class that allows subclasses to provide or override any components. Does anyone have a nice workaround? It seems to me that creating the pages component tree in some kind of initialisation step would make classes easier to extend. Or is there already a method that should be used to do this? Thanks, John I had similar problems, when I worked with DefaultDataTable and needed to have custom PagingNavigation. For example, DefaultDataTable has no factory methods for creating custom PagingNavigation so I had to copy-paste it and change some minor parts of the class. But it was very easy and I take the default implementations as an example how to work with them. SS -- View this message in context: http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16922848.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]
Re: Alternative method to initialise page
On Sat, Apr 26, 2008 at 01:58:28PM -0700, John Patterson wrote: Note to self: don't post messages when half cut. But I have to break that rule just one more time Heh, no problem. Been there once or twice myself... jk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative method to initialise page
Cool. I can see that you now and the links in onBeforeRender(). So is this
the recommended approach for creating extendible components? What are the
reasons to not to add all child components in this method?
igor.vaynberg wrote:
fixed in trunk for 1.4, i will fix in 1.3.x later today when i can get
to my desktop.
https://issues.apache.org/jira/browse/WICKET-1548
-igor
On Thu, Apr 17, 2008 at 3:54 AM, Maurice Marrink [EMAIL PROTECTED]
wrote:
PaginNavigation is not setup properly for extending, we are aware of
this and probably will fix it in wicket 1.5. in the meantime you could
try and copy paste the classes into your own project and then modify
them.
Maurice
On Thu, Apr 17, 2008 at 12:14 PM, John Patterson [EMAIL PROTECTED]
wrote:
John Patterson wrote:
Hi,
I am extending the PagingNavigatation and need to access some
member
variables to create my page links. Because these links are created
in
PagingNavigatation's constructor me subclasses
newPagingNavigationLink()
method is called before my subclasses member variables are
initialised. I
realised that this situation must occur quite often when extending
any
class that allows subclasses to provide or override any components.
Does anyone have a nice workaround?
It seems to me that creating the pages component tree in some kind
of
initialisation step would make classes easier to extend. Or is
there
already a method that should be used to do this?
Thanks,
John
Just to be a bit clearer
class MySubclass extends WicketBaseclass
{
MyDomainObject _parameter;
MySubclass(String id, MyDomainObject parameter)
{
super(id);
_parameter = parameter;
}
@Override
protected Component overrideToCreateCustomComponent()
{
return new MyCustomisedCompopnent(_parameter.getSomething());
}
}
So _parameter will always be null when
overrideToCreateCustomComponent() is
called from the base class
--
View this message in context:
http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16742891.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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16910691.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]
Re: Alternative method to initialise page
it is called every time the page renders. Though creating objects
isn't *that* expensive, imagine recreating all your components with
every request for every user, discarding all the components you
already created one request earlier.
Martijn
On 4/26/08, John Patterson [EMAIL PROTECTED] wrote:
Cool. I can see that you now and the links in onBeforeRender(). So is this
the recommended approach for creating extendible components? What are the
reasons to not to add all child components in this method?
igor.vaynberg wrote:
fixed in trunk for 1.4, i will fix in 1.3.x later today when i can get
to my desktop.
https://issues.apache.org/jira/browse/WICKET-1548
-igor
On Thu, Apr 17, 2008 at 3:54 AM, Maurice Marrink [EMAIL PROTECTED]
wrote:
PaginNavigation is not setup properly for extending, we are aware of
this and probably will fix it in wicket 1.5. in the meantime you could
try and copy paste the classes into your own project and then modify
them.
Maurice
On Thu, Apr 17, 2008 at 12:14 PM, John Patterson [EMAIL PROTECTED]
wrote:
John Patterson wrote:
Hi,
I am extending the PagingNavigatation and need to access some
member
variables to create my page links. Because these links are created
in
PagingNavigatation's constructor me subclasses
newPagingNavigationLink()
method is called before my subclasses member variables are
initialised. I
realised that this situation must occur quite often when extending
any
class that allows subclasses to provide or override any components.
Does anyone have a nice workaround?
It seems to me that creating the pages component tree in some kind
of
initialisation step would make classes easier to extend. Or is
there
already a method that should be used to do this?
Thanks,
John
Just to be a bit clearer
class MySubclass extends WicketBaseclass
{
MyDomainObject _parameter;
MySubclass(String id, MyDomainObject parameter)
{
super(id);
_parameter = parameter;
}
@Override
protected Component overrideToCreateCustomComponent()
{
return new MyCustomisedCompopnent(_parameter.getSomething());
}
}
So _parameter will always be null when
overrideToCreateCustomComponent() is
called from the base class
--
View this message in context:
http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16742891.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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16910691.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]
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative method to initialise page
Thanks. So is this the way we should build all components that could be
extended? If so, how about adding an initialisation hook to avoid this
problem and the need to call super.onBeforeRender() (which I forgot recently
and took me a while to find)... and also to give it a more intuitive name
like initialise()
John
Martijn Dashorst wrote:
it is called every time the page renders. Though creating objects
isn't *that* expensive, imagine recreating all your components with
every request for every user, discarding all the components you
already created one request earlier.
Martijn
On 4/26/08, John Patterson [EMAIL PROTECTED] wrote:
Cool. I can see that you now and the links in onBeforeRender(). So is
this
the recommended approach for creating extendible components? What are
the
reasons to not to add all child components in this method?
igor.vaynberg wrote:
fixed in trunk for 1.4, i will fix in 1.3.x later today when i can get
to my desktop.
https://issues.apache.org/jira/browse/WICKET-1548
-igor
On Thu, Apr 17, 2008 at 3:54 AM, Maurice Marrink [EMAIL PROTECTED]
wrote:
PaginNavigation is not setup properly for extending, we are aware of
this and probably will fix it in wicket 1.5. in the meantime you
could
try and copy paste the classes into your own project and then modify
them.
Maurice
On Thu, Apr 17, 2008 at 12:14 PM, John Patterson [EMAIL PROTECTED]
wrote:
John Patterson wrote:
Hi,
I am extending the PagingNavigatation and need to access some
member
variables to create my page links. Because these links are
created
in
PagingNavigatation's constructor me subclasses
newPagingNavigationLink()
method is called before my subclasses member variables are
initialised. I
realised that this situation must occur quite often when
extending
any
class that allows subclasses to provide or override any
components.
Does anyone have a nice workaround?
It seems to me that creating the pages component tree in some
kind
of
initialisation step would make classes easier to extend. Or is
there
already a method that should be used to do this?
Thanks,
John
Just to be a bit clearer
class MySubclass extends WicketBaseclass
{
MyDomainObject _parameter;
MySubclass(String id, MyDomainObject parameter)
{
super(id);
_parameter = parameter;
}
@Override
protected Component overrideToCreateCustomComponent()
{
return new
MyCustomisedCompopnent(_parameter.getSomething());
}
}
So _parameter will always be null when
overrideToCreateCustomComponent() is
called from the base class
--
View this message in context:
http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16742891.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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16910691.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]
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16910806.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]
Re: Alternative method to initialise page
We have discussed this over and over on the list. Search the archives.
Short answer: NO.
Martijn
On 4/26/08, John Patterson [EMAIL PROTECTED] wrote:
Thanks. So is this the way we should build all components that could be
extended? If so, how about adding an initialisation hook to avoid this
problem and the need to call super.onBeforeRender() (which I forgot recently
and took me a while to find)... and also to give it a more intuitive name
like initialise()
John
Martijn Dashorst wrote:
it is called every time the page renders. Though creating objects
isn't *that* expensive, imagine recreating all your components with
every request for every user, discarding all the components you
already created one request earlier.
Martijn
On 4/26/08, John Patterson [EMAIL PROTECTED] wrote:
Cool. I can see that you now and the links in onBeforeRender(). So is
this
the recommended approach for creating extendible components? What are
the
reasons to not to add all child components in this method?
igor.vaynberg wrote:
fixed in trunk for 1.4, i will fix in 1.3.x later today when i can get
to my desktop.
https://issues.apache.org/jira/browse/WICKET-1548
-igor
On Thu, Apr 17, 2008 at 3:54 AM, Maurice Marrink [EMAIL PROTECTED]
wrote:
PaginNavigation is not setup properly for extending, we are aware of
this and probably will fix it in wicket 1.5. in the meantime you
could
try and copy paste the classes into your own project and then modify
them.
Maurice
On Thu, Apr 17, 2008 at 12:14 PM, John Patterson [EMAIL PROTECTED]
wrote:
John Patterson wrote:
Hi,
I am extending the PagingNavigatation and need to access some
member
variables to create my page links. Because these links are
created
in
PagingNavigatation's constructor me subclasses
newPagingNavigationLink()
method is called before my subclasses member variables are
initialised. I
realised that this situation must occur quite often when
extending
any
class that allows subclasses to provide or override any
components.
Does anyone have a nice workaround?
It seems to me that creating the pages component tree in some
kind
of
initialisation step would make classes easier to extend. Or is
there
already a method that should be used to do this?
Thanks,
John
Just to be a bit clearer
class MySubclass extends WicketBaseclass
{
MyDomainObject _parameter;
MySubclass(String id, MyDomainObject parameter)
{
super(id);
_parameter = parameter;
}
@Override
protected Component overrideToCreateCustomComponent()
{
return new
MyCustomisedCompopnent(_parameter.getSomething());
}
}
So _parameter will always be null when
overrideToCreateCustomComponent() is
called from the base class
--
View this message in context:
http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16742891.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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16910691.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]
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
Re: Alternative method to initialise page
Sorry, I did find a discussion which was related [1] which ended with Igor saying: yes, but its also easy to fix. Just don't call any overridible methods inside constructors. And for everything else there is onbeforerender() If this is the recommended way to write extendible components I could add a wiki page because it is not very intuitive. So to be clear, whenever building a component designed to be extendible: 1 - Call all overridable methods from onBeforeRender() 2 - Check that components are not added more than once 3 - call super.onBeforeRender() Anything else to keep in mind? Thanks, John [1] http://www.nabble.com/Re%3A-Jira-issue-moved-to-the-list%3A-constructors-and-init-of-components-p13569575.html Martijn Dashorst wrote: We have discussed this over and over on the list. Search the archives. Short answer: NO. -- View this message in context: http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16911887.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]
Re: Alternative method to initialise page
John Krasnay wrote: This rule is too strict. Another way to avoid calling overridable methods from the constructor is to use a model: Models are fine for providing dynamic values but do not help you customise components by extension. For example, to provide a different type of link to use in the component (as PagingNavigation allows) -- View this message in context: http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16912100.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]
Re: Alternative method to initialise page
On Sat, Apr 26, 2008 at 04:46:11AM -0700, John Patterson wrote:
John Krasnay wrote:
This rule is too strict. Another way to avoid calling overridable
methods from the constructor is to use a model:
Models are fine for providing dynamic values but do not help you customise
components by extension. For example, to provide a different type of link
to use in the component (as PagingNavigation allows)
Sure, but your rule said Call all overridable methods from
onBeforeRender(), and I gave you a working counterexample that has
nothing to do with onBeforeRender.
The rule should really be Avoid calling overridable methods from the
constructor. onBeforeRender is a good strategy to use when you need
information from your subclass to *construct* a sub-component (e.g.
...to provide a different type of link...), but it's really overkill
if you simply need a value that comes from the subclass, e.g. as a label
value.
Since you've volunteered to write up a wiki page :-) here's another
pattern I use quite a bit: providing overridable methods in the panel to
turn on and off elements within the panel:
BAD:
public class MyPanel extends Panel {
public MyPanel(String id) {
super(id);
add(new Label(name, ...).setVisible(isNameVisible()));
}
public boolean isNameVislble() {
return true;
}
}
GOOD:
public class MyPanel extends Panel {
public MyPanel(String id) {
super(id);
add(new Label(name, ...) {
public boolean isVisible() {
return isNameVisible();
}
}
}
public boolean isNameVislble() {
return true;
}
}
jk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative method to initialise page
John Patterson schrieb: Thanks. So is this the way we should build all components that could be extended? If so, how about adding an initialisation hook to avoid this problem and the need to call super.onBeforeRender() (which I forgot recently and took me a while to find)... and also to give it a more intuitive name like initialise() thats exactly what i thought a while ago. is there any good reason not to do that? cu uwe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative method to initialise page
On Sat, Apr 26, 2008 at 4:17 AM, John Patterson [EMAIL PROTECTED] wrote:
Sorry, I did find a discussion which was related [1] which ended with Igor
saying:
yes, but its also easy to fix. Just don't call any overridible methods
inside constructors. And for everything else there is onbeforerender()
this has come up more then a few times since we discussed it last, and
i am willing to change my mind on this. I am willing to add an
onInitialize() or onFirstRender() callback to Component. my big worry
is that it will be severly abused by our users.
so for example instead of just
class mypanel extends panel {
public mypanel(string id, string foo) {
super(id);
add(new label(l, foo);
}
}
some users will start doing
class mypanel extends panel {
private String foo;
public mypanel(string id, string foo) {
super(id);
this.foo=foo;
}
protected void onInitialize() {
add(new label(l, foo);
}
}
makes the code much uglier with plenty more room for abuse. what do
others think?
-igor
[1]
http://www.nabble.com/Re%3A-Jira-issue-moved-to-the-list%3A-constructors-and-init-of-components-p13569575.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative method to initialise page
We shouldnt call it onInitialize, onFirstRender is fine, onInitialize
looks like a really after constructor call to me, but it is called
much later, if it is called (onvisible checks and so on)
On 4/26/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
On Sat, Apr 26, 2008 at 4:17 AM, John Patterson [EMAIL PROTECTED] wrote:
Sorry, I did find a discussion which was related [1] which ended with
Igor
saying:
yes, but its also easy to fix. Just don't call any overridible methods
inside constructors. And for everything else there is onbeforerender()
this has come up more then a few times since we discussed it last, and
i am willing to change my mind on this. I am willing to add an
onInitialize() or onFirstRender() callback to Component. my big worry
is that it will be severly abused by our users.
so for example instead of just
class mypanel extends panel {
public mypanel(string id, string foo) {
super(id);
add(new label(l, foo);
}
}
some users will start doing
class mypanel extends panel {
private String foo;
public mypanel(string id, string foo) {
super(id);
this.foo=foo;
}
protected void onInitialize() {
add(new label(l, foo);
}
}
makes the code much uglier with plenty more room for abuse. what do
others think?
-igor
[1]
http://www.nabble.com/Re%3A-Jira-issue-moved-to-the-list%3A-constructors-and-init-of-components-p13569575.html
-
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]
Re: Alternative method to initialise page
onBeforeFirstRender() ? , onFirstRender() is ambiguous with its
relation to onbeforerender()
-igor
On Sat, Apr 26, 2008 at 9:35 AM, Johan Compagner [EMAIL PROTECTED] wrote:
We shouldnt call it onInitialize, onFirstRender is fine, onInitialize
looks like a really after constructor call to me, but it is called
much later, if it is called (onvisible checks and so on)
On 4/26/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
On Sat, Apr 26, 2008 at 4:17 AM, John Patterson [EMAIL PROTECTED] wrote:
Sorry, I did find a discussion which was related [1] which ended with
Igor
saying:
yes, but its also easy to fix. Just don't call any overridible methods
inside constructors. And for everything else there is onbeforerender()
this has come up more then a few times since we discussed it last, and
i am willing to change my mind on this. I am willing to add an
onInitialize() or onFirstRender() callback to Component. my big worry
is that it will be severly abused by our users.
so for example instead of just
class mypanel extends panel {
public mypanel(string id, string foo) {
super(id);
add(new label(l, foo);
}
}
some users will start doing
class mypanel extends panel {
private String foo;
public mypanel(string id, string foo) {
super(id);
this.foo=foo;
}
protected void onInitialize() {
add(new label(l, foo);
}
}
makes the code much uglier with plenty more room for abuse. what do
others think?
-igor
[1]
http://www.nabble.com/Re%3A-Jira-issue-moved-to-the-list%3A-constructors-and-init-of-components-p13569575.html
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative method to initialise page
John Krasnay wrote: Sure, but your rule said Call all overridable methods from onBeforeRender(), and I gave you a working counterexample that has nothing to do with onBeforeRender. The counter example was the exact mistake that is very easy to make when designing a component that can be extended. So easy to make that even the mighty super genius Igor initially did it in PagingNavigation. So most mere mortal wicketeers could not be expected to understand this intricacy. Your assumption is that the subclass can return its result without access to parameters passed into the constructor. Even getTitle() may need to access a domain object passed on creation. Igor Vaynberg wrote: onBeforeFirstRender() ? , onFirstRender() is ambiguous with its relation to onbeforerender() Does it need to be defined relative to onBeforeRender()? Isn't it enough to say onBeforeFirstRender() or onPageSetup() is called only once and before rendering. -- View this message in context: http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16916018.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]
Re: Alternative method to initialise page
But as Johan has already pointed out. onBeforeFirstRender (or whatever it is called) might not be called at all if the component is not (allowed to be) rendered. This is probably going to confuse people just as much as the current situation. And if we have an initialize method which should be called always after all sub component constructors have been called, then when do we trigger it and how will people abuse this? Such an initialize method can easily be done by users them self with a simple factory pattern. So why bloat our api with it? Maurice On Sat, Apr 26, 2008 at 8:28 PM, John Patterson [EMAIL PROTECTED] wrote: John Krasnay wrote: Sure, but your rule said Call all overridable methods from onBeforeRender(), and I gave you a working counterexample that has nothing to do with onBeforeRender. The counter example was the exact mistake that is very easy to make when designing a component that can be extended. So easy to make that even the mighty super genius Igor initially did it in PagingNavigation. So most mere mortal wicketeers could not be expected to understand this intricacy. Your assumption is that the subclass can return its result without access to parameters passed into the constructor. Even getTitle() may need to access a domain object passed on creation. Igor Vaynberg wrote: onBeforeFirstRender() ? , onFirstRender() is ambiguous with its relation to onbeforerender() Does it need to be defined relative to onBeforeRender()? Isn't it enough to say onBeforeFirstRender() or onPageSetup() is called only once and before rendering. -- View this message in context: http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16916018.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]
Re: Alternative method to initialise page
John Patterson wrote: The counter example was the exact mistake that is very easy to make when designing a component that can be extended. So easy to make that even the mighty super genius Igor initially did it in PagingNavigation. So most mere mortal wicketeers could not be expected to understand this intricacy. Your assumption is that the subclass can return its result without access to parameters passed into the constructor. Even getTitle() may need to access a domain object passed on creation. Sorry, my smug reply was wrong and you were right. So that first rule should be: never call an overridable method form the constructor; your example is not calling the overridible method from the constructor... it simply provides a class that can do so later (from render). Exactly as Igor said earlier. Note to self: don't post messages when half cut. But I have to break that rule just one more time -- View this message in context: http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16917444.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]
Re: Alternative method to initialise page
Mr Mean wrote: But as Johan has already pointed out. onBeforeFirstRender (or whatever it is called) might not be called at all if the component is not (allowed to be) rendered. This is probably going to confuse people just as much as the current situation. And if we have an initialize method which should be called always after all sub component constructors have been called, then when do we trigger it and how will people abuse this? Such an initialize method can easily be done by users them self with a simple factory pattern. So why bloat our api with it? What is confusing about the component not being rendered if it is not visible? That is already the case with onBeforeRender(). How is this any more confusing? -- View this message in context: http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16917466.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]
Re: Alternative method to initialise page
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? 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. Would others agree that it is fairly common to allow subclasses to override some components? Or is this a corner case in wicket development? 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 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 onXX() 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. 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]
Re: Alternative method to initialise page
John Patterson wrote:
Hi,
I am extending the PagingNavigatation and need to access some member
variables to create my page links. Because these links are created in
PagingNavigatation's constructor me subclasses newPagingNavigationLink()
method is called before my subclasses member variables are initialised. I
realised that this situation must occur quite often when extending any
class that allows subclasses to provide or override any components.
Does anyone have a nice workaround?
It seems to me that creating the pages component tree in some kind of
initialisation step would make classes easier to extend. Or is there
already a method that should be used to do this?
Thanks,
John
Just to be a bit clearer
class MySubclass extends WicketBaseclass
{
MyDomainObject _parameter;
MySubclass(String id, MyDomainObject parameter)
{
super(id);
_parameter = parameter;
}
@Override
protected Component overrideToCreateCustomComponent()
{
return new MyCustomisedCompopnent(_parameter.getSomething());
}
}
So _parameter will always be null when overrideToCreateCustomComponent() is
called from the base class
--
View this message in context:
http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16742891.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]
Re: Alternative method to initialise page
PaginNavigation is not setup properly for extending, we are aware of
this and probably will fix it in wicket 1.5. in the meantime you could
try and copy paste the classes into your own project and then modify
them.
Maurice
On Thu, Apr 17, 2008 at 12:14 PM, John Patterson [EMAIL PROTECTED] wrote:
John Patterson wrote:
Hi,
I am extending the PagingNavigatation and need to access some member
variables to create my page links. Because these links are created in
PagingNavigatation's constructor me subclasses newPagingNavigationLink()
method is called before my subclasses member variables are initialised. I
realised that this situation must occur quite often when extending any
class that allows subclasses to provide or override any components.
Does anyone have a nice workaround?
It seems to me that creating the pages component tree in some kind of
initialisation step would make classes easier to extend. Or is there
already a method that should be used to do this?
Thanks,
John
Just to be a bit clearer
class MySubclass extends WicketBaseclass
{
MyDomainObject _parameter;
MySubclass(String id, MyDomainObject parameter)
{
super(id);
_parameter = parameter;
}
@Override
protected Component overrideToCreateCustomComponent()
{
return new MyCustomisedCompopnent(_parameter.getSomething());
}
}
So _parameter will always be null when overrideToCreateCustomComponent() is
called from the base class
--
View this message in context:
http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16742891.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]
Re: Alternative method to initialise page
fixed in trunk for 1.4, i will fix in 1.3.x later today when i can get
to my desktop.
https://issues.apache.org/jira/browse/WICKET-1548
-igor
On Thu, Apr 17, 2008 at 3:54 AM, Maurice Marrink [EMAIL PROTECTED] wrote:
PaginNavigation is not setup properly for extending, we are aware of
this and probably will fix it in wicket 1.5. in the meantime you could
try and copy paste the classes into your own project and then modify
them.
Maurice
On Thu, Apr 17, 2008 at 12:14 PM, John Patterson [EMAIL PROTECTED] wrote:
John Patterson wrote:
Hi,
I am extending the PagingNavigatation and need to access some member
variables to create my page links. Because these links are created in
PagingNavigatation's constructor me subclasses newPagingNavigationLink()
method is called before my subclasses member variables are initialised.
I
realised that this situation must occur quite often when extending any
class that allows subclasses to provide or override any components.
Does anyone have a nice workaround?
It seems to me that creating the pages component tree in some kind of
initialisation step would make classes easier to extend. Or is there
already a method that should be used to do this?
Thanks,
John
Just to be a bit clearer
class MySubclass extends WicketBaseclass
{
MyDomainObject _parameter;
MySubclass(String id, MyDomainObject parameter)
{
super(id);
_parameter = parameter;
}
@Override
protected Component overrideToCreateCustomComponent()
{
return new MyCustomisedCompopnent(_parameter.getSomething());
}
}
So _parameter will always be null when overrideToCreateCustomComponent()
is
called from the base class
--
View this message in context:
http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16742891.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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
