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
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
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
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
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
Sorry, type given to meta data key should be Boolean, not
IBeforeFirstRenderListener.
On Tue, Apr 29, 2008 at 8:55 AM, James Carman
[EMAIL PROTECTED] wrote:
Would you like me to add something like this to the wiki?
// The interface...
public interface IBeforeFirstRenderListener
{
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
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
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
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:
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.
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
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
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
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
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
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
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,
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
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
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
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,
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
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
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]:
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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:
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
50 matches
Mail list logo
