This is a slippery slope and can easily become an excuse to do
whatever it is that one wants an excuse to do. It's impossible to
argue against supposed silent, anonymous individuals. They may
think anything or have any problem whatsoever... whatever suits
the argument at hand.
I think we're
> 1.2.6
>
> we no longer need bodycontainer in 1.3 because we have a much more
elegant
> system for handling such things
Are you saying that overriding getVariation on a page will work properly
in 1.3 already?
>
> -igor
Separate threat but kind of related:
>> Apparently the usecase is prett
1.2.6
we no longer need bodycontainer in 1.3 because we have a much more elegant
system for handling such things
-igor
On 3/31/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> > > Java objects construct the way that they do and we use Java object
> > > constructors because we like that simplici
> > > Java objects construct the way that they do and we use Java object
> > > constructors because we like that simplicity. Your bug is
reported
> > and
> > > will be fixed.
> >
> > Any time schedule for that?
>
>
> the fix is in svn
>
> -igor
Excellent news! What will be the first public rel
On 3/30/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> Java objects construct the way that they do and we use Java object
> constructors because we like that simplicity. Your bug is reported
and
> will be fixed.
Any time schedule for that?
the fix is in svn
-igor
---
> Okay, here's my opinion:
>
> People have been using Wicket for years now and this is the first bug
> of this type I have heard of. I am very reluctant attempt any sort of
> generic framework-level "fix" to the semantics of Java object
construction
> (regardless of how anyone feels about the pra
On 3/30/07, Chris Colman <[EMAIL PROTECTED]> wrote:
2. Users still have to remember to call super.onAttach in their
overridden handlers though this could be rectified by creating a new
method internalOnAttach that only the framework calls:
heh, weve been down this road and i just finally remo
> can you show us your code?
> ...
> ah, sorry. this is the code i take it. just not in response to my
> original post (at least on nabble).
There is possibly an even simpler solution using onAttach - overriding
it in WebPage:
onAttach()
{
commonInit();
init();
}
public void init()
{
Okay, here's my opinion:
People have been using Wicket for years now and this is the first bug
of this type I have heard of. I am very reluctant attempt any sort of
generic framework-level "fix" to the semantics of Java object construction
(regardless of how anyone feels about the practices def
ah, sorry. this is the code i take it. just not in response to my original
post (at least on nabble).
Chris Colman wrote:
>
>> i'm not sure what i think about this yet. can you show us the
>> exact code modifications and use cases you have coded up?
>> (boiled down to the important parts, i
can you show us your code?
Chris Colman wrote:
>
>> there is a reason why some of the stuff is done where it is. now,
>
> I believe that with the minor change that I have made everything is
> still being done in the exact same order so there should be no
> consequences of this change. It's ju
On 3/28/07, Chris Colman <[EMAIL PROTECTED]> wrote:
Easy if you deal with the parameters in the constructor and deal with
adding children, accessing markup etc., in the overridden init (or
commonInit) method.
In cases where people have a number of constructors they normally create
their own se
> the fact remains that getvariation() call from webpage constructor is
a
> bug we need to fix.
Yeah, that's my numero uno motivation at this point also.
> further we already have listener methods you can use - onattach and
> ondetach
>
> what you want can be just as easily accomplished on every
the fact remains that getvariation() call from webpage constructor is a bug
we need to fix.
further we already have listener methods you can use - onattach and ondetach
what you want can be just as easily accomplished on every component
class mypage extends webpage {
private boolean initted=fa
> > I believe that with the minor change that I have made everything is
> > still being done in the exact same order so there should be no
> > consequences of this change. It's just that all the stuff done in
> > commonInit is now being slightly deferred so that it uses completely
> > constructed o
On 3/28/07, Chris Colman <[EMAIL PROTECTED]> wrote:
i am against this because i do not think the value it brings is worth the
complexity it adds.
you can persuade me by coming up with examples that actually demonstrate the
advantage. it is common practice in wicket to use imodel to deffer lookup
> i'm not sure what i think about this yet. can you show us the
> exact code modifications and use cases you have coded up?
> (boiled down to the important parts, if possible)
Ok, here's the changed bits you requested. Only 3 Java classes need
minor changes in the framework:
[I added the deferr
i'm not sure what i think about this yet. can you show us the
exact code modifications and use cases you have coded up?
(boiled down to the important parts, if possible) also, it would
be good if you could explain how this solves any problems
other than getVariation().
Chris Colman wrote:
>
https://issues.apache.org/jira/browse/WICKET-432
-igor
On 3/28/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
On 3/28/07, Chris Colman <[EMAIL PROTECTED]> wrote:
>
> > there is a reason why some of the stuff is done where it is. now,
>
> I believe that with the minor change that I have made eve
On 3/28/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> there is a reason why some of the stuff is done where it is. now,
I believe that with the minor change that I have made everything is
still being done in the exact same order so there should be no
consequences of this change. It's just that
> there is a reason why some of the stuff is done where it is. now,
I believe that with the minor change that I have made everything is
still being done in the exact same order so there should be no
consequences of this change. It's just that all the stuff done in
commonInit is now being slightly
there is a reason why some of the stuff is done where it is. now, im not
sure there is a reason for the markup loading for bodcontainer, we might be
able to do that lazily when getbodycontainer() is called.
juergen are you reading with us?
-igor
On 3/27/07, Chris Colman <[EMAIL PROTECTED]> wro
I went ahead and implemented these changes in my copy of the wicket
source code and now I can specify a variation at the Page level (never
been able to do that before!) without causing a NPE. It works very
nicely indeed.
> what about pages that are constructed with the new operator?
I mainly use
what about pages that are constructed with the new operator? the users then
have to explicitly call commoninit() from their constructors? i think that
is horrible. what we need to do is somehow delay the getvariation() until
render time.
-igor
On 3/27/07, Chris Colman <[EMAIL PROTECTED]> wrote:
Just looking at the source code for WebPage it looks like a very minor
change to achieve a more flexible lifecycle initialization phase.
All the WebPage constructors call
private void commonInit()
As you will no doubt understand this is being called before
construction/instantiation has
I have a constructor that takes parameters and then uses the parameters
to set up a variable that is used in getVariation().
There appears to be a lifecycle issue here because getVariation is being
called from within a base class constructor - before my constructor's
code below the super(parameter
26 matches
Mail list logo
