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
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
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
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 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
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
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 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]
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
On Tue, Apr 29, 2008 at 2:44 PM, John Patterson <[EMAIL PROTECTED]> wrote:
>
> I think the key point is - if extending components by overriding methods is a
> supported (and encouraged) pattern in wicket there should be a *standard*
> way to do it. Sure it is possible for each user to hack a unique solution
> but this provides no common ground when people run into issues.
>
> If every user implements it in their own way (or ignores the problem -
> which, as we have seen, limits extensibility) then it will be harder to
> support and the learning curve will be steeper. One documented, supported
> approach makes sense.
Who wouldn't agree with this ;)
>
> In my opinion, component extension by overriding methods is very powerful
> and should be made as simple as possible.
>
>
>
> Mr Mean wrote:
> >
> >> > Such an initialize method can easily be done by users them self with a
> >> > simple factory pattern.
> >> >
> >>
> >> Can you give an example of this?
> >
> > public class MyFactory
> > {
> > public SomeComponent getComponent(String id,someParams)
> > {
> > SomeComponent c=new MyCustomComponent(id,someParams);
> > c.init();
> > return c;
> > }
> > }
> >
> > public class MyPage extends webPage
> > {
> > public MyPage()
> > {
> > add(factory.getComponent("id",foo);
> > }
> > }
> >
> >
>
> What a huge amount of bloat to simply give the *option* to customise
> components.
Exactly what i have been saying. Overridable methods was already
mentioned i simply mentioned an alternative that also had come up in
earlier posts.
> Overridable methods area much more obvious way to make a
> component extendible and require less effort from the developer. I imagine
> that is why none of the core wicket components use such component factories.
> And, be honest... have you used this pattern in a real component?
No, i use an init method to attach overridable subcomponents. all
subclasses have to trigger the init method themself in there
constructor. It is not perfect but works for me.
>
>
>
>
> Mr Mean wrote:
> >
> >> Building such extendable components seems to be a core feature of wicket
> >> and
> >> one of its major selling points. I have unwittingly built many
> >> components
> >> that suffer from this problem already and I imagine it is a fairly
> >> common
> >> situation. It only becomes obvious when your subclass needs to access
> >> constructor parameters that your component acts in bizarre ways when
> >> extended. Now that is confusing.
> >
> > I fully agree with you, however this is not a wicket limitation but
> > something that cannot be done as expected in the java language. That
> > is why people have to resort to using things like initialize methods
> > or factory patterns.
> >
>
> Java constructors work as expected. When users "have to resort to using
> things like initiialize methods" they should be helped by the framework to
> do it consistently.
>
>
>
> Mr Mean wrote:
> >
> > So while this is a problem
> > that a significant amount of user could encounter at one time or
> > another, forcing everyone to use factories for components like labels
> > just to avoid problems with more complex components is not a good
> > idea. that is what i meant with api bloat.
> >
>
> As Igor said at the beginning of this discussion, it is preferable to use
> the constructor for most cases. So no one will be "forced" to use
> factories - but if you want to provide overridable factory methods there is
> a simple recommended way to do it.
>
>
>
> Mr Mean wrote:
> >
> >> Is this issue even documented yet? I will create a page for it but
> >> waiting
> >> until this discussion closes
> >>
> > Well this particular issue has been around on the mailing list a few
> > times, so in a way it is self documented ;)
> > I honestly have not looked if there is wiki page for this or if it is
> > mentioned in the api doc.
> >
>
> Is this feature of wicket useful? Damn yes. So it should be paraded about
> and
>
>
>
> Mr Mean wrote:
> >
> > But you have to be careful that the solution does not introduce other
> > problems or more work for the more standard usecases or anti-patterns.
> >
>
> Exactly why each use should not be left wondering how to approach
Re: Alternative method to initialise page
t; > 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]
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 i
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
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
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
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: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
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 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
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
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
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
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 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
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 Map initializersMap = new
> HashMap();
>
>
> //**
> // IComponentInstantiationListener Implementation
>
> //**
>
>
> public void onInstantiation( Component component )
> {
> Initializer initializer = getInitializer(component);
> initializer.initialize(component);
> }
>
> private synchronized Initializer getInitializer( Component component )
> {
> final Class componentClass =
> component.getClass();
> Initializer initializer = initializersMap.get(componentClass);
> if( initializer == null )
> {
> final List initializationMethods =
> getInitializationMethods(component);
> initializer = createInitializer(componentClass,
> initializationMethods);
> initializersMap.put(componentClass, initializer);
> }
> return initializer;
> }
>
>
> //**
> // Other Methods
>
> //**
>
> private synchronized List getInitializationMethods(
> Component component )
> {
> List initializationMethods = new LinkedList();
> 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 )
> {
> Set initializers = new HashSet();
> 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,
> List initializat
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 Map initializersMap = new
HashMap();
//**
// IComponentInstantiationListener Implementation
//**
public void onInstantiation( Component component )
{
Initializer initializer = getInitializer(component);
initializer.initialize(component);
}
private synchronized Initializer getInitializer( Component component )
{
final Class componentClass = component.getClass();
Initializer initializer = initializersMap.get(componentClass);
if( initializer == null )
{
final List initializationMethods =
getInitializationMethods(component);
initializer = createInitializer(componentClass,
initializationMethods);
initializersMap.put(componentClass, initializer);
}
return initializer;
}
//**
// Other Methods
//**
private synchronized List getInitializationMethods(
Component component )
{
List initializationMethods = new LinkedList();
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 )
{
Set initializers = new HashSet();
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,
List initializationMethods )
{
return initializationMethods.isEmpty() ? new NullInitializer()
: new ReflectionInitializer(initializationMethods);
}
//**
// Inner Classes
//**
protected static interface Initializer
{
public void initialize( Component component );
}
protected static class NullInitializer implements Initializ
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 > 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? - 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 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
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 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 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
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. S&S -- 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 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
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
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 ;) 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. Maurice On Sat, Apr 26, 2008 at 11:02 PM, John Patterson <[EMAIL PROTECTED]> wrote: > > > > 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] > > - 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
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
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 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
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
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
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
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 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 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:17:35AM -0700, John Patterson 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()"
>
> 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()
This rule is too strict. Another way to avoid calling overridable
methods from the constructor is to use a model:
public abstract void BaseComponent extends Panel {
protected abstract String getTitle();
public BaseComponent(String id) {
super(id);
add(new Label("title", new AbstractReadOnlyModel() {
public Object getObject() {
return getTitle();
}
});
}
}
This works because getObject() is not called until after the panel is
constructed (at render time, I believe).
jk
> 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]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
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()
> >> >> > {
> >> >>
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.
>> >> >
>> >> >
>> >> >
>>
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
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
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]
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
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]
Alternative method to initialise page
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 -- View this message in context: http://www.nabble.com/Alternative-method-to-initialise-page-tp16742636p16742636.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]
