Hi,
i think we should finally define onDetach() contract and decide what
to do with detachModels().
Right now, after the detach attach/refactor the situation is that
onDetach is called only for components which were attached and
detachModels is called for every component.
While this kinda does
On 3/26/07, Matej Knopp [EMAIL PROTECTED] wrote:
The onDetach sematics would be defined something like this:
The method is called on the end of request, even if the component was
not attached.
The detach methods are usually rather simple, so I really don't think
there would be a big performance
This is no longer true. All request targets that deal with page call
page.detach, and the page is detached before serialization, even
during ajax requests.
Trigerring detachment of serialization is imho not a very good idea,
as it wouldn't work for httpsessionstore. And right now, it's not even
as far as i see it does already what i expect it todo:
if (getFlag(FLAG_ATTACHED))
{
// if the component has been previously attached via attach()
// detach it now
setFlag(FLAG_DETACHING, true);
onDetach();
if
On 3/26/07, Matej Knopp [EMAIL PROTECTED] wrote:
and you clean myModel in onDetach, that won't work. I'm not sure how
rare this is and if you assign mymodel to a component it will be
detached anyway, but there is the possibility.
In our application it is not rare :-)
Martijn
--
Learn Wicket
detachModels is not final.
So if you want to detach a model that be done in detachmodels...
The only other solution is that onDetach is always called (but then also
twice if there are multiply request targets on the stack with the same page)
But The biggest problem is attach itself. That should
IIRC the behavior used to be like that. But then someone decided that
it is too fragile if you put your component into a repeater...
-Matej
On 3/26/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
The current implementation of getMarkupId() is pretty dumb. It doesn't
check if the user already has
if we don't care (there where people complaining about double detach calls..
(i think martijn itself was one))
then we can drop the if(ATTACHED) completely and just do everything in one
method
johan
On 3/26/07, Matej Knopp [EMAIL PROTECTED] wrote:
I don't see as a problem that onDetach would
On 3/26/07, Matej Knopp [EMAIL PROTECTED] wrote:
IIRC the behavior used to be like that. But then someone decided that
it is too fragile if you put your component into a repeater...
But that is the choice of the user, not the framework. Now you make it
completely impossible to write stable
Well, I do agree with you on this one. I wonder if there was other
reason for why it is like it is right now. IIRC there was something
with markup parsing but i'm not sure.
-Matej
On 3/26/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 3/26/07, Matej Knopp [EMAIL PROTECTED] wrote:
IIRC the
I found one discussion:
http://mail-archives.apache.org/mod_mbox/incubator-wicket-dev/200610.mbox/[EMAIL
PROTECTED]
Martijn
On 3/26/07, Matej Knopp [EMAIL PROTECTED] wrote:
Well, I do agree with you on this one. I wonder if there was other
reason for why it is like it is right now. IIRC
Well, I would generaly not put navigation logic to form's onSubmit. I
always use button's onSubmit for things like that. I actually use
Form.onSubmit rather rarely.
But i didn't vote -1 for this.
-Matej
On 3/26/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i find that funny coming from you
I also found the commit that disabled the getAttributes().getId()
check, it is from 2/13/06. But I fail to see a discussion on @dev
relating to this.
Martijn
On 3/26/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
I found one discussion:
I can see the reasons where the problems stem with repeaters, and that
is a valid usecase. However, not all components are created inside
repeaters, and writing javascript for a particular page is a common
usecase as well. We need to find some middle ground here.
The problem I have is that the
On 3/26/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 3/26/07, Matej Knopp [EMAIL PROTECTED] wrote:
I really don't understand what's the big deal here.
The big deal is that there is a big discussion, and suddenly the
change is committed. Don't we have a process for changes that are
Why cant you work with static id's when you do override getMarkupId?
If you do that and then return:
return getMarkupAttributes().get(id)
then that should work fine
johan
On 3/26/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
I can see the reasons where the problems stem with repeaters,
On 3/26/07, Johan Compagner [EMAIL PROTECTED] wrote:
Why cant you work with static id's when you do override getMarkupId?
If you do that and then return:
return getMarkupAttributes().get(id)
then that should work fine
Then I have to create custom components for all components where I
attach
Was it 2.0 only?
Eelco
On 3/26/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
This surprises me too. I would have sworn we supported that, and it
strikes me as a very useful feature.
Eelco
On 3/26/07, Matej Knopp [EMAIL PROTECTED] wrote:
Well, I do agree with you on this one. I wonder if
same here
-igor
On 3/26/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 3/26/07, Matej Knopp [EMAIL PROTECTED] wrote:
and you clean myModel in onDetach, that won't work. I'm not sure how
rare this is and if you assign mymodel to a component it will be
detached anyway, but there is the
gwyn, you cannot vote -1 without giving a reason
-igor
On 3/25/07, Gwyn Evans [EMAIL PROTECTED] wrote:
Adding a setting:+0 Reversing the present order:-1
/Gwyn
On 25/03/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
For me the argument still remains: you break a lot of stuff in a
silent
we have reached a consensus in the discussion thread and it went quiet so i
assumed no one else had anything to say.
like i said the controversy was over the fact that it would do too much
magic/be automatic and that is why i closed the original jira issue as wont
fix. right now it is completely
On 3/26/07, Matej Knopp [EMAIL PROTECTED] wrote:
Yeah, that's my opinion too. I don't care about duplicate onDetach
calls, and that will only happen if there are multiple request targets
on stack with same page which should be rather rare.
Duplicate detaches are not something to worry about,
agreed
next time :)
-igor
On 3/26/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 3/26/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
we have reached a consensus in the discussion thread and it went quiet
so i
assumed no one else had anything to say.
like i said the controversy was over
Duplicate detaches are not something to worry about, imo too, but they
look stupid. If they can be prevented, then all the better.
We could hold a temp hash set with the detached components so far and
check against that, but that wouldn't say a thing about how the
detaches cascade to
OK,
I just want to add a thank you towards Vincent and Frédéric for
staying with us in this (semi) heated discussion.
Martijn
On 3/26/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
agreed
next time :)
-igor
On 3/26/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 3/26/07, Igor Vaynberg
Sorry, I thought it would be clear from the thread, but just for the
record, I'm -1 on this because my recollection is that we have in the
past documented the ordering involved and given that, I don't believe
we should change it in such a way that there's a likelihood that the
change would be
Ok +1 on releasing to IPMC.
I don't expect them to just eat it without comments. I guess the biggest
point will be the license header aspect. I would therefor appreciate if we
could agree on what I have wrote in the wiki[1] or else reach consensus on
what our opinion is on this.
Frank
[1]:
* Martijn Dashorst:
I just want to add a thank you towards Vincent and Frédéric for
staying with us in this (semi) heated discussion.
Indeed they are valiant and bold, I have fun working with them.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
On 3/26/07, Martijn Dashorst [EMAIL PROTECTED] wrote
[x] yes submit apache-wicket-1.3.0-incubating-alpha to the IPMC for
ratification
[ ] no, don't submit apache-wicket-1.3.0-incubating-alpha to the IPMC
Frank (binding)
i thought we were not shipping a bug free release. this is just a
development snapshot that we are shipping for legal purposes.
so while WICKET-424 may hold water ?, i dont think 422 or 423 do
-igor
On 3/26/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
FWIW corresponding issues are:
* Igor Vaynberg:
i thought we were not shipping a bug free release. this is
just a development snapshot that we are shipping for legal
purposes.
so while WICKET-424 may hold water ?, i dont think 422 or 423 do
Sure, WICKET-424 is a showstopper but not the others.
--
I commented on this in 2.0, and it was fixed to support hardcoding ids:
http://www.nabble.com/HTML-ids-in-2.0-SNAPHOT-are-being-generated-even-when-hardcoded-t2805481.html
It certainly makes life easier to allow hardcoding ids.
On 3/26/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Was it 2.0
32 matches
Mail list logo
