On 6/25/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
I think reasonable behavior would be to generate markup id when
invoked from constructor (instead of failing getting one from markup).
However, I'm affraid the complications you have are caused by the fact
the the component hasn't been rendered a
I think reasonable behavior would be to generate markup id when
invoked from constructor (instead of failing getting one from markup).
However, I'm affraid the complications you have are caused by the fact
the the component hasn't been rendered already, so it doesn't know
it's markup position. At
i can think of one, getMarkupId() can't really be called in the constructor
phase (as we could do in 2.0)
(it now can but then you really have to make sure how you construct your
objects you have to setup the hierachy up until the page as soon as
possible)
Yeah, even now the component has to be
On 6/25/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
What are the side effects?
Jonathan had problems:
http://www.nabble.com/Unable-to-find-the-markup-for-the-component-tf3976741.html
and
the project I'm working on got some exceptions from the test site this
morning as well. For instance:
o
i can think of one, getMarkupId() can't really be called in the constructor
phase (as we could do in 2.0)
(it now can but then you really have to make sure how you construct your
objects you have to setup the hierachy up until the page as soon as
possible)
johan
On 6/25/07, Martijn Dashorst <[E
What are the side effects?
We have been down this road too many times and we keep forgetting them
(or ignoring until we can't bare them) I'd hate to not fix this one
once and for all.
Martijn
--
BREAKING NEWS: Wicket joins the Apache Software Foundation as Apache Wicket
Join the wicket communi
Unfortunately, the fix for
http://issues.apache.org/jira/browse/WICKET-694 had some side effects
I didn't come across when testing :(
It's a bloody shame, but it seems that already too much code assumes
it can call getMarkupId where it shouldn't. I'm leaving the bug open,
but at this time I have
I believe the current behavior is intentional. Igor seemed to feel
quite strongly about not using markup id specified in template. The
reason is that it's not unique and it behaves wrongly in repeaters or
when you put the component to page twice.
I remember having this discussion a very long tim
i dont feel strongly about it anymore. a lot of people seem to want to shoot
themselves in the foot, and i am inclined to let them.
-igor
On 6/24/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
I believe the current behavior is intentional. Igor seemed to feel
quite strongly about not using markup
I believe the current behavior is intentional. Igor seemed to feel
quite strongly about not using markup id specified in template. The
reason is that it's not unique and it behaves wrongly in repeaters or
when you put the component to page twice.
I'd actually prefer wicket to preserve specified a
On 6/24/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
I think everyone ran into it at one time... I know I did. Last time I
think Igor threw some issues with repeaters into the mix, and then the
discussion went dead.
For all I know, it worked in 2.0. I remember testing it specifically.
I'm ju
I think everyone ran into it at one time... I know I did. Last time I
think Igor threw some issues with repeaters into the mix, and then the
discussion went dead.
Martijn
On 6/24/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Yep, you read that right. I just found out that if you explicitly
def
Yep, you read that right. I just found out that if you explicitly
define an id attribute on your component, getMarkupId still just
returns a generated one. This suprises me; I'm pretty sure we always
agreed that if an explicit id is provided in the markup, that should
be used. See the date picker
13 matches
Mail list logo
