You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Igor Vaynberg <ig...@gmail.com> on 2007/01/22 22:47:48 UTC
VOTE: remove Page.before/afterCallComponent()
this api is simply too fragile. any custom requesttarget impl has to call
this in order for it to be consistent, and if its not consistent its
useless.
the only usecase i could come up with for this is the one we use in
teachscape where we setup some threadlocals kept with page in this method so
they can be accessed by component constructors - the need for this is
eliminated by the parent refactor.
-igor
Re: VOTE: remove Page.before/afterCallComponent()
Posted by Eelco Hillenius <ee...@gmail.com>.
+1
Eelco
On 1/22/07, Igor Vaynberg <ig...@gmail.com> wrote:
> +1
>
> -igor
>
>
> On 1/22/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > this api is simply too fragile. any custom requesttarget impl has to call
> > this in order for it to be consistent, and if its not consistent its
> > useless.
> >
> > the only usecase i could come up with for this is the one we use in
> > teachscape where we setup some threadlocals kept with page in this method so
> > they can be accessed by component constructors - the need for this is
> > eliminated by the parent refactor.
> >
> > -igor
> >
> >
>
>
Re: VOTE: remove Page.before/afterCallComponent()
Posted by Igor Vaynberg <ig...@gmail.com>.
_if_ there is a valid security usecase it should be integrated into our
IAuthStrat, not be spread into the page
i will post to the user and ask if anyone is using it.
-igor
On 1/22/07, Johan Compagner <jc...@gmail.com> wrote:
>
> i thought people where using this, i don't know anymore about what i
> didn't
> use it
> But was it for security or something?
>
> On 1/22/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > +1
> >
> > -igor
> >
> >
> > On 1/22/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > >
> > > this api is simply too fragile. any custom requesttarget impl has to
> > call
> > > this in order for it to be consistent, and if its not consistent its
> > > useless.
> > >
> > > the only usecase i could come up with for this is the one we use in
> > > teachscape where we setup some threadlocals kept with page in this
> > method so
> > > they can be accessed by component constructors - the need for this is
> > > eliminated by the parent refactor.
> > >
> > > -igor
> > >
> > >
> >
> >
>
>
Re: VOTE: remove Page.before/afterCallComponent()
Posted by Eelco Hillenius <ee...@gmail.com>.
The idea behind it isn't bad, but if it isn't used much and is fragile
and we there are alternative ways of achieving (kind of) the same
thing, I'm +1 with simplifying and thus removing.
Eelco
On 1/22/07, Johan Compagner <jc...@gmail.com> wrote:
> i thought people where using this, i don't know anymore about what i didn't
> use it
> But was it for security or something?
>
> On 1/22/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > +1
> >
> > -igor
> >
> >
> > On 1/22/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > >
> > > this api is simply too fragile. any custom requesttarget impl has to
> > call
> > > this in order for it to be consistent, and if its not consistent its
> > > useless.
> > >
> > > the only usecase i could come up with for this is the one we use in
> > > teachscape where we setup some threadlocals kept with page in this
> > method so
> > > they can be accessed by component constructors - the need for this is
> > > eliminated by the parent refactor.
> > >
> > > -igor
> > >
> > >
> >
> >
>
>
Re: VOTE: remove Page.before/afterCallComponent()
Posted by Johan Compagner <jc...@gmail.com>.
i thought people where using this, i don't know anymore about what i didn't
use it
But was it for security or something?
On 1/22/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> +1
>
> -igor
>
>
> On 1/22/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > this api is simply too fragile. any custom requesttarget impl has to
> call
> > this in order for it to be consistent, and if its not consistent its
> > useless.
> >
> > the only usecase i could come up with for this is the one we use in
> > teachscape where we setup some threadlocals kept with page in this
> method so
> > they can be accessed by component constructors - the need for this is
> > eliminated by the parent refactor.
> >
> > -igor
> >
> >
>
>
Re: VOTE: remove Page.before/afterCallComponent()
Posted by Igor Vaynberg <ig...@gmail.com>.
+1
-igor
On 1/22/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> this api is simply too fragile. any custom requesttarget impl has to call
> this in order for it to be consistent, and if its not consistent its
> useless.
>
> the only usecase i could come up with for this is the one we use in
> teachscape where we setup some threadlocals kept with page in this method so
> they can be accessed by component constructors - the need for this is
> eliminated by the parent refactor.
>
> -igor
>
>
Re: VOTE: remove Page.before/afterCallComponent()
Posted by Al Maw <wi...@almaw.com>.
Frank Bille wrote:
> On 1/22/07, Igor Vaynberg <ig...@gmail.com> wrote:
>>
>> this api is simply too fragile. any custom requesttarget impl has to call
>> this in order for it to be consistent, and if its not consistent its
>> useless.
>>
>
> +1 because of fragile api.
+1
This is currently biting me for AJAX stuff.
Al
Re: VOTE: remove Page.before/afterCallComponent()
Posted by Frank Bille <fr...@gmail.com>.
On 1/22/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> this api is simply too fragile. any custom requesttarget impl has to call
> this in order for it to be consistent, and if its not consistent its
> useless.
>
+1 because of fragile api.