Re: Possible bug / edge case found where page is not detached

[Locke, Jonathan (Luo Shibo)]

Now that is a stellar bug report.

From: Bas Gooren 
Sent: Sunday, July 25, 2021 12:06 AM
To: users@wicket.apache.org ; Sven Meier 

Subject: Re: Possible bug / edge case found where page is not detached

Hi Sven,

Done - https://issues.apache.org/jira/browse/WICKET-6908

Met vriendelijke groet,
Kind regards,

Bas Gooren

Op 24 juli 2021 bij 10:29:38, Sven Meier (s...@meiers.net) schreef:

Hi Bas,

that sounds like a bug.

Your quickstart didn't make it through the mailing list, would you please
attach it to a new Jira issue?

Thanks
Sven

Am 23. Juli 2021 19:30:46 MESZ schrieb Bas Gooren :
>Hi all,
>
>Today I spent the better part of my day investigating a bug report
>regarding a hibernate LazyInitializationException.
>Since we use detaching models everywhere and (in general) never see
>such
>issues anymore, this one was interesting :-)
>
>After much debugging I found out what is happening.
>
>We have a page which has a database model + links for prev/next item
>(in
>the database).
>When the users double-clicks on one of the links, the first click is
>OK,
>and the second click throws a StalePageException during request cycle
>processing.
>
>So far, normal.
>
>However, stepping through the wicket code, this is what happens:
>
>1) Resolve to ListenerRequestHandler, execute it, throws
>StalePageException
>2) exception mapper handles this and we execute a
>RenderPageRequestHandler,
>which re-renders the page
>3) the request cycle detaches, which delegates in part
>to RequestHandlerExecutor.detach()
>4) The handlers to detach are both handlers from step 1 and 2; During
>the
>detach of ListenerRequestHandler, it initializes ListenerLogData, which
>(in
>the PageLogData ctor) throws the StalePageException again!
>5) The second handler (RenderPageRequestHandler) is not detached, thus
>all
>models in the page are not detached
>6) The user clicks on a link and boom, the models are all still
>attached
>and there we get the LazyInitializationException
>
>I think that (a) RequestHandlerExecutor.detach() should ensure all
>handlers
>are detached, and (b) that failing to collect LogData should not stop
>the
>detaching of a request handler.
>
>What do you think?
>
>I tried to make the simplest possible Quickstart to demonstrate this.
>
>Weird stuff: on the homepage of the quick start, the page is properly
>detached when a stale link is clicked;
>On another (test) page, the page is not properly detached.
>
>Steps to reproduce:
>
>Run Quickstart
>Click on “Test” link on homepage
>Observe that the following is logged:
>
>Model still attached? false
>Page detaching
>
>Now click on "Click me (stale link)!”
>Now refresh the page (re-render)
>
>Observe that the following is logged:
>
>Model still attached? true
>Page detaching
>
>—> So the page was not detached
>
>These steps don’t have the same result on the homepage. So my guess is
>there is some relation to the fact that we are interacting with a
>stateful,
>non-mounted page.
>
>Met vriendelijke groet,
>Kind regards,
>
>Bas Gooren
[EXTERNAL EMAIL] CAUTION: This email originated from outside of Telenav. DO NOT 
CLICK links or attachments unless you recognize the sender and know the content 
is safe.

Re: Possible bug / edge case found where page is not detached

[Bas Gooren]

Hi Sven,

Done - https://issues.apache.org/jira/browse/WICKET-6908

Met vriendelijke groet,
Kind regards,

Bas Gooren

Op 24 juli 2021 bij 10:29:38, Sven Meier (s...@meiers.net) schreef:

Hi Bas,

that sounds like a bug.

Your quickstart didn't make it through the mailing list, would you please
attach it to a new Jira issue?

Thanks
Sven

Am 23. Juli 2021 19:30:46 MESZ schrieb Bas Gooren :
>Hi all,
>
>Today I spent the better part of my day investigating a bug report
>regarding a hibernate LazyInitializationException.
>Since we use detaching models everywhere and (in general) never see
>such
>issues anymore, this one was interesting :-)
>
>After much debugging I found out what is happening.
>
>We have a page which has a database model + links for prev/next item
>(in
>the database).
>When the users double-clicks on one of the links, the first click is
>OK,
>and the second click throws a StalePageException during request cycle
>processing.
>
>So far, normal.
>
>However, stepping through the wicket code, this is what happens:
>
>1) Resolve to ListenerRequestHandler, execute it, throws
>StalePageException
>2) exception mapper handles this and we execute a
>RenderPageRequestHandler,
>which re-renders the page
>3) the request cycle detaches, which delegates in part
>to RequestHandlerExecutor.detach()
>4) The handlers to detach are both handlers from step 1 and 2; During
>the
>detach of ListenerRequestHandler, it initializes ListenerLogData, which
>(in
>the PageLogData ctor) throws the StalePageException again!
>5) The second handler (RenderPageRequestHandler) is not detached, thus
>all
>models in the page are not detached
>6) The user clicks on a link and boom, the models are all still
>attached
>and there we get the LazyInitializationException
>
>I think that (a) RequestHandlerExecutor.detach() should ensure all
>handlers
>are detached, and (b) that failing to collect LogData should not stop
>the
>detaching of a request handler.
>
>What do you think?
>
>I tried to make the simplest possible Quickstart to demonstrate this.
>
>Weird stuff: on the homepage of the quick start, the page is properly
>detached when a stale link is clicked;
>On another (test) page, the page is not properly detached.
>
>Steps to reproduce:
>
>Run Quickstart
>Click on “Test” link on homepage
>Observe that the following is logged:
>
>Model still attached? false
>Page detaching
>
>Now click on "Click me (stale link)!”
>Now refresh the page (re-render)
>
>Observe that the following is logged:
>
>Model still attached? true
>Page detaching
>
>—> So the page was not detached
>
>These steps don’t have the same result on the homepage. So my guess is
>there is some relation to the fact that we are interacting with a
>stateful,
>non-mounted page.
>
>Met vriendelijke groet,
>Kind regards,
>
>Bas Gooren

Re: Possible bug / edge case found where page is not detached

[Sven Meier]

Hi Bas,

that sounds like a bug.

Your quickstart didn't make it through the mailing list, would you please 
attach it to a new Jira issue?

Thanks
Sven

Am 23. Juli 2021 19:30:46 MESZ schrieb Bas Gooren :
>Hi all,
>
>Today I spent the better part of my day investigating a bug report
>regarding a hibernate LazyInitializationException.
>Since we use detaching models everywhere and (in general) never see
>such
>issues anymore, this one was interesting :-)
>
>After much debugging I found out what is happening.
>
>We have a page which has a database model + links for prev/next item
>(in
>the database).
>When the users double-clicks on one of the links, the first click is
>OK,
>and the second click throws a StalePageException during request cycle
>processing.
>
>So far, normal.
>
>However, stepping through the wicket code, this is what happens:
>
>1) Resolve to ListenerRequestHandler, execute it, throws
>StalePageException
>2) exception mapper handles this and we execute a
>RenderPageRequestHandler,
>which re-renders the page
>3) the request cycle detaches, which delegates in part
>to RequestHandlerExecutor.detach()
>4) The handlers to detach are both handlers from step 1 and 2; During
>the
>detach of ListenerRequestHandler, it initializes ListenerLogData, which
>(in
>the PageLogData ctor) throws the StalePageException again!
>5) The second handler (RenderPageRequestHandler) is not detached, thus
>all
>models in the page are not detached
>6) The user clicks on a link and boom, the models are all still
>attached
>and there we get the LazyInitializationException
>
>I think that (a) RequestHandlerExecutor.detach() should ensure all
>handlers
>are detached, and (b) that failing to collect LogData should not stop
>the
>detaching of a request handler.
>
>What do you think?
>
>I tried to make the simplest possible Quickstart to demonstrate this.
>
>Weird stuff: on the homepage of the quick start, the page is properly
>detached when a stale link is clicked;
>On another (test) page, the page is not properly detached.
>
>Steps to reproduce:
>
>Run Quickstart
>Click on “Test” link on homepage
>Observe that the following is logged:
>
>Model still attached? false
>Page detaching
>
>Now click on "Click me (stale link)!”
>Now refresh the page (re-render)
>
>Observe that the following is logged:
>
>Model still attached? true
>Page detaching
>
>—> So the page was not detached
>
>These steps don’t have the same result on the homepage. So my guess is
>there is some relation to the fact that we are interacting with a
>stateful,
>non-mounted page.
>
>Met vriendelijke groet,
>Kind regards,
>
>Bas Gooren

Possible bug / edge case found where page is not detached

[Bas Gooren]

Hi all,

Today I spent the better part of my day investigating a bug report
regarding a hibernate LazyInitializationException.
Since we use detaching models everywhere and (in general) never see such
issues anymore, this one was interesting :-)

After much debugging I found out what is happening.

We have a page which has a database model + links for prev/next item (in
the database).
When the users double-clicks on one of the links, the first click is OK,
and the second click throws a StalePageException during request cycle
processing.

So far, normal.

However, stepping through the wicket code, this is what happens:

1) Resolve to ListenerRequestHandler, execute it, throws StalePageException
2) exception mapper handles this and we execute a RenderPageRequestHandler,
which re-renders the page
3) the request cycle detaches, which delegates in part
to RequestHandlerExecutor.detach()
4) The handlers to detach are both handlers from step 1 and 2; During the
detach of ListenerRequestHandler, it initializes ListenerLogData, which (in
the PageLogData ctor) throws the StalePageException again!
5) The second handler (RenderPageRequestHandler) is not detached, thus all
models in the page are not detached
6) The user clicks on a link and boom, the models are all still attached
and there we get the LazyInitializationException

I think that (a) RequestHandlerExecutor.detach() should ensure all handlers
are detached, and (b) that failing to collect LogData should not stop the
detaching of a request handler.

What do you think?

I tried to make the simplest possible Quickstart to demonstrate this.

Weird stuff: on the homepage of the quick start, the page is properly
detached when a stale link is clicked;
On another (test) page, the page is not properly detached.

Steps to reproduce:

Run Quickstart
Click on “Test” link on homepage
Observe that the following is logged:

Model still attached? false
Page detaching

Now click on "Click me (stale link)!”
Now refresh the page (re-render)

Observe that the following is logged:

Model still attached? true
Page detaching

—> So the page was not detached

These steps don’t have the same result on the homepage. So my guess is
there is some relation to the fact that we are interacting with a stateful,
non-mounted page.

Met vriendelijke groet,
Kind regards,

Bas Gooren

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Performance issue (possible bug since 7.2.0…up to and including 8.0.0-M8)

[Lon Varscsak]

Thanks guys, I filed WICKET-6506.

-Lon

On Wed, Dec 13, 2017 at 2:15 AM, Emond Papegaaij  wrote:

> Martin is right. It seems like you found a regression in the changes made
> for
> WICKET-6021. In general, the performance was increased by those changes,
> but
> evidently not in this case. Please create a JIRA issue and attach a
> quickstart
> that shows the problem. That should help us debug this regression.
>
> Best regards,
> Emond
>
> On woensdag 13 december 2017 05:39:15 CET Martin Makundi wrote:
> > Performance is no joking mantter =)
> >
> > 2017-12-13 3:56 GMT+02:00 Lon Varscsak :
> > > Haha, sure…I was sure someone was going to argue with me. :P
> > >
> > > -Lon
> > >
> > > On Tue, Dec 12, 2017 at 6:23 PM, Martin Makundi <
> > >
> > > martin.maku...@koodaripalvelut.com> wrote:
> > > > Good find! Sounds like a bug, file to jira?
> > > >
> > > > 2017-12-12 23:38 GMT+02:00 Lon Varscsak :
> > > > > Okay, so here's the situation, I have a component where an Ajax
> > > > > request
> > > > > displays a large table (1000ish rows).  It display fast, no
> problem,
> > >
> > > not
> > >
> > > > a
> > > >
> > > > > great use of resources (not paginating), but ignore that for now.
> I
> > >
> > > then
> > >
> > > > > have another Ajax request where I tell the wicket component to not
> be
> > > > > visible and refresh an area.  No problem so far (although slightly
> > >
> > > slow,
> > >
> > > > > since it's not generating much html, should be faster).  Now EVERY
> > > > > Ajax
> > > > > request that updates the same area (with the component not in the
> > > > > html)
> > > > > takes a long time to respond (half second), even though it should
> be
> > > > > returning in ms, because the html is pretty minimal.
> > > > >
> > > > > I hooked it up to a profiler and found that it's spending a large
> > >
> > > amount
> > >
> > > > of
> > > >
> > > > > CPU time in
> > > > > MarkupContainer$MarkupChildIterator.refreshInternalIteratorIfNeede
> d().
> > > >
> > > > I'm
> > > >
> > > > > not sure why it would be traversing the component hierarchy of the
> > >
> > > table
> > >
> > > > > that's not even visible…but I don't know enough of the
> architecture of
> > > > > wicket to really say…which is why I've come here. :)
> > > > >
> > > > > I've gone back to 7.1.0 and can confirm that in that version this
> > > >
> > > > "problem"
> > > >
> > > > > does not exist.  The Ajax request is as fast as if I've never
> loaded
> > >
> > > the
> > >
> > > > > large table.
> > > > >
> > > > > So I've attached a link to a Quickstart showing the problem
> (currently
> > > > > configured for 8.0.0-M8, but can be complied down to 7.0.0).  When
> > > >
> > > > loading
> > > >
> > > > > the page, first click the refresh link…this will essentially
> refresh
> > >
> > > all
> > >
> > > > > the contents in an Ajax request and give you a sense of how fast it
> > > > > _should_ be.  The table has not been visible yet, so there have
> been
> > > > > no
> > > > > ListView items created yet.  Then click "show table", this will
> > >
> > > generate
> > >
> > > > 2k
> > > >
> > > > > dummy rows and redisplay the area.  It's obviously slower because
> it's
> > > > > generating 350k of html (but surprisingly fast :P).  Then click
> hide
> > > > > table.  It takes about the same amount of time to hide the table
> as it
> > > >
> > > > does
> > > >
> > > > > to show it, which is odd, because the html being regenerated is the
> > >
> > > same
> > >
> > > > as
> > > >
> > > > > if there were no table displayed.  Then go ahead and click
> "refresh"
> > >
> > > and
> > >
> > > > > you'll see that refreshing a basically empty component is slow
> because
> > > >
> > > > it's
> > > >
> > > > > referencing all the components in the wicket hierarchy (
> > > > > MarkupChildIterator.refreshInternalIteratorIfNeeded)even though
> > >
> > > they're
> > >
> > > > > not
> > > > > visible.
> > > > >
> > > > > Thoughts?  I recognize that the first response will be "don't
> display
> > > >
> > > > 1000
> > > >
> > > > > rows", but lets ignore that for now.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > -Lon
> > > > >
> > > > > Here's the link to the Quickstart:
> > > > > https://www.dropbox.com/s/l0uxsibmh24nsoh/slownesstest.tar.gz?dl=0
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Performance issue (possible bug since 7.2.0…up to and including 8.0.0-M8)

[Emond Papegaaij]

Martin is right. It seems like you found a regression in the changes made for 
WICKET-6021. In general, the performance was increased by those changes, but 
evidently not in this case. Please create a JIRA issue and attach a quickstart 
that shows the problem. That should help us debug this regression.

Best regards,
Emond

On woensdag 13 december 2017 05:39:15 CET Martin Makundi wrote:
> Performance is no joking mantter =)
> 
> 2017-12-13 3:56 GMT+02:00 Lon Varscsak :
> > Haha, sure…I was sure someone was going to argue with me. :P
> > 
> > -Lon
> > 
> > On Tue, Dec 12, 2017 at 6:23 PM, Martin Makundi <
> > 
> > martin.maku...@koodaripalvelut.com> wrote:
> > > Good find! Sounds like a bug, file to jira?
> > > 
> > > 2017-12-12 23:38 GMT+02:00 Lon Varscsak :
> > > > Okay, so here's the situation, I have a component where an Ajax
> > > > request
> > > > displays a large table (1000ish rows).  It display fast, no problem,
> > 
> > not
> > 
> > > a
> > > 
> > > > great use of resources (not paginating), but ignore that for now.  I
> > 
> > then
> > 
> > > > have another Ajax request where I tell the wicket component to not be
> > > > visible and refresh an area.  No problem so far (although slightly
> > 
> > slow,
> > 
> > > > since it's not generating much html, should be faster).  Now EVERY
> > > > Ajax
> > > > request that updates the same area (with the component not in the
> > > > html)
> > > > takes a long time to respond (half second), even though it should be
> > > > returning in ms, because the html is pretty minimal.
> > > > 
> > > > I hooked it up to a profiler and found that it's spending a large
> > 
> > amount
> > 
> > > of
> > > 
> > > > CPU time in
> > > > MarkupContainer$MarkupChildIterator.refreshInternalIteratorIfNeeded().
> > > 
> > > I'm
> > > 
> > > > not sure why it would be traversing the component hierarchy of the
> > 
> > table
> > 
> > > > that's not even visible…but I don't know enough of the architecture of
> > > > wicket to really say…which is why I've come here. :)
> > > > 
> > > > I've gone back to 7.1.0 and can confirm that in that version this
> > > 
> > > "problem"
> > > 
> > > > does not exist.  The Ajax request is as fast as if I've never loaded
> > 
> > the
> > 
> > > > large table.
> > > > 
> > > > So I've attached a link to a Quickstart showing the problem (currently
> > > > configured for 8.0.0-M8, but can be complied down to 7.0.0).  When
> > > 
> > > loading
> > > 
> > > > the page, first click the refresh link…this will essentially refresh
> > 
> > all
> > 
> > > > the contents in an Ajax request and give you a sense of how fast it
> > > > _should_ be.  The table has not been visible yet, so there have been
> > > > no
> > > > ListView items created yet.  Then click "show table", this will
> > 
> > generate
> > 
> > > 2k
> > > 
> > > > dummy rows and redisplay the area.  It's obviously slower because it's
> > > > generating 350k of html (but surprisingly fast :P).  Then click hide
> > > > table.  It takes about the same amount of time to hide the table as it
> > > 
> > > does
> > > 
> > > > to show it, which is odd, because the html being regenerated is the
> > 
> > same
> > 
> > > as
> > > 
> > > > if there were no table displayed.  Then go ahead and click "refresh"
> > 
> > and
> > 
> > > > you'll see that refreshing a basically empty component is slow because
> > > 
> > > it's
> > > 
> > > > referencing all the components in the wicket hierarchy (
> > > > MarkupChildIterator.refreshInternalIteratorIfNeeded)even though
> > 
> > they're
> > 
> > > > not
> > > > visible.
> > > > 
> > > > Thoughts?  I recognize that the first response will be "don't display
> > > 
> > > 1000
> > > 
> > > > rows", but lets ignore that for now.
> > > > 
> > > > Thanks!
> > > > 
> > > > -Lon
> > > > 
> > > > Here's the link to the Quickstart:
> > > > https://www.dropbox.com/s/l0uxsibmh24nsoh/slownesstest.tar.gz?dl=0



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Performance issue (possible bug since 7.2.0…up to and including 8.0.0-M8)

[Martijn Dashorst]

In 7.2 we modified the markupcontainer's storage of its children to
accommodate large numbers of children. The original structure gave adding
children a O(N^2) complexity, so it was changed to become O(1) for N>some
value.

Apparently your use case is not part of our setup and we should see what
happens.

Please file a bug report and we'll look into it

Martijn


On Tue, Dec 12, 2017 at 10:38 PM, Lon Varscsak 
wrote:

> Okay, so here's the situation, I have a component where an Ajax request
> displays a large table (1000ish rows).  It display fast, no problem, not a
> great use of resources (not paginating), but ignore that for now.  I then
> have another Ajax request where I tell the wicket component to not be
> visible and refresh an area.  No problem so far (although slightly slow,
> since it's not generating much html, should be faster).  Now EVERY Ajax
> request that updates the same area (with the component not in the html)
> takes a long time to respond (half second), even though it should be
> returning in ms, because the html is pretty minimal.
>
> I hooked it up to a profiler and found that it's spending a large amount of
> CPU time in
> MarkupContainer$MarkupChildIterator.refreshInternalIteratorIfNeeded(). I'm
> not sure why it would be traversing the component hierarchy of the table
> that's not even visible…but I don't know enough of the architecture of
> wicket to really say…which is why I've come here. :)
>
> I've gone back to 7.1.0 and can confirm that in that version this "problem"
> does not exist.  The Ajax request is as fast as if I've never loaded the
> large table.
>
> So I've attached a link to a Quickstart showing the problem (currently
> configured for 8.0.0-M8, but can be complied down to 7.0.0).  When loading
> the page, first click the refresh link…this will essentially refresh all
> the contents in an Ajax request and give you a sense of how fast it
> _should_ be.  The table has not been visible yet, so there have been no
> ListView items created yet.  Then click "show table", this will generate 2k
> dummy rows and redisplay the area.  It's obviously slower because it's
> generating 350k of html (but surprisingly fast :P).  Then click hide
> table.  It takes about the same amount of time to hide the table as it does
> to show it, which is odd, because the html being regenerated is the same as
> if there were no table displayed.  Then go ahead and click "refresh" and
> you'll see that refreshing a basically empty component is slow because it's
> referencing all the components in the wicket hierarchy (
> MarkupChildIterator.refreshInternalIteratorIfNeeded)even though they're
> not
> visible.
>
> Thoughts?  I recognize that the first response will be "don't display 1000
> rows", but lets ignore that for now.
>
> Thanks!
>
> -Lon
>
> Here's the link to the Quickstart:
> https://www.dropbox.com/s/l0uxsibmh24nsoh/slownesstest.tar.gz?dl=0
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Performance issue (possible bug since 7.2.0…up to and including 8.0.0-M8)

[Martin Makundi]

Performance is no joking mantter =)

2017-12-13 3:56 GMT+02:00 Lon Varscsak :

> Haha, sure…I was sure someone was going to argue with me. :P
>
> -Lon
>
> On Tue, Dec 12, 2017 at 6:23 PM, Martin Makundi <
> martin.maku...@koodaripalvelut.com> wrote:
>
> > Good find! Sounds like a bug, file to jira?
> >
> > 2017-12-12 23:38 GMT+02:00 Lon Varscsak :
> >
> > > Okay, so here's the situation, I have a component where an Ajax request
> > > displays a large table (1000ish rows).  It display fast, no problem,
> not
> > a
> > > great use of resources (not paginating), but ignore that for now.  I
> then
> > > have another Ajax request where I tell the wicket component to not be
> > > visible and refresh an area.  No problem so far (although slightly
> slow,
> > > since it's not generating much html, should be faster).  Now EVERY Ajax
> > > request that updates the same area (with the component not in the html)
> > > takes a long time to respond (half second), even though it should be
> > > returning in ms, because the html is pretty minimal.
> > >
> > > I hooked it up to a profiler and found that it's spending a large
> amount
> > of
> > > CPU time in
> > > MarkupContainer$MarkupChildIterator.refreshInternalIteratorIfNeeded().
> > I'm
> > > not sure why it would be traversing the component hierarchy of the
> table
> > > that's not even visible…but I don't know enough of the architecture of
> > > wicket to really say…which is why I've come here. :)
> > >
> > > I've gone back to 7.1.0 and can confirm that in that version this
> > "problem"
> > > does not exist.  The Ajax request is as fast as if I've never loaded
> the
> > > large table.
> > >
> > > So I've attached a link to a Quickstart showing the problem (currently
> > > configured for 8.0.0-M8, but can be complied down to 7.0.0).  When
> > loading
> > > the page, first click the refresh link…this will essentially refresh
> all
> > > the contents in an Ajax request and give you a sense of how fast it
> > > _should_ be.  The table has not been visible yet, so there have been no
> > > ListView items created yet.  Then click "show table", this will
> generate
> > 2k
> > > dummy rows and redisplay the area.  It's obviously slower because it's
> > > generating 350k of html (but surprisingly fast :P).  Then click hide
> > > table.  It takes about the same amount of time to hide the table as it
> > does
> > > to show it, which is odd, because the html being regenerated is the
> same
> > as
> > > if there were no table displayed.  Then go ahead and click "refresh"
> and
> > > you'll see that refreshing a basically empty component is slow because
> > it's
> > > referencing all the components in the wicket hierarchy (
> > > MarkupChildIterator.refreshInternalIteratorIfNeeded)even though
> they're
> > > not
> > > visible.
> > >
> > > Thoughts?  I recognize that the first response will be "don't display
> > 1000
> > > rows", but lets ignore that for now.
> > >
> > > Thanks!
> > >
> > > -Lon
> > >
> > > Here's the link to the Quickstart:
> > > https://www.dropbox.com/s/l0uxsibmh24nsoh/slownesstest.tar.gz?dl=0
> > >
> >
>

Re: Performance issue (possible bug since 7.2.0…up to and including 8.0.0-M8)

[Lon Varscsak]

Haha, sure…I was sure someone was going to argue with me. :P

-Lon

On Tue, Dec 12, 2017 at 6:23 PM, Martin Makundi <
martin.maku...@koodaripalvelut.com> wrote:

> Good find! Sounds like a bug, file to jira?
>
> 2017-12-12 23:38 GMT+02:00 Lon Varscsak :
>
> > Okay, so here's the situation, I have a component where an Ajax request
> > displays a large table (1000ish rows).  It display fast, no problem, not
> a
> > great use of resources (not paginating), but ignore that for now.  I then
> > have another Ajax request where I tell the wicket component to not be
> > visible and refresh an area.  No problem so far (although slightly slow,
> > since it's not generating much html, should be faster).  Now EVERY Ajax
> > request that updates the same area (with the component not in the html)
> > takes a long time to respond (half second), even though it should be
> > returning in ms, because the html is pretty minimal.
> >
> > I hooked it up to a profiler and found that it's spending a large amount
> of
> > CPU time in
> > MarkupContainer$MarkupChildIterator.refreshInternalIteratorIfNeeded().
> I'm
> > not sure why it would be traversing the component hierarchy of the table
> > that's not even visible…but I don't know enough of the architecture of
> > wicket to really say…which is why I've come here. :)
> >
> > I've gone back to 7.1.0 and can confirm that in that version this
> "problem"
> > does not exist.  The Ajax request is as fast as if I've never loaded the
> > large table.
> >
> > So I've attached a link to a Quickstart showing the problem (currently
> > configured for 8.0.0-M8, but can be complied down to 7.0.0).  When
> loading
> > the page, first click the refresh link…this will essentially refresh all
> > the contents in an Ajax request and give you a sense of how fast it
> > _should_ be.  The table has not been visible yet, so there have been no
> > ListView items created yet.  Then click "show table", this will generate
> 2k
> > dummy rows and redisplay the area.  It's obviously slower because it's
> > generating 350k of html (but surprisingly fast :P).  Then click hide
> > table.  It takes about the same amount of time to hide the table as it
> does
> > to show it, which is odd, because the html being regenerated is the same
> as
> > if there were no table displayed.  Then go ahead and click "refresh" and
> > you'll see that refreshing a basically empty component is slow because
> it's
> > referencing all the components in the wicket hierarchy (
> > MarkupChildIterator.refreshInternalIteratorIfNeeded)even though they're
> > not
> > visible.
> >
> > Thoughts?  I recognize that the first response will be "don't display
> 1000
> > rows", but lets ignore that for now.
> >
> > Thanks!
> >
> > -Lon
> >
> > Here's the link to the Quickstart:
> > https://www.dropbox.com/s/l0uxsibmh24nsoh/slownesstest.tar.gz?dl=0
> >
>

Re: Performance issue (possible bug since 7.2.0…up to and including 8.0.0-M8)

[Martin Makundi]

Good find! Sounds like a bug, file to jira?

2017-12-12 23:38 GMT+02:00 Lon Varscsak :

> Okay, so here's the situation, I have a component where an Ajax request
> displays a large table (1000ish rows).  It display fast, no problem, not a
> great use of resources (not paginating), but ignore that for now.  I then
> have another Ajax request where I tell the wicket component to not be
> visible and refresh an area.  No problem so far (although slightly slow,
> since it's not generating much html, should be faster).  Now EVERY Ajax
> request that updates the same area (with the component not in the html)
> takes a long time to respond (half second), even though it should be
> returning in ms, because the html is pretty minimal.
>
> I hooked it up to a profiler and found that it's spending a large amount of
> CPU time in
> MarkupContainer$MarkupChildIterator.refreshInternalIteratorIfNeeded(). I'm
> not sure why it would be traversing the component hierarchy of the table
> that's not even visible…but I don't know enough of the architecture of
> wicket to really say…which is why I've come here. :)
>
> I've gone back to 7.1.0 and can confirm that in that version this "problem"
> does not exist.  The Ajax request is as fast as if I've never loaded the
> large table.
>
> So I've attached a link to a Quickstart showing the problem (currently
> configured for 8.0.0-M8, but can be complied down to 7.0.0).  When loading
> the page, first click the refresh link…this will essentially refresh all
> the contents in an Ajax request and give you a sense of how fast it
> _should_ be.  The table has not been visible yet, so there have been no
> ListView items created yet.  Then click "show table", this will generate 2k
> dummy rows and redisplay the area.  It's obviously slower because it's
> generating 350k of html (but surprisingly fast :P).  Then click hide
> table.  It takes about the same amount of time to hide the table as it does
> to show it, which is odd, because the html being regenerated is the same as
> if there were no table displayed.  Then go ahead and click "refresh" and
> you'll see that refreshing a basically empty component is slow because it's
> referencing all the components in the wicket hierarchy (
> MarkupChildIterator.refreshInternalIteratorIfNeeded)even though they're
> not
> visible.
>
> Thoughts?  I recognize that the first response will be "don't display 1000
> rows", but lets ignore that for now.
>
> Thanks!
>
> -Lon
>
> Here's the link to the Quickstart:
> https://www.dropbox.com/s/l0uxsibmh24nsoh/slownesstest.tar.gz?dl=0
>

Performance issue (possible bug since 7.2.0…up to and including 8.0.0-M8)

[Lon Varscsak]

Okay, so here's the situation, I have a component where an Ajax request
displays a large table (1000ish rows).  It display fast, no problem, not a
great use of resources (not paginating), but ignore that for now.  I then
have another Ajax request where I tell the wicket component to not be
visible and refresh an area.  No problem so far (although slightly slow,
since it's not generating much html, should be faster).  Now EVERY Ajax
request that updates the same area (with the component not in the html)
takes a long time to respond (half second), even though it should be
returning in ms, because the html is pretty minimal.

I hooked it up to a profiler and found that it's spending a large amount of
CPU time in
MarkupContainer$MarkupChildIterator.refreshInternalIteratorIfNeeded(). I'm
not sure why it would be traversing the component hierarchy of the table
that's not even visible…but I don't know enough of the architecture of
wicket to really say…which is why I've come here. :)

I've gone back to 7.1.0 and can confirm that in that version this "problem"
does not exist.  The Ajax request is as fast as if I've never loaded the
large table.

So I've attached a link to a Quickstart showing the problem (currently
configured for 8.0.0-M8, but can be complied down to 7.0.0).  When loading
the page, first click the refresh link…this will essentially refresh all
the contents in an Ajax request and give you a sense of how fast it
_should_ be.  The table has not been visible yet, so there have been no
ListView items created yet.  Then click "show table", this will generate 2k
dummy rows and redisplay the area.  It's obviously slower because it's
generating 350k of html (but surprisingly fast :P).  Then click hide
table.  It takes about the same amount of time to hide the table as it does
to show it, which is odd, because the html being regenerated is the same as
if there were no table displayed.  Then go ahead and click "refresh" and
you'll see that refreshing a basically empty component is slow because it's
referencing all the components in the wicket hierarchy (
MarkupChildIterator.refreshInternalIteratorIfNeeded)even though they're not
visible.

Thoughts?  I recognize that the first response will be "don't display 1000
rows", but lets ignore that for now.

Thanks!

-Lon

Here's the link to the Quickstart:
https://www.dropbox.com/s/l0uxsibmh24nsoh/slownesstest.tar.gz?dl=0

Re: WicketTester's possible bug?

[Vit Rozkovec]

I see now, thanks a lot.
Vit

On 05/07/2017 03:41 PM, Martin Grigorov wrote:

The setting is DebugSettings#componentUseCheck:
https://github.com/apache/wicket/blob/e22614277685199ed56c3aa855fdb0daf454027e/wicket-core/src/main/java/org/apache/wicket/settings/DebugSettings.java#L137
The rendering is markup driven, i.e. for every component in the HTML Wicket
tries to find a component in Java. So technically the extra child in Java
is not really a problem.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Sat, May 6, 2017 at 8:31 PM, Martijn Dashorst 
wrote:

Hi,

when testing the application which is in deployment mode, test passes

even

when the child is missing:

Code:

 TextField input = new TextField("input");
 add(new WebMarkupContainer("border").add(input));

HTML:

 
 

Test:

 //start and render the test page
 tester.startPage(HomePage.class);

 //assert rendered page class
 tester.assertRenderedPage(HomePage.class);


In development mode, this test fails, in deployment passes. Is it

desirable

effect or a bug?

I've used Wicket 8.0.0-M5 quickstart which shows this behavior that I can
provide.

Thanks,
Vit


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




--
Become a Wicket expert, learn from the best: http://wicketinaction.com

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: WicketTester's possible bug?

[Martin Grigorov]

The setting is DebugSettings#componentUseCheck:
https://github.com/apache/wicket/blob/e22614277685199ed56c3aa855fdb0daf454027e/wicket-core/src/main/java/org/apache/wicket/settings/DebugSettings.java#L137
The rendering is markup driven, i.e. for every component in the HTML Wicket
tries to find a component in Java. So technically the extra child in Java
is not really a problem.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Sat, May 6, 2017 at 8:31 PM, Martijn Dashorst  wrote:

> This is as designed. We are stricter in our markup checking in dev
> mode than in prod mode. Mostly because of performance considerations.
> You can fiddle with the settings to make dev and prod similar.
>
> Search the archives or see the one of the *Settings classes for which
> setting to en/disable. (I don't know it by name)
>
> Martijn
>
>
> On Sat, May 6, 2017 at 2:37 PM, Vit Rozkovec 
> wrote:
> > Hi,
> >
> > when testing the application which is in deployment mode, test passes
> even
> > when the child is missing:
> >
> > Code:
> >
> > TextField input = new TextField("input");
> > add(new WebMarkupContainer("border").add(input));
> >
> > HTML:
> >
> > 
> > 
> >
> > Test:
> >
> > //start and render the test page
> > tester.startPage(HomePage.class);
> >
> > //assert rendered page class
> > tester.assertRenderedPage(HomePage.class);
> >
> >
> > In development mode, this test fails, in deployment passes. Is it
> desirable
> > effect or a bug?
> >
> > I've used Wicket 8.0.0-M5 quickstart which shows this behavior that I can
> > provide.
> >
> > Thanks,
> > Vit
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: WicketTester's possible bug?

[Martijn Dashorst]

This is as designed. We are stricter in our markup checking in dev
mode than in prod mode. Mostly because of performance considerations.
You can fiddle with the settings to make dev and prod similar.

Search the archives or see the one of the *Settings classes for which
setting to en/disable. (I don't know it by name)

Martijn


On Sat, May 6, 2017 at 2:37 PM, Vit Rozkovec  wrote:
> Hi,
>
> when testing the application which is in deployment mode, test passes even
> when the child is missing:
>
> Code:
>
> TextField input = new TextField("input");
> add(new WebMarkupContainer("border").add(input));
>
> HTML:
>
> 
> 
>
> Test:
>
> //start and render the test page
> tester.startPage(HomePage.class);
>
> //assert rendered page class
> tester.assertRenderedPage(HomePage.class);
>
>
> In development mode, this test fails, in deployment passes. Is it desirable
> effect or a bug?
>
> I've used Wicket 8.0.0-M5 quickstart which shows this behavior that I can
> provide.
>
> Thanks,
> Vit
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

WicketTester's possible bug?

[Vit Rozkovec]

Hi,

when testing the application which is in deployment mode, test passes 
even when the child is missing:


Code:

TextField input = new TextField("input");
add(new WebMarkupContainer("border").add(input));

HTML:




Test:

//start and render the test page
tester.startPage(HomePage.class);

//assert rendered page class
tester.assertRenderedPage(HomePage.class);


In development mode, this test fails, in deployment passes. Is it 
desirable effect or a bug?


I've used Wicket 8.0.0-M5 quickstart which shows this behavior that I 
can provide.


Thanks,
Vit


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Possible bug with AjaxButton and textarea.

[Raul]

Hi, I have a form with a textarea using CKEditor, I need to send the contents
of the textarea to the server.
When using a standard Button, content is submit correctly, but when
AjaxButton type, the data is not sent to the server. I tried to remove the
comportamient CKEditor, and AjaxButton if it works, someone expert can tell
me that may be happening.



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Possible-bug-with-AjaxButton-and-textarea-tp4660669.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Possible bug with AjaxLazyLoadPanel

[Michael Zhavzharov]

Hm, I just tried to do what you are talking about and it works for me.
I have an ALLP:
add(new AjaxLazyLoadPanel(lazy) {
@Override
public Component getLazyLoadComponent(*String id*) {
return new ContentPanel(*id*);
}
});

and AjaxLink:
add(new AjaxLink(thumbLink) {
@Override
public void onClick(AjaxRequestTarget ajaxRequestTarget) {
   
System.out.println(this.getPage().get(lazy).get(*content*));
}
});

And in debug I can see, that get(content) returns me component that I
need.



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Possible-bug-with-AjaxLazyLoadPanel-tp4658793p4658838.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Possible bug with AjaxLazyLoadPanel

[Raul]

Michael Zhavzharov the way you've indicated, it works correctly.
Thank you.



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Possible-bug-with-AjaxLazyLoadPanel-tp4658793p4658846.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Possible bug with AjaxLazyLoadPanel

[Martin Grigorov]

Hi,

See AjaxLazyLoadPanel's source. It uses a temporary component until the
expensive one is loaded.


On Tue, May 14, 2013 at 6:29 PM, Raul ralva...@netwie.com wrote:

 Hello, I'm trying to get a component to update with Ajax from a AjaxLink,
 but
 always returns null, the access component is as follows.

 Component  current = this.getPage().get(commentsPanel).get
 (modalPanel);

 Where commentsPanel is a AjaxLazyLoadPanel and modalPanel is of type
 Panel, If commentsPanel I put Panel type, the component finds
 correctly,



 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Possible-bug-with-AjaxLazyLoadPanel-tp4658793.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-- 
Martin Grigorov
Wicket Training  Consulting
http://jWeekend.com http://jweekend.com/

Re: Possible bug with AjaxLazyLoadPanel

[Raul]

I know how it works, in my case the component is already loaded, and I can
access it, the problem is I have to access the internal components of the
AjaxLazyLoadPanel.



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Possible-bug-with-AjaxLazyLoadPanel-tp4658793p4658817.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Possible bug with AjaxLazyLoadPanel

[Raul]

Hello, I'm trying to get a component to update with Ajax from a AjaxLink, but
always returns null, the access component is as follows.

Component  current = this.getPage().get(commentsPanel).get (modalPanel);

Where commentsPanel is a AjaxLazyLoadPanel and modalPanel is of type
Panel, If commentsPanel I put Panel type, the component finds correctly,



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Possible-bug-with-AjaxLazyLoadPanel-tp4658793.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Possible bug in ListView [Cannot change attributes in ListView div]

[Sven Meier]

Short answer is in ListView's javadoc:

 * p
 * strongNOTE:/strong
 *
 * When you want to change the default generated markup it is important 
to realize that the ListView
 * instance itself does not correspond to any markup, however, the 
generated ListItems do.br/

 *
 * This means that methods like {@link #setRenderBodyOnly(boolean)} and
 * {@link #add(org.apache.wicket.behavior.Behavior...)} should be 
invoked on the {@link ListItem}

 * that is given in {@link #populateItem(ListItem)} method.
 * /p

Sven

On 02/24/2013 02:40 AM, Gonzalo Aguilar Delgado wrote:

Hello,

I think I found something that may not be working right.

I have an html that looks like:

div wicket:id=regionOne
div wicket:id=regionWidget/div
/div


regionOne will be a listview and regionWidget will be one panel
populated on populateItem.


This is how it looks the class that will go to regionOne (listview)

public class RegionWidgetContainer extends ListViewRegionWidget {
/**
 *
 */
private static final long serialVersionUID = 1L;
final static Logger logger =
LoggerFactory.getLogger(RegionWidgetContainer.class);
private static int regionCounter = 1;

private int regionIdx=0;

public RegionWidgetContainer(String id, final Region region, PageUser
pageUser) {
super(id, new IModelListRegionWidget(){

/**
 *
 */
private static final long serialVersionUID = 1L;

@Override
public void detach() {
// TODO Auto-generated method stub
}

@Override
public ListRegionWidget getObject() {
return region.getRegionWidgets();
}

@Override
public void setObject(ListRegionWidget object) {
}

});
regionIdx = RegionWidgetContainer.nextCounter();
buildCssClassAttributes(region,pageUser);
this.setMarkupId(region- + region.getId() + -id);   
this.setOutputMarkupId(true);
}

protected void buildCssClassAttributes(Region region, PageUser
pageUser)
{
String cssClass = region;
if(region.isLocked() || !pageUser.isEditor())
{
cssClass +=  region-locked;
}

cssClass +=   + region.getPage().getPageLayout().getCode() + 
_ +
String.valueOf(regionIdx);
cssClass +=  regionNonDragging;


this.add(new AttributeAppender(class, cssClass));
}
...
}



As you can see it will add the class via AttributeAppender and will set
the markup id.


But it does not work. Any of two. The div is rendered like this...

div
...
/div


So, is this a bug or a feature?





-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Possible bug in ListView [Cannot change attributes in ListView div]

[Gonzalo Aguilar Delgado]

Hello Sven, 

I'm stupid. Sorry for the question. I read a lot of times it in the
forums, saw examples, but really 
never realized that the main div was the item that get passed to the
populateItem.

It made me uncofortable someway. I don't know why. :D

Thank you a lot. 


El dom, 24-02-2013 a las 09:01 +0100, Sven Meier escribió:

 Short answer is in ListView's javadoc:
 
   * p
   * strongNOTE:/strong
   *
   * When you want to change the default generated markup it is important 
 to realize that the ListView
   * instance itself does not correspond to any markup, however, the 
 generated ListItems do.br/
   *
   * This means that methods like {@link #setRenderBodyOnly(boolean)} and
   * {@link #add(org.apache.wicket.behavior.Behavior...)} should be 
 invoked on the {@link ListItem}
   * that is given in {@link #populateItem(ListItem)} method.
   * /p
 
 Sven
 
 On 02/24/2013 02:40 AM, Gonzalo Aguilar Delgado wrote:
  Hello,
 
  I think I found something that may not be working right.
 
  I have an html that looks like:
 
  div wicket:id=regionOne
  div wicket:id=regionWidget/div
  /div
 
 
  regionOne will be a listview and regionWidget will be one panel
  populated on populateItem.
 
 
  This is how it looks the class that will go to regionOne (listview)
 
  public class RegionWidgetContainer extends ListViewRegionWidget {
  /**
   *
   */
  private static final long serialVersionUID = 1L;
  final static Logger logger =
  LoggerFactory.getLogger(RegionWidgetContainer.class);
  private static int regionCounter = 1;
 
  private int regionIdx=0;
 
  public RegionWidgetContainer(String id, final Region region, PageUser
  pageUser) {
  super(id, new IModelListRegionWidget(){
 
  /**
   *
   */
  private static final long serialVersionUID = 1L;
 
  @Override
  public void detach() {
  // TODO Auto-generated method stub
  }
 
  @Override
  public ListRegionWidget getObject() {
  return region.getRegionWidgets();
  }
 
  @Override
  public void setObject(ListRegionWidget object) {
  }
  
  });
  regionIdx = RegionWidgetContainer.nextCounter();
  buildCssClassAttributes(region,pageUser);
  this.setMarkupId(region- + region.getId() + -id);   
  this.setOutputMarkupId(true);
  }
  
  protected void buildCssClassAttributes(Region region, PageUser
  pageUser)
  {
  String cssClass = region;
  if(region.isLocked() || !pageUser.isEditor())
  {
  cssClass +=  region-locked;
  }
  
  cssClass +=   + region.getPage().getPageLayout().getCode() + 
  _ +
  String.valueOf(regionIdx);
  cssClass +=  regionNonDragging;
  
  
  this.add(new AttributeAppender(class, cssClass));
  }
  ...
  }
 
 
 
  As you can see it will add the class via AttributeAppender and will set
  the markup id.
 
 
  But it does not work. Any of two. The div is rendered like this...
 
  div
  ...
  /div
 
 
  So, is this a bug or a feature?
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 

Possible bug in ListView [Cannot change attributes in ListView div]

[Gonzalo Aguilar Delgado]

Hello, 

I think I found something that may not be working right. 

I have an html that looks like:

div wicket:id=regionOne
div wicket:id=regionWidget/div
/div


regionOne will be a listview and regionWidget will be one panel
populated on populateItem.


This is how it looks the class that will go to regionOne (listview)

public class RegionWidgetContainer extends ListViewRegionWidget {
/**
 * 
 */
private static final long serialVersionUID = 1L;
final static Logger logger =
LoggerFactory.getLogger(RegionWidgetContainer.class);
private static int regionCounter = 1;

private int regionIdx=0;

public RegionWidgetContainer(String id, final Region region, PageUser
pageUser) {
super(id, new IModelListRegionWidget(){

/**
 * 
 */
private static final long serialVersionUID = 1L;

@Override
public void detach() {
// TODO Auto-generated method stub
}

@Override
public ListRegionWidget getObject() {
return region.getRegionWidgets();
}

@Override
public void setObject(ListRegionWidget object) {
}

});
regionIdx = RegionWidgetContainer.nextCounter();
buildCssClassAttributes(region,pageUser);
this.setMarkupId(region- + region.getId() + -id);   
this.setOutputMarkupId(true);
}

protected void buildCssClassAttributes(Region region, PageUser
pageUser)
{
String cssClass = region;
if(region.isLocked() || !pageUser.isEditor())
{
cssClass +=  region-locked;
}

cssClass +=   + region.getPage().getPageLayout().getCode() + 
_ +
String.valueOf(regionIdx);
cssClass +=  regionNonDragging;


this.add(new AttributeAppender(class, cssClass));
}
...
}



As you can see it will add the class via AttributeAppender and will set
the markup id. 


But it does not work. Any of two. The div is rendered like this...

div
...
/div


So, is this a bug or a feature?

Re: Possible bug in ListView [Cannot change attributes in ListView div]

[Ernesto Reinaldo Barreiro]

Try

div wicket:id=regionOne class=
div wicket:id=regionWidget/div
/div


On Sun, Feb 24, 2013 at 2:40 AM, Gonzalo Aguilar Delgado 
gagui...@aguilardelgado.com wrote:

 Hello,

 I think I found something that may not be working right.

 I have an html that looks like:

 div wicket:id=regionOne
 div wicket:id=regionWidget/div
 /div


 regionOne will be a listview and regionWidget will be one panel
 populated on populateItem.


 This is how it looks the class that will go to regionOne (listview)

 public class RegionWidgetContainer extends ListViewRegionWidget {
 /**
  *
  */
 private static final long serialVersionUID = 1L;
 final static Logger logger =
 LoggerFactory.getLogger(RegionWidgetContainer.class);
 private static int regionCounter = 1;

 private int regionIdx=0;

 public RegionWidgetContainer(String id, final Region region,
 PageUser
 pageUser) {
 super(id, new IModelListRegionWidget(){

 /**
  *
  */
 private static final long serialVersionUID = 1L;

 @Override
 public void detach() {
 // TODO Auto-generated method stub
 }

 @Override
 public ListRegionWidget getObject() {
 return region.getRegionWidgets();
 }

 @Override
 public void setObject(ListRegionWidget object) {
 }

 });
 regionIdx = RegionWidgetContainer.nextCounter();
 buildCssClassAttributes(region,pageUser);
 this.setMarkupId(region- + region.getId() + -id);
 this.setOutputMarkupId(true);
 }

 protected void buildCssClassAttributes(Region region, PageUser
 pageUser)
 {
 String cssClass = region;
 if(region.isLocked() || !pageUser.isEditor())
 {
 cssClass +=  region-locked;
 }

 cssClass +=   +
 region.getPage().getPageLayout().getCode() + _ +
 String.valueOf(regionIdx);
 cssClass +=  regionNonDragging;


 this.add(new AttributeAppender(class, cssClass));
 }
 ...
 }



 As you can see it will add the class via AttributeAppender and will set
 the markup id.


 But it does not work. Any of two. The div is rendered like this...

 div
 ...
 /div


 So, is this a bug or a feature?




-- 
Regards - Ernesto Reinaldo Barreiro
Antilia Soft
http://antiliasoft.com/ http://antiliasoft.com/antilia

UploadProgressBar Possible Bug

[MZemeck]

Sorry but I do not have the time/resources to create a quickstart (I don't 
use Maven) but I wanted to alert the group to an issue I had in case 
anyone wanted to test/fix it.

Using the following;

Wicket 1.4.16
UploadWebRequest in App object
Form with setMaxSize() (I'm using 1MB)
FileUploadField
AjaxSubmitButton
UploadProgressBar

When the form max size exception is hit, the progress bar stays visible 
and refreshes many times showing no progress, then eventually disappears. 
If I manually call error on a component the form stops processing and the 
progress bar disappears as expected.  I'm not sure if the bug is in the 
progress bar or the form processing.  There also seems to be some 
difference between Wicket 1.4.16 and 1.4.15.  Using 1.4.15 the progress 
bar disappeared but the page continued to refresh repeatedly.  After 
upgrading to 1.4.16 the progress bar remains visible and continues to 
refresh erroneously.



Notice: This communication, including any attachments, is intended solely 
for the use of the individual or entity to which it is addressed. This 
communication may contain information that is protected from disclosure 
under State and/or Federal law. Please notify the sender immediately if 
you have received this communication in error and delete this email from 
your system. If you are not the intended recipient, you are requested not 
to disclose, copy, distribute or take any action in reliance on the 
contents of this information.

Re: UploadProgressBar Possible Bug

[Pedro Santos]

Please open a ticket, I will try to reproduce and upload a quickstart. I
remember of it taking some time to be hidden, but just the time of form
submit process (maybe your form do heavy processing, easily reproducible on
quickstart).

On Mon, Apr 4, 2011 at 12:43 PM, mzem...@osc.state.ny.us wrote:

 Sorry but I do not have the time/resources to create a quickstart (I don't
 use Maven) but I wanted to alert the group to an issue I had in case
 anyone wanted to test/fix it.

 Using the following;

 Wicket 1.4.16
 UploadWebRequest in App object
 Form with setMaxSize() (I'm using 1MB)
 FileUploadField
 AjaxSubmitButton
 UploadProgressBar

 When the form max size exception is hit, the progress bar stays visible
 and refreshes many times showing no progress, then eventually disappears.
 If I manually call error on a component the form stops processing and the
 progress bar disappears as expected.  I'm not sure if the bug is in the
 progress bar or the form processing.  There also seems to be some
 difference between Wicket 1.4.16 and 1.4.15.  Using 1.4.15 the progress
 bar disappeared but the page continued to refresh repeatedly.  After
 upgrading to 1.4.16 the progress bar remains visible and continues to
 refresh erroneously.



 Notice: This communication, including any attachments, is intended solely
 for the use of the individual or entity to which it is addressed. This
 communication may contain information that is protected from disclosure
 under State and/or Federal law. Please notify the sender immediately if
 you have received this communication in error and delete this email from
 your system. If you are not the intended recipient, you are requested not
 to disclose, copy, distribute or take any action in reliance on the
 contents of this information.




-- 
Pedro Henrique Oliveira dos Santos

Re: UploadProgressBar Possible Bug

[MZemeck]

The form does not process anything besides the file upload, and everything 
works fine until the UploadProgressBar is introduced (and yes I set 
mutlipart to true).  I will open a jira if/when time permits, if you have 
the appropriate credentials please create a jira on my behalf, I am not 
currently an account holder.




From:   Pedro Santos pedros...@gmail.com
To: users@wicket.apache.org
Date:   04/04/2011 04:59 PM
Subject:Re: UploadProgressBar Possible Bug



Please open a ticket, I will try to reproduce and upload a quickstart. I
remember of it taking some time to be hidden, but just the time of form
submit process (maybe your form do heavy processing, easily reproducible 
on
quickstart).

On Mon, Apr 4, 2011 at 12:43 PM, mzem...@osc.state.ny.us wrote:

 Sorry but I do not have the time/resources to create a quickstart (I 
don't
 use Maven) but I wanted to alert the group to an issue I had in case
 anyone wanted to test/fix it.

 Using the following;

 Wicket 1.4.16
 UploadWebRequest in App object
 Form with setMaxSize() (I'm using 1MB)
 FileUploadField
 AjaxSubmitButton
 UploadProgressBar

 When the form max size exception is hit, the progress bar stays visible
 and refreshes many times showing no progress, then eventually 
disappears.
 If I manually call error on a component the form stops processing and 
the
 progress bar disappears as expected.  I'm not sure if the bug is in the
 progress bar or the form processing.  There also seems to be some
 difference between Wicket 1.4.16 and 1.4.15.  Using 1.4.15 the progress
 bar disappeared but the page continued to refresh repeatedly.  After
 upgrading to 1.4.16 the progress bar remains visible and continues to
 refresh erroneously.



 Notice: This communication, including any attachments, is intended 
solely
 for the use of the individual or entity to which it is addressed. This
 communication may contain information that is protected from disclosure
 under State and/or Federal law. Please notify the sender immediately if
 you have received this communication in error and delete this email from
 your system. If you are not the intended recipient, you are requested 
not
 to disclose, copy, distribute or take any action in reliance on the
 contents of this information.




-- 
Pedro Henrique Oliveira dos Santos





Notice: This communication, including any attachments, is intended solely 
for the use of the individual or entity to which it is addressed. This 
communication may contain information that is protected from disclosure 
under State and/or Federal law. Please notify the sender immediately if 
you have received this communication in error and delete this email from 
your system. If you are not the intended recipient, you are requested not 
to disclose, copy, distribute or take any action in reliance on the 
contents of this information.

Re: UploadProgressBar Possible Bug

[Pedro Santos]

we already have a quickstart :)
https://issues.apache.org/jira/browse/WICKET-3594

On Mon, Apr 4, 2011 at 6:10 PM, mzem...@osc.state.ny.us wrote:

 The form does not process anything besides the file upload, and everything
 works fine until the UploadProgressBar is introduced (and yes I set
 mutlipart to true).  I will open a jira if/when time permits, if you have
 the appropriate credentials please create a jira on my behalf, I am not
 currently an account holder.




 From:   Pedro Santos pedros...@gmail.com
 To: users@wicket.apache.org
 Date:   04/04/2011 04:59 PM
 Subject:Re: UploadProgressBar Possible Bug



 Please open a ticket, I will try to reproduce and upload a quickstart. I
 remember of it taking some time to be hidden, but just the time of form
 submit process (maybe your form do heavy processing, easily reproducible
 on
 quickstart).

 On Mon, Apr 4, 2011 at 12:43 PM, mzem...@osc.state.ny.us wrote:

  Sorry but I do not have the time/resources to create a quickstart (I
 don't
  use Maven) but I wanted to alert the group to an issue I had in case
  anyone wanted to test/fix it.
 
  Using the following;
 
  Wicket 1.4.16
  UploadWebRequest in App object
  Form with setMaxSize() (I'm using 1MB)
  FileUploadField
  AjaxSubmitButton
  UploadProgressBar
 
  When the form max size exception is hit, the progress bar stays visible
  and refreshes many times showing no progress, then eventually
 disappears.
  If I manually call error on a component the form stops processing and
 the
  progress bar disappears as expected.  I'm not sure if the bug is in the
  progress bar or the form processing.  There also seems to be some
  difference between Wicket 1.4.16 and 1.4.15.  Using 1.4.15 the progress
  bar disappeared but the page continued to refresh repeatedly.  After
  upgrading to 1.4.16 the progress bar remains visible and continues to
  refresh erroneously.
 
 
 
  Notice: This communication, including any attachments, is intended
 solely
  for the use of the individual or entity to which it is addressed. This
  communication may contain information that is protected from disclosure
  under State and/or Federal law. Please notify the sender immediately if
  you have received this communication in error and delete this email from
  your system. If you are not the intended recipient, you are requested
 not
  to disclose, copy, distribute or take any action in reliance on the
  contents of this information.




 --
 Pedro Henrique Oliveira dos Santos





 Notice: This communication, including any attachments, is intended solely
 for the use of the individual or entity to which it is addressed. This
 communication may contain information that is protected from disclosure
 under State and/or Federal law. Please notify the sender immediately if
 you have received this communication in error and delete this email from
 your system. If you are not the intended recipient, you are requested not
 to disclose, copy, distribute or take any action in reliance on the
 contents of this information.




-- 
Pedro Henrique Oliveira dos Santos

Re: [1.5.0-rc2] possible bug with danish characters

[nino martinez wael]

Ok done som hardcore diging, and found out the problem.

I use markup inheritance in my parent page everything are declared as it
should be

like:

...
?xml version=1.0 encoding=UTF-8?
!-- ** --
!-- NetDesign Web Template --
!-- ** --
! DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN 
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
!-- !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN 
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; --
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=da lang=da
xmlns:wicket=http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd

...

However In my child pages, i've not declared much and forgot this tag

?xml version=1.0 encoding=UTF-8?

After adding the above tag everything seems to be working.. But I thought
that wicket only should care about wicket:head and wicket:extend in child
pages... And this is certainly a change from RC1 to rc2...


regards Nino


2011/3/3 Martin Grigorov mgrigo...@apache.org

 trunk from today runs at http://www.wicket-library.com/wicket-examples

 On Wed, Mar 2, 2011 at 9:21 PM, nino martinez wael 
 nino.martinez.w...@gmail.com wrote:

  is there a server somewhere where rc2 live examples are running on?
 
 
  2011/3/2 Martin Grigorov mgrigo...@apache.org
 
   quickstart will help us to debug it.
   attach it to jira
   thanks!
  
   On Wed, Mar 2, 2011 at 3:16 PM, nino martinez wael 
   nino.martinez.w...@gmail.com wrote:
  
anyone have an idea why changing from rc1 to rc2 would have an have
 an
impact on this..? There was no issue that looked related to me (in
 the
change log).
   
2011/3/2 nino martinez wael nino.martinez.w...@gmail.com
   
 Charset are UTF8... Anyhow there's no problem on rc1..

 2011/3/2 Wilhelmsen Tor Iver toriv...@arrive.no

  I just noticed that after upgrading to rc2, my some of my texts
  like
  håndteret kald when getting saved/posted becomes this:
  håndteret
 kald..

 Charset issue, they get posted as UTF-8; you probably  either need
  to
test
 for charset or assume UTF-8 across the board.

 - Tor Iver


  -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



   
  
 

Re: [1.5.0-rc2] possible bug with danish characters

[Martin Grigorov]

trunk from today runs at http://www.wicket-library.com/wicket-examples

On Wed, Mar 2, 2011 at 9:21 PM, nino martinez wael 
nino.martinez.w...@gmail.com wrote:

 is there a server somewhere where rc2 live examples are running on?


 2011/3/2 Martin Grigorov mgrigo...@apache.org

  quickstart will help us to debug it.
  attach it to jira
  thanks!
 
  On Wed, Mar 2, 2011 at 3:16 PM, nino martinez wael 
  nino.martinez.w...@gmail.com wrote:
 
   anyone have an idea why changing from rc1 to rc2 would have an have an
   impact on this..? There was no issue that looked related to me (in the
   change log).
  
   2011/3/2 nino martinez wael nino.martinez.w...@gmail.com
  
Charset are UTF8... Anyhow there's no problem on rc1..
   
2011/3/2 Wilhelmsen Tor Iver toriv...@arrive.no
   
 I just noticed that after upgrading to rc2, my some of my texts
 like
 håndteret kald when getting saved/posted becomes this:
 håndteret
kald..
   
Charset issue, they get posted as UTF-8; you probably  either need
 to
   test
for charset or assume UTF-8 across the board.
   
- Tor Iver
   
   
 -
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
   
   
   
  
 

Re: [1.5.0-rc2] possible bug with danish characters

[Gonzalo Aguilar Delgado]

Hi


Will try it.

Is there a complete example with the html in place there?

Tnx


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: [1.5.0-rc2] possible bug with danish characters

[Gonzalo Aguilar Delgado]

Have you tried 1.5?


-- 


  Gonzalo Aguilar Delgado
  Consultor CRM - Ingeniero en
Informática

M. +34 607 81 42 76



No subestimes el poder de la gente estúpida en grupos grandes 

El jue, 03-03-2011 a las 20:09 +0200, Martin Grigorov escribió:

 trunk from today runs at http://www.wicket-library.com/wicket-examples
 
 On Wed, Mar 2, 2011 at 9:21 PM, nino martinez wael 
 nino.martinez.w...@gmail.com wrote:
 
  is there a server somewhere where rc2 live examples are running on?
 
 
  2011/3/2 Martin Grigorov mgrigo...@apache.org
 
   quickstart will help us to debug it.
   attach it to jira
   thanks!
  
   On Wed, Mar 2, 2011 at 3:16 PM, nino martinez wael 
   nino.martinez.w...@gmail.com wrote:
  
anyone have an idea why changing from rc1 to rc2 would have an have an
impact on this..? There was no issue that looked related to me (in the
change log).
   
2011/3/2 nino martinez wael nino.martinez.w...@gmail.com
   
 Charset are UTF8... Anyhow there's no problem on rc1..

 2011/3/2 Wilhelmsen Tor Iver toriv...@arrive.no

  I just noticed that after upgrading to rc2, my some of my texts
  like
  håndteret kald when getting saved/posted becomes this:
  håndteret
 kald..

 Charset issue, they get posted as UTF-8; you probably  either need
  to
test
 for charset or assume UTF-8 across the board.

 - Tor Iver


  -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



   
  
 

[1.5.0-rc2] possible bug with danish characters

[nino martinez wael]

Hi

I just noticed that after upgrading to rc2, my some of my texts like
håndteret kald when getting saved/posted becomes this: hÃ¥ndteret kald..
I revert to rc1 to see if it's a problem there (I did not notice it
earlier).

-Regards Nino

RE: [1.5.0-rc2] possible bug with danish characters

[Wilhelmsen Tor Iver]

 I just noticed that after upgrading to rc2, my some of my texts like
 håndteret kald when getting saved/posted becomes this: hÃ¥ndteret kald..

Charset issue, they get posted as UTF-8; you probably  either need to test for 
charset or assume UTF-8 across the board.

- Tor Iver

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: [1.5.0-rc2] possible bug with danish characters

[nino martinez wael]

The problem is not there with rc1, Im using Tomcat 7.04... So to explain
again, I have a text

2011/3/2 nino martinez wael nino.martinez.w...@gmail.com

 Hi

 I just noticed that after upgrading to rc2, my some of my texts like
 håndteret kald when getting saved/posted becomes this: hÃ¥ndteret
 kald.. I revert to rc1 to see if it's a problem there (I did not notice it
 earlier).

 -Regards Nino

Re: [1.5.0-rc2] possible bug with danish characters

[nino martinez wael]

Charset are UTF8... Anyhow there's no problem on rc1..

2011/3/2 Wilhelmsen Tor Iver toriv...@arrive.no

  I just noticed that after upgrading to rc2, my some of my texts like
  håndteret kald when getting saved/posted becomes this: hÃ¥ndteret
 kald..

 Charset issue, they get posted as UTF-8; you probably  either need to test
 for charset or assume UTF-8 across the board.

 - Tor Iver

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org

Re: [1.5.0-rc2] possible bug with danish characters

[nino martinez wael]

anyone have an idea why changing from rc1 to rc2 would have an have an
impact on this..? There was no issue that looked related to me (in the
change log).

2011/3/2 nino martinez wael nino.martinez.w...@gmail.com

 Charset are UTF8... Anyhow there's no problem on rc1..

 2011/3/2 Wilhelmsen Tor Iver toriv...@arrive.no

  I just noticed that after upgrading to rc2, my some of my texts like
  håndteret kald when getting saved/posted becomes this: hÃ¥ndteret
 kald..

 Charset issue, they get posted as UTF-8; you probably  either need to test
 for charset or assume UTF-8 across the board.

 - Tor Iver

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org

Re: [1.5.0-rc2] possible bug with danish characters

[Martin Grigorov]

quickstart will help us to debug it.
attach it to jira
thanks!

On Wed, Mar 2, 2011 at 3:16 PM, nino martinez wael 
nino.martinez.w...@gmail.com wrote:

 anyone have an idea why changing from rc1 to rc2 would have an have an
 impact on this..? There was no issue that looked related to me (in the
 change log).

 2011/3/2 nino martinez wael nino.martinez.w...@gmail.com

  Charset are UTF8... Anyhow there's no problem on rc1..
 
  2011/3/2 Wilhelmsen Tor Iver toriv...@arrive.no
 
   I just noticed that after upgrading to rc2, my some of my texts like
   håndteret kald when getting saved/posted becomes this: hÃ¥ndteret
  kald..
 
  Charset issue, they get posted as UTF-8; you probably  either need to
 test
  for charset or assume UTF-8 across the board.
 
  - Tor Iver
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 

Re: [1.5.0-rc2] possible bug with danish characters

[nino martinez wael]

is there a server somewhere where rc2 live examples are running on?


2011/3/2 Martin Grigorov mgrigo...@apache.org

 quickstart will help us to debug it.
 attach it to jira
 thanks!

 On Wed, Mar 2, 2011 at 3:16 PM, nino martinez wael 
 nino.martinez.w...@gmail.com wrote:

  anyone have an idea why changing from rc1 to rc2 would have an have an
  impact on this..? There was no issue that looked related to me (in the
  change log).
 
  2011/3/2 nino martinez wael nino.martinez.w...@gmail.com
 
   Charset are UTF8... Anyhow there's no problem on rc1..
  
   2011/3/2 Wilhelmsen Tor Iver toriv...@arrive.no
  
I just noticed that after upgrading to rc2, my some of my texts like
håndteret kald when getting saved/posted becomes this: hÃ¥ndteret
   kald..
  
   Charset issue, they get posted as UTF-8; you probably  either need to
  test
   for charset or assume UTF-8 across the board.
  
   - Tor Iver
  
   -
   To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org
  
  
  
 

radio group stated not updated via AJAX. Possible bug?

[Ernesto Reinaldo Barreiro]

Hi,

Apologies for the somewhat lengthy e-mail.

Consider the following situation

1-I have a form with a RadioGroup, several Radio buttons, an AJAX
submit button and some AJAX links that fetch information that can be
used to repaint the form and the RadioGroup.

In simplified code more or less this.

public class RadioPage extends WebPage  {

private static final long serialVersionUID = 1L;

private WebMarkupContainer context;

private Gender gender;

private FeedbackPanel feedbackPanel;

public RadioPage() {
  FormVoid form = new FormVoid(form);
  add(form);
  context = new WebMarkupContainer(context);
  context.setOutputMarkupId(true);
  form.add(context);


RadioGroupGender gender = new RadioGroupGender(gender,
new PropertyModelGender(this,gender));

gender.setRequired(true);
context.add(gender);
// hombre
RadioGender sexoH = new RadioGender(male, new
ModelGender(Gender.MALE), gender);
gender.add(sexoH);

RadioGender sexoM = new RadioGender(female, new
ModelGender(Gender.FEMALE), gender);
gender.add(sexoM);

add(new AjaxLinkVoid(makeMale) {

private static final long serialVersionUID = 1L;

@Override
public void onClick(AjaxRequestTarget target) {
RadioPage.this.gender = Gender.MALE;
if(target != null) {
target.addComponent(context);
}
}
});

add(new AjaxLinkVoid(makeFemale) {

private static final long serialVersionUID = 1L;

@Override
public void onClick(AjaxRequestTarget target) {
RadioPage.this.gender = Gender.FEMALE;
if(target != null) {
target.addComponent(context);
}
}
});

form.add(new AjaxSubmitLink(submit) {

private static final long serialVersionUID = 1L;

@Override
protected void onSubmit(AjaxRequestTarget target, 
Form? form) {
form.info(Gender was set to  + 
RadioPage.this.gender);
target.addComponent(feedbackPanel);
}

@Override
protected void onError(AjaxRequestTarget target, 
Form? form) {
target.addComponent(feedbackPanel);
}
});

feedbackPanel = new FeedbackPanel(feedback);
feedbackPanel.setOutputMarkupId(true);
add(feedbackPanel);
}

public Gender getGender() {
return gender;
}

public void setGender(Gender gender) {
this.gender = gender;
}
}

-RadioPage.html--

html 
xmlns:wicket=http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd;
head
titleTest/title
/head
body
form wicket:id=form
div wicket:id=context
span wicket:id=gender
input type=radio wicket:id=male/
label for=radio3Male/label
input type=radio wicket:id=female/
label for=radio4Female/label
/span
/div
input wicket:id=submit type=submit value=AJAX 
submit/   
/form
span wicket:id=feedback/span
p
Updating RadioGroup via AJAX does not work:
a wicket:id=makeMaleMake male/a and a
wicket:id=makeFemaleMake female/a.
/p
/body
/html

and

public enum Gender {
FEMALE,
MALE;   
}


2-You click on the AJAX submit button without selecting any of the
radio buttons. This seems to set the rawinput of  RadioGroup to null.
3-You click now on one of the AJAX links (Make male or Make female in
the example) in order to fetch the information  and repaint the form
via AJAX. But radios checked condition is not updated:-(

This seems to be 

Re: radio group stated not updated via AJAX. Possible bug?

[Ernesto Reinaldo Barreiro]

I forgot to mentions this is with wicket 1.4.x.

Ernesto

On Thu, Dec 30, 2010 at 1:53 PM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
 Hi,

 Apologies for the somewhat lengthy e-mail.

 Consider the following situation

 1-I have a form with a RadioGroup, several Radio buttons, an AJAX
 submit button and some AJAX links that fetch information that can be
 used to repaint the form and the RadioGroup.

 In simplified code more or less this.

 public class RadioPage extends WebPage  {

        private static final long serialVersionUID = 1L;

        private WebMarkupContainer context;

        private Gender gender;

        private FeedbackPanel feedbackPanel;

        public RadioPage() {
              FormVoid form = new FormVoid(form);
              add(form);
              context = new WebMarkupContainer(context);
              context.setOutputMarkupId(true);
              form.add(context);


                RadioGroupGender gender = new RadioGroupGender(gender,
                                new PropertyModelGender(this,gender));

                gender.setRequired(true);
                context.add(gender);
                // hombre
                RadioGender sexoH = new RadioGender(male, new
 ModelGender(Gender.MALE), gender);
                gender.add(sexoH);

                RadioGender sexoM = new RadioGender(female, new
 ModelGender(Gender.FEMALE), gender);
                gender.add(sexoM);

                add(new AjaxLinkVoid(makeMale) {

                        private static final long serialVersionUID = 1L;

                       �...@override
                        public void onClick(AjaxRequestTarget target) {
                                RadioPage.this.gender = Gender.MALE;
                                if(target != null) {
                                        target.addComponent(context);
                                }
                        }
                });

                add(new AjaxLinkVoid(makeFemale) {

                        private static final long serialVersionUID = 1L;

                       �...@override
                        public void onClick(AjaxRequestTarget target) {
                                RadioPage.this.gender = Gender.FEMALE;
                                if(target != null) {
                                        target.addComponent(context);
                                }
                        }
                });

                form.add(new AjaxSubmitLink(submit) {

                        private static final long serialVersionUID = 1L;

                       �...@override
                        protected void onSubmit(AjaxRequestTarget target, 
 Form? form) {
                                form.info(Gender was set to  + 
 RadioPage.this.gender);
                                target.addComponent(feedbackPanel);
                        }

                       �...@override
                        protected void onError(AjaxRequestTarget target, 
 Form? form) {
                                target.addComponent(feedbackPanel);
                        }
                });

                feedbackPanel = new FeedbackPanel(feedback);
                feedbackPanel.setOutputMarkupId(true);
                add(feedbackPanel);
    }

        public Gender getGender() {
                return gender;
        }

        public void setGender(Gender gender) {
                this.gender = gender;
        }
 }

 -RadioPage.html--

 html 
 xmlns:wicket=http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd;
    head
        titleTest/title
    /head
    body
        form wicket:id=form
                div wicket:id=context
                        span wicket:id=gender
                                        input type=radio wicket:id=male/
                                        label for=radio3Male/label
                                        input type=radio 
 wicket:id=female/
                                        label for=radio4Female/label
                                /span
                        /div
                        input wicket:id=submit type=submit value=AJAX 
 submit/
                /form
                span wicket:id=feedback/span
                p
                        Updating RadioGroup via AJAX does not work:
                        a wicket:id=makeMaleMake male/a and a
 wicket:id=makeFemaleMake female/a.
                /p
    /body
 /html

 and

 public enum Gender {
        FEMALE,
        MALE;
 }


 2-You click on the AJAX submit button without selecting any of the
 radio buttons. This seems to set the rawinput of  RadioGroup to null.
 3-You click now on one of the AJAX links (Make male or Make female in
 the example) in order to fetch the information  and repaint the form
 via AJAX. But radios checked condition is not updated:-(

 This seems to be because of following code on Radio.onComponentTag():

                // compare the 

Re: radio group stated not updated via AJAX. Possible bug?

[Igor Vaynberg]

call clearinput() on the radiogroup so it refreshes based on new model
value you set.

-igor

On Thu, Dec 30, 2010 at 4:57 AM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
 I forgot to mentions this is with wicket 1.4.x.

 Ernesto

 On Thu, Dec 30, 2010 at 1:53 PM, Ernesto Reinaldo Barreiro
 reier...@gmail.com wrote:
 Hi,

 Apologies for the somewhat lengthy e-mail.

 Consider the following situation

 1-I have a form with a RadioGroup, several Radio buttons, an AJAX
 submit button and some AJAX links that fetch information that can be
 used to repaint the form and the RadioGroup.

 In simplified code more or less this.

 public class RadioPage extends WebPage  {

        private static final long serialVersionUID = 1L;

        private WebMarkupContainer context;

        private Gender gender;

        private FeedbackPanel feedbackPanel;

        public RadioPage() {
              FormVoid form = new FormVoid(form);
              add(form);
              context = new WebMarkupContainer(context);
              context.setOutputMarkupId(true);
              form.add(context);


                RadioGroupGender gender = new RadioGroupGender(gender,
                                new PropertyModelGender(this,gender));

                gender.setRequired(true);
                context.add(gender);
                // hombre
                RadioGender sexoH = new RadioGender(male, new
 ModelGender(Gender.MALE), gender);
                gender.add(sexoH);

                RadioGender sexoM = new RadioGender(female, new
 ModelGender(Gender.FEMALE), gender);
                gender.add(sexoM);

                add(new AjaxLinkVoid(makeMale) {

                        private static final long serialVersionUID = 1L;

                       �...@override
                        public void onClick(AjaxRequestTarget target) {
                                RadioPage.this.gender = Gender.MALE;
                                if(target != null) {
                                        target.addComponent(context);
                                }
                        }
                });

                add(new AjaxLinkVoid(makeFemale) {

                        private static final long serialVersionUID = 1L;

                       �...@override
                        public void onClick(AjaxRequestTarget target) {
                                RadioPage.this.gender = Gender.FEMALE;
                                if(target != null) {
                                        target.addComponent(context);
                                }
                        }
                });

                form.add(new AjaxSubmitLink(submit) {

                        private static final long serialVersionUID = 1L;

                       �...@override
                        protected void onSubmit(AjaxRequestTarget target, 
 Form? form) {
                                form.info(Gender was set to  + 
 RadioPage.this.gender);
                                target.addComponent(feedbackPanel);
                        }

                       �...@override
                        protected void onError(AjaxRequestTarget target, 
 Form? form) {
                                target.addComponent(feedbackPanel);
                        }
                });

                feedbackPanel = new FeedbackPanel(feedback);
                feedbackPanel.setOutputMarkupId(true);
                add(feedbackPanel);
    }

        public Gender getGender() {
                return gender;
        }

        public void setGender(Gender gender) {
                this.gender = gender;
        }
 }

 -RadioPage.html--

 html 
 xmlns:wicket=http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd;
    head
        titleTest/title
    /head
    body
        form wicket:id=form
                div wicket:id=context
                        span wicket:id=gender
                                        input type=radio wicket:id=male/
                                        label for=radio3Male/label
                                        input type=radio 
 wicket:id=female/
                                        label for=radio4Female/label
                                /span
                        /div
                        input wicket:id=submit type=submit value=AJAX 
 submit/
                /form
                span wicket:id=feedback/span
                p
                        Updating RadioGroup via AJAX does not work:
                        a wicket:id=makeMaleMake male/a and a
 wicket:id=makeFemaleMake female/a.
                /p
    /body
 /html

 and

 public enum Gender {
        FEMALE,
        MALE;
 }


 2-You click on the AJAX submit button without selecting any of the
 radio buttons. This seems to set the rawinput of  RadioGroup to null.
 3-You click now on one of the AJAX links (Make male or Make female in
 the example) in order to fetch the information  

Re: radio group stated not updated via AJAX. Possible bug?

[Ernesto Reinaldo Barreiro]

Igor,

Thanks for your answer. Yes, I thought about that possibility but
somehow it seems weird to me that you have to call clearinput() to get
the component update its state based on the model value: in particular
because other form components do not need that trick to work properly.
 Would the override

 public boolean isInputNullable() {
return false;
 }

have any other (undesirable) side effects? This solution has the
advantage that I can roll out my own AjaxUpdatebleRadioGroup and thus
I do not have remember to call clearinput() over and over.

Regards,

Ernesto

On Thu, Dec 30, 2010 at 3:29 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
 call clearinput() on the radiogroup so it refreshes based on new model
 value you set.

 -igor

 On Thu, Dec 30, 2010 at 4:57 AM, Ernesto Reinaldo Barreiro
 reier...@gmail.com wrote:
 I forgot to mentions this is with wicket 1.4.x.

 Ernesto

 On Thu, Dec 30, 2010 at 1:53 PM, Ernesto Reinaldo Barreiro
 reier...@gmail.com wrote:
 Hi,

 Apologies for the somewhat lengthy e-mail.

 Consider the following situation

 1-I have a form with a RadioGroup, several Radio buttons, an AJAX
 submit button and some AJAX links that fetch information that can be
 used to repaint the form and the RadioGroup.

 In simplified code more or less this.

 public class RadioPage extends WebPage  {

        private static final long serialVersionUID = 1L;

        private WebMarkupContainer context;

        private Gender gender;

        private FeedbackPanel feedbackPanel;

        public RadioPage() {
              FormVoid form = new FormVoid(form);
              add(form);
              context = new WebMarkupContainer(context);
              context.setOutputMarkupId(true);
              form.add(context);


                RadioGroupGender gender = new RadioGroupGender(gender,
                                new PropertyModelGender(this,gender));

                gender.setRequired(true);
                context.add(gender);
                // hombre
                RadioGender sexoH = new RadioGender(male, new
 ModelGender(Gender.MALE), gender);
                gender.add(sexoH);

                RadioGender sexoM = new RadioGender(female, new
 ModelGender(Gender.FEMALE), gender);
                gender.add(sexoM);

                add(new AjaxLinkVoid(makeMale) {

                        private static final long serialVersionUID = 1L;

                       �...@override
                        public void onClick(AjaxRequestTarget target) {
                                RadioPage.this.gender = Gender.MALE;
                                if(target != null) {
                                        target.addComponent(context);
                                }
                        }
                });

                add(new AjaxLinkVoid(makeFemale) {

                        private static final long serialVersionUID = 1L;

                       �...@override
                        public void onClick(AjaxRequestTarget target) {
                                RadioPage.this.gender = Gender.FEMALE;
                                if(target != null) {
                                        target.addComponent(context);
                                }
                        }
                });

                form.add(new AjaxSubmitLink(submit) {

                        private static final long serialVersionUID = 1L;

                       �...@override
                        protected void onSubmit(AjaxRequestTarget target, 
 Form? form) {
                                form.info(Gender was set to  + 
 RadioPage.this.gender);
                                target.addComponent(feedbackPanel);
                        }

                       �...@override
                        protected void onError(AjaxRequestTarget target, 
 Form? form) {
                                target.addComponent(feedbackPanel);
                        }
                });

                feedbackPanel = new FeedbackPanel(feedback);
                feedbackPanel.setOutputMarkupId(true);
                add(feedbackPanel);
    }

        public Gender getGender() {
                return gender;
        }

        public void setGender(Gender gender) {
                this.gender = gender;
        }
 }

 -RadioPage.html--

 html 
 xmlns:wicket=http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd;
    head
        titleTest/title
    /head
    body
        form wicket:id=form
                div wicket:id=context
                        span wicket:id=gender
                                        input type=radio 
 wicket:id=male/
                                        label for=radio3Male/label
                                        input type=radio 
 wicket:id=female/
                                        label for=radio4Female/label
                                /span
                        /div
                        

Re: radio group stated not updated via AJAX. Possible bug?

[Igor Vaynberg]

all components need that after they have been submitted once. how is
component to know that you have updated its model object? have you
called component.modelchanged()? clearinput() will do the same as
that.

-igor

On Thu, Dec 30, 2010 at 6:46 AM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
 Igor,

 Thanks for your answer. Yes, I thought about that possibility but
 somehow it seems weird to me that you have to call clearinput() to get
 the component update its state based on the model value: in particular
 because other form components do not need that trick to work properly.
  Would the override

  public boolean isInputNullable() {
        return false;
  }

 have any other (undesirable) side effects? This solution has the
 advantage that I can roll out my own AjaxUpdatebleRadioGroup and thus
 I do not have remember to call clearinput() over and over.

 Regards,

 Ernesto

 On Thu, Dec 30, 2010 at 3:29 PM, Igor Vaynberg igor.vaynb...@gmail.com 
 wrote:
 call clearinput() on the radiogroup so it refreshes based on new model
 value you set.

 -igor

 On Thu, Dec 30, 2010 at 4:57 AM, Ernesto Reinaldo Barreiro
 reier...@gmail.com wrote:
 I forgot to mentions this is with wicket 1.4.x.

 Ernesto

 On Thu, Dec 30, 2010 at 1:53 PM, Ernesto Reinaldo Barreiro
 reier...@gmail.com wrote:
 Hi,

 Apologies for the somewhat lengthy e-mail.

 Consider the following situation

 1-I have a form with a RadioGroup, several Radio buttons, an AJAX
 submit button and some AJAX links that fetch information that can be
 used to repaint the form and the RadioGroup.

 In simplified code more or less this.

 public class RadioPage extends WebPage  {

        private static final long serialVersionUID = 1L;

        private WebMarkupContainer context;

        private Gender gender;

        private FeedbackPanel feedbackPanel;

        public RadioPage() {
              FormVoid form = new FormVoid(form);
              add(form);
              context = new WebMarkupContainer(context);
              context.setOutputMarkupId(true);
              form.add(context);


                RadioGroupGender gender = new RadioGroupGender(gender,
                                new PropertyModelGender(this,gender));

                gender.setRequired(true);
                context.add(gender);
                // hombre
                RadioGender sexoH = new RadioGender(male, new
 ModelGender(Gender.MALE), gender);
                gender.add(sexoH);

                RadioGender sexoM = new RadioGender(female, new
 ModelGender(Gender.FEMALE), gender);
                gender.add(sexoM);

                add(new AjaxLinkVoid(makeMale) {

                        private static final long serialVersionUID = 1L;

                       �...@override
                        public void onClick(AjaxRequestTarget target) {
                                RadioPage.this.gender = Gender.MALE;
                                if(target != null) {
                                        target.addComponent(context);
                                }
                        }
                });

                add(new AjaxLinkVoid(makeFemale) {

                        private static final long serialVersionUID = 1L;

                       �...@override
                        public void onClick(AjaxRequestTarget target) {
                                RadioPage.this.gender = Gender.FEMALE;
                                if(target != null) {
                                        target.addComponent(context);
                                }
                        }
                });

                form.add(new AjaxSubmitLink(submit) {

                        private static final long serialVersionUID = 1L;

                       �...@override
                        protected void onSubmit(AjaxRequestTarget target, 
 Form? form) {
                                form.info(Gender was set to  + 
 RadioPage.this.gender);
                                target.addComponent(feedbackPanel);
                        }

                       �...@override
                        protected void onError(AjaxRequestTarget target, 
 Form? form) {
                                target.addComponent(feedbackPanel);
                        }
                });

                feedbackPanel = new FeedbackPanel(feedback);
                feedbackPanel.setOutputMarkupId(true);
                add(feedbackPanel);
    }

        public Gender getGender() {
                return gender;
        }

        public void setGender(Gender gender) {
                this.gender = gender;
        }
 }

 -RadioPage.html--

 html 
 xmlns:wicket=http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd;
    head
        titleTest/title
    /head
    body
        form wicket:id=form
                div wicket:id=context
                        span wicket:id=gender
                                        input type=radio 
 

Re: StalePageException and AJAX possible bug

[Michal Kurtak]

JIRA issue created https://issues.apache.org/jira/browse/WICKET-3252

2010/12/11 Martin Grigorov mgrigo...@apache.org:
 Yes, please.
 Create a ticket with a quickstart.
 Even better - with a patch ;-)

 On Sat, Dec 11, 2010 at 10:26 AM, Michal Kurtak 
 michal.kur...@gmail.comwrote:

 Hi,

 I have encountered a problem when using not versioned page with AJAX
 in multiple tabs/windows .

 Suppose I have ajax link which changes its model in non versioned
 page. I open the same page in new tab/window and click on the link.
 When i click the link in the first tab/window i get javascript error

 Wicket.Ajax: Wicket.Ajax.Call.failure: Error while parsing response:
 Could not find root ajax-response element
 This occurs because theres a hole page rendered in response
 (ajax-response element is missing)

 Should i create JIRA issue or is this a known bug?

 BR,
 Michal

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

StalePageException and AJAX possible bug

[Michal Kurtak]

Hi,

I have encountered a problem when using not versioned page with AJAX
in multiple tabs/windows .

Suppose I have ajax link which changes its model in non versioned
page. I open the same page in new tab/window and click on the link.
When i click the link in the first tab/window i get javascript error

Wicket.Ajax: Wicket.Ajax.Call.failure: Error while parsing response:
Could not find root ajax-response element
This occurs because theres a hole page rendered in response
(ajax-response element is missing)

Should i create JIRA issue or is this a known bug?

BR,
Michal

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: StalePageException and AJAX possible bug

[Martin Grigorov]

Yes, please.
Create a ticket with a quickstart.
Even better - with a patch ;-)

On Sat, Dec 11, 2010 at 10:26 AM, Michal Kurtak michal.kur...@gmail.comwrote:

 Hi,

 I have encountered a problem when using not versioned page with AJAX
 in multiple tabs/windows .

 Suppose I have ajax link which changes its model in non versioned
 page. I open the same page in new tab/window and click on the link.
 When i click the link in the first tab/window i get javascript error

 Wicket.Ajax: Wicket.Ajax.Call.failure: Error while parsing response:
 Could not find root ajax-response element
 This occurs because theres a hole page rendered in response
 (ajax-response element is missing)

 Should i create JIRA issue or is this a known bug?

 BR,
 Michal

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org

Simple Download from StringResourceStream cause NPE wicket 1.5M3 (possible bug??)

[jcgarciam]

Hi Folks,

Probably im doing it wrong, but please bear with me, currently i'm trying to
do a very simple download operation in wicket 1.5M3, but it fails with a NPE
in (ResourceStreamResource.java line 72), because it seems is always
expecting that any IResourceStream implementation set the lastModifiedTime 
in the underlying stream before calling dataNeedsToBeWritten which
StringResourceStream doesn't do it ( i need to explicitly set it to make it
work ) .

@Override
protected ResourceResponse newResourceResponse(Attributes attributes)
{
ResourceResponse data = new ResourceResponse();
(72)-  data.setLastModified(stream.lastModifiedTime().toDate());


My code using [StringResourceStream]
code
final StringBuilder content = new StringBuilder(Hello,world);
add(new LinkVoid(downloadDoc) {
@Override
public void onClick() {
StringResourceStream stream = new
StringResourceStream(content.toString(),html/csv);
getRequestCycle().scheduleRequestHandlerAfterCurrent(new
ResourceStreamRequestHandler(stream)
.setFileName(demo.csv)
.setContentDisposition(ContentDisposition.ATTACHMENT));
}
});
/code

Calling [stream.setLastModified(Time.now());] right before scheduling the
request handler make the download to works, but it seems that probably im
doing something wrong (not supposed to a download on this way) or does it
sounds like a bug in [ResourceStreamResource.java]? 

Thanks,

Attached is a quickstart
http://apache-wicket.1842946.n4.nabble.com/file/n3056036/DownloadStreamBug.7z
DownloadStreamBug.7z 


-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Simple-Download-from-StringResourceStream-cause-NPE-wicket-1-5M3-possible-bug-tp3056036p3056036.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Simple Download from StringResourceStream cause NPE wicket 1.5M3 (possible bug??)

[Martin Grigorov]

Looks like a bug.
I think StringResourceStream has to initialize its lastModifiedTime in the
constructor to Time.now().

I'll create a ticket and fix it.

On Tue, Nov 23, 2010 at 8:05 PM, jcgarciam jcgarc...@gmail.com wrote:


 Hi Folks,

 Probably im doing it wrong, but please bear with me, currently i'm trying
 to
 do a very simple download operation in wicket 1.5M3, but it fails with a
 NPE
 in (ResourceStreamResource.java line 72), because it seems is always
 expecting that any IResourceStream implementation set the lastModifiedTime
 in the underlying stream before calling dataNeedsToBeWritten which
 StringResourceStream doesn't do it ( i need to explicitly set it to make it
 work ) .

 @Override
protected ResourceResponse newResourceResponse(Attributes
 attributes)
{
ResourceResponse data = new ResourceResponse();
 (72)-  data.setLastModified(stream.lastModifiedTime().toDate());


 My code using [StringResourceStream]
 code
final StringBuilder content = new StringBuilder(Hello,world);
add(new LinkVoid(downloadDoc) {
@Override
public void onClick() {
StringResourceStream stream = new
 StringResourceStream(content.toString(),html/csv);

  getRequestCycle().scheduleRequestHandlerAfterCurrent(new
 ResourceStreamRequestHandler(stream)
.setFileName(demo.csv)

  .setContentDisposition(ContentDisposition.ATTACHMENT));
}
});
 /code

 Calling [stream.setLastModified(Time.now());] right before scheduling the
 request handler make the download to works, but it seems that probably im
 doing something wrong (not supposed to a download on this way) or does it
 sounds like a bug in [ResourceStreamResource.java]?

 Thanks,

 Attached is a quickstart

 http://apache-wicket.1842946.n4.nabble.com/file/n3056036/DownloadStreamBug.7z
 DownloadStreamBug.7z


 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Simple-Download-from-StringResourceStream-cause-NPE-wicket-1-5M3-possible-bug-tp3056036p3056036.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org

Re: Simple Download from StringResourceStream cause NPE wicket 1.5M3 (possible bug??)

[Martin Grigorov]

Done.
r1038292

On Tue, Nov 23, 2010 at 8:20 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 Looks like a bug.
 I think StringResourceStream has to initialize its lastModifiedTime in the
 constructor to Time.now().

 I'll create a ticket and fix it.


 On Tue, Nov 23, 2010 at 8:05 PM, jcgarciam jcgarc...@gmail.com wrote:


 Hi Folks,

 Probably im doing it wrong, but please bear with me, currently i'm trying
 to
 do a very simple download operation in wicket 1.5M3, but it fails with a
 NPE
 in (ResourceStreamResource.java line 72), because it seems is always
 expecting that any IResourceStream implementation set the lastModifiedTime
 in the underlying stream before calling dataNeedsToBeWritten which
 StringResourceStream doesn't do it ( i need to explicitly set it to make
 it
 work ) .

 @Override
protected ResourceResponse newResourceResponse(Attributes
 attributes)
{
ResourceResponse data = new ResourceResponse();
 (72)-  data.setLastModified(stream.lastModifiedTime().toDate());


 My code using [StringResourceStream]
 code
final StringBuilder content = new StringBuilder(Hello,world);
add(new LinkVoid(downloadDoc) {
@Override
public void onClick() {
StringResourceStream stream = new
 StringResourceStream(content.toString(),html/csv);

  getRequestCycle().scheduleRequestHandlerAfterCurrent(new
 ResourceStreamRequestHandler(stream)
.setFileName(demo.csv)

  .setContentDisposition(ContentDisposition.ATTACHMENT));
}
});
 /code

 Calling [stream.setLastModified(Time.now());] right before scheduling the
 request handler make the download to works, but it seems that probably im
 doing something wrong (not supposed to a download on this way) or does it
 sounds like a bug in [ResourceStreamResource.java]?

 Thanks,

 Attached is a quickstart

 http://apache-wicket.1842946.n4.nabble.com/file/n3056036/DownloadStreamBug.7z
 DownloadStreamBug.7z


 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Simple-Download-from-StringResourceStream-cause-NPE-wicket-1-5M3-possible-bug-tp3056036p3056036.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org

Re: Simple Download from StringResourceStream cause NPE wicket 1.5M3 (possible bug??)

[jcgarciam]

Hi Martin,

I explored the object hierarchy, and it seems *StringBufferResourceStream *may
suffer from the same problem, if its constructed and no append or prepend
method is called on it (which is a weird scenario of course).

Thanks!

On Tue, Nov 23, 2010 at 4:27 PM, Martin Grigorov-4 [via Apache Wicket] 
ml-node+3056080-692802461-65...@n4.nabble.comml-node%2b3056080-692802461-65...@n4.nabble.com
 wrote:

 Done.
 r1038292

 On Tue, Nov 23, 2010 at 8:20 PM, Martin Grigorov [hidden 
 email]http://user/SendEmail.jtp?type=nodenode=3056080i=0wrote:


  Looks like a bug.
  I think StringResourceStream has to initialize its lastModifiedTime in
 the
  constructor to Time.now().
 
  I'll create a ticket and fix it.
 
 
  On Tue, Nov 23, 2010 at 8:05 PM, jcgarciam [hidden 
  email]http://user/SendEmail.jtp?type=nodenode=3056080i=1
 wrote:
 
 
  Hi Folks,
 
  Probably im doing it wrong, but please bear with me, currently i'm
 trying
  to
  do a very simple download operation in wicket 1.5M3, but it fails with a

  NPE
  in (ResourceStreamResource.java line 72), because it seems is always
  expecting that any IResourceStream implementation set the
 lastModifiedTime
  in the underlying stream before calling dataNeedsToBeWritten which
  StringResourceStream doesn't do it ( i need to explicitly set it to make

  it
  work ) .
 
  @Override
 protected ResourceResponse newResourceResponse(Attributes
  attributes)
 {
 ResourceResponse data = new ResourceResponse();
  (72)-  data.setLastModified(stream.lastModifiedTime().toDate());
 
 
  My code using [StringResourceStream]
  code
 final StringBuilder content = new StringBuilder(Hello,world);
 add(new LinkVoid(downloadDoc) {
 @Override
 public void onClick() {
 StringResourceStream stream = new
  StringResourceStream(content.toString(),html/csv);
 
   getRequestCycle().scheduleRequestHandlerAfterCurrent(new
  ResourceStreamRequestHandler(stream)
 .setFileName(demo.csv)
 
   .setContentDisposition(ContentDisposition.ATTACHMENT));
 }
 });
  /code
 
  Calling [stream.setLastModified(Time.now());] right before scheduling
 the
  request handler make the download to works, but it seems that probably
 im
  doing something wrong (not supposed to a download on this way) or does
 it
  sounds like a bug in [ResourceStreamResource.java]?
 
  Thanks,
 
  Attached is a quickstart
 
 
 http://apache-wicket.1842946.n4.nabble.com/file/n3056036/DownloadStreamBug.7zhttp://apache-wicket.1842946.n4.nabble.com/file/n3056036/DownloadStreamBug.7z?by-user=t
  DownloadStreamBug.7z
 
 
  --
  View this message in context:
 
 http://apache-wicket.1842946.n4.nabble.com/Simple-Download-from-StringResourceStream-cause-NPE-wicket-1-5M3-possible-bug-tp3056036p3056036.htmlhttp://apache-wicket.1842946.n4.nabble.com/Simple-Download-from-StringResourceStream-cause-NPE-wicket-1-5M3-possible-bug-tp3056036p3056036.html?by-user=t
  Sent from the Users forum mailing list archive at Nabble.com.
 
  -
  To unsubscribe, e-mail: [hidden 
  email]http://user/SendEmail.jtp?type=nodenode=3056080i=2
  For additional commands, e-mail: [hidden 
  email]http://user/SendEmail.jtp?type=nodenode=3056080i=3
 
 
 


 --
  View message @
 http://apache-wicket.1842946.n4.nabble.com/Simple-Download-from-StringResourceStream-cause-NPE-wicket-1-5M3-possible-bug-tp3056036p3056080.html

 To unsubscribe from Simple Download from StringResourceStream cause NPE
 wicket 1.5M3 (possible bug??), click 
 herehttp://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3056036code=amNnYXJjaWFtQGdtYWlsLmNvbXwzMDU2MDM2fDEyNTYxMzc3ODY=.





-- 
Sincerely,
JC (http://www.linkedin.com/in/jcgarciam)
Work smarter, not harder!.

-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Simple-Download-from-StringResourceStream-cause-NPE-wicket-1-5M3-possible-bug-tp3056036p3056096.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Simple Download from StringResourceStream cause NPE wicket 1.5M3 (possible bug??)

[Martin Grigorov]

Covered by the fix ;-)
All classes
extending org.apache.wicket.util.resource.AbstractStringResourceStream will
have it initialized for free.

On Tue, Nov 23, 2010 at 8:37 PM, jcgarciam jcgarc...@gmail.com wrote:


 Hi Martin,

 I explored the object hierarchy, and it seems *StringBufferResourceStream
 *may
 suffer from the same problem, if its constructed and no append or prepend
 method is called on it (which is a weird scenario of course).

 Thanks!

 On Tue, Nov 23, 2010 at 4:27 PM, Martin Grigorov-4 [via Apache Wicket] 
 ml-node+3056080-692802461-65...@n4.nabble.comml-node%2b3056080-692802461-65...@n4.nabble.com
 ml-node%2b3056080-692802461-65...@n4.nabble.comml-node%252b3056080-692802461-65...@n4.nabble.com
 
  wrote:

  Done.
  r1038292
 
  On Tue, Nov 23, 2010 at 8:20 PM, Martin Grigorov [hidden email]
 http://user/SendEmail.jtp?type=nodenode=3056080i=0wrote:
 
 
   Looks like a bug.
   I think StringResourceStream has to initialize its lastModifiedTime in
  the
   constructor to Time.now().
  
   I'll create a ticket and fix it.
  
  
   On Tue, Nov 23, 2010 at 8:05 PM, jcgarciam [hidden email]
 http://user/SendEmail.jtp?type=nodenode=3056080i=1
  wrote:
  
  
   Hi Folks,
  
   Probably im doing it wrong, but please bear with me, currently i'm
  trying
   to
   do a very simple download operation in wicket 1.5M3, but it fails with
 a
 
   NPE
   in (ResourceStreamResource.java line 72), because it seems is always
   expecting that any IResourceStream implementation set the
  lastModifiedTime
   in the underlying stream before calling dataNeedsToBeWritten which
   StringResourceStream doesn't do it ( i need to explicitly set it to
 make
 
   it
   work ) .
  
   @Override
  protected ResourceResponse newResourceResponse(Attributes
   attributes)
  {
  ResourceResponse data = new ResourceResponse();
   (72)-  data.setLastModified(stream.lastModifiedTime().toDate());
  
  
   My code using [StringResourceStream]
   code
  final StringBuilder content = new StringBuilder(Hello,world);
  add(new LinkVoid(downloadDoc) {
  @Override
  public void onClick() {
  StringResourceStream stream = new
   StringResourceStream(content.toString(),html/csv);
  
getRequestCycle().scheduleRequestHandlerAfterCurrent(new
   ResourceStreamRequestHandler(stream)
  .setFileName(demo.csv)
  
.setContentDisposition(ContentDisposition.ATTACHMENT));
  }
  });
   /code
  
   Calling [stream.setLastModified(Time.now());] right before scheduling
  the
   request handler make the download to works, but it seems that probably
  im
   doing something wrong (not supposed to a download on this way) or does
  it
   sounds like a bug in [ResourceStreamResource.java]?
  
   Thanks,
  
   Attached is a quickstart
  
  
 
 http://apache-wicket.1842946.n4.nabble.com/file/n3056036/DownloadStreamBug.7z
 
 http://apache-wicket.1842946.n4.nabble.com/file/n3056036/DownloadStreamBug.7z?by-user=t
 
   DownloadStreamBug.7z
  
  
   --
   View this message in context:
  
 
 http://apache-wicket.1842946.n4.nabble.com/Simple-Download-from-StringResourceStream-cause-NPE-wicket-1-5M3-possible-bug-tp3056036p3056036.html
 
 http://apache-wicket.1842946.n4.nabble.com/Simple-Download-from-StringResourceStream-cause-NPE-wicket-1-5M3-possible-bug-tp3056036p3056036.html?by-user=t
 
   Sent from the Users forum mailing list archive at Nabble.com.
  
   -
   To unsubscribe, e-mail: [hidden email]
 http://user/SendEmail.jtp?type=nodenode=3056080i=2
   For additional commands, e-mail: [hidden email]
 http://user/SendEmail.jtp?type=nodenode=3056080i=3
  
  
  
 
 
  --
   View message @
 
 http://apache-wicket.1842946.n4.nabble.com/Simple-Download-from-StringResourceStream-cause-NPE-wicket-1-5M3-possible-bug-tp3056036p3056080.html
 
  To unsubscribe from Simple Download from StringResourceStream cause NPE
  wicket 1.5M3 (possible bug??), click here
 http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3056036code=amNnYXJjaWFtQGdtYWlsLmNvbXwzMDU2MDM2fDEyNTYxMzc3ODY=
 .
 
 



 --
 Sincerely,
 JC (http://www.linkedin.com/in/jcgarciam)
 Work smarter, not harder!.

 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Simple-Download-from-StringResourceStream-cause-NPE-wicket-1-5M3-possible-bug-tp3056036p3056096.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org

Re: Simple Download from StringResourceStream cause NPE wicket 1.5M3 (possible bug??)

[jcgarciam]

Great, exactly what i had in mind :)

Thanks.

On Tue, Nov 23, 2010 at 4:42 PM, Martin Grigorov-4 [via Apache Wicket] 
ml-node+3056108-1056044911-65...@n4.nabble.comml-node%2b3056108-1056044911-65...@n4.nabble.com
 wrote:

 Covered by the fix ;-)
 All classes
 extending org.apache.wicket.util.resource.AbstractStringResourceStream will

 have it initialized for free.

 On Tue, Nov 23, 2010 at 8:37 PM, jcgarciam [hidden 
 email]http://user/SendEmail.jtp?type=nodenode=3056108i=0
 wrote:

 
  Hi Martin,
 
  I explored the object hierarchy, and it seems *StringBufferResourceStream

  *may
  suffer from the same problem, if its constructed and no append or prepend

  method is called on it (which is a weird scenario of course).
 
  Thanks!
 
  On Tue, Nov 23, 2010 at 4:27 PM, Martin Grigorov-4 [via Apache Wicket] 
  [hidden email] 
  http://user/SendEmail.jtp?type=nodenode=3056108i=1[hidden
 email] http://user/SendEmail.jtp?type=nodenode=3056108i=2
  [hidden email] 
  http://user/SendEmail.jtp?type=nodenode=3056108i=3[hidden
 email] http://user/SendEmail.jtp?type=nodenode=3056108i=4
  
   wrote:
 
   Done.
   r1038292
  
   On Tue, Nov 23, 2010 at 8:20 PM, Martin Grigorov [hidden email]
  http://user/SendEmail.jtp?type=nodenode=3056080i=0wrote:
  
  
Looks like a bug.
I think StringResourceStream has to initialize its lastModifiedTime
 in
   the
constructor to Time.now().
   
I'll create a ticket and fix it.
   
   
On Tue, Nov 23, 2010 at 8:05 PM, jcgarciam [hidden email]
  http://user/SendEmail.jtp?type=nodenode=3056080i=1
   wrote:
   
   
Hi Folks,
   
Probably im doing it wrong, but please bear with me, currently i'm
   trying
to
do a very simple download operation in wicket 1.5M3, but it fails
 with
  a
  
NPE
in (ResourceStreamResource.java line 72), because it seems is always

expecting that any IResourceStream implementation set the
   lastModifiedTime
in the underlying stream before calling dataNeedsToBeWritten which
StringResourceStream doesn't do it ( i need to explicitly set it to
  make
  
it
work ) .
   
@Override
   protected ResourceResponse newResourceResponse(Attributes
attributes)
   {
   ResourceResponse data = new ResourceResponse();
(72)-  data.setLastModified(stream.lastModifiedTime().toDate());
   
   
My code using [StringResourceStream]
code
   final StringBuilder content = new
 StringBuilder(Hello,world);
   add(new LinkVoid(downloadDoc) {
   @Override
   public void onClick() {
   StringResourceStream stream = new
StringResourceStream(content.toString(),html/csv);
   
 getRequestCycle().scheduleRequestHandlerAfterCurrent(new
ResourceStreamRequestHandler(stream)
   .setFileName(demo.csv)
   
 .setContentDisposition(ContentDisposition.ATTACHMENT));
   }
   });
/code
   
Calling [stream.setLastModified(Time.now());] right before
 scheduling
   the
request handler make the download to works, but it seems that
 probably
   im
doing something wrong (not supposed to a download on this way) or
 does
   it
sounds like a bug in [ResourceStreamResource.java]?
   
Thanks,
   
Attached is a quickstart
   
   
  
 
 http://apache-wicket.1842946.n4.nabble.com/file/n3056036/DownloadStreamBug.7zhttp://apache-wicket.1842946.n4.nabble.com/file/n3056036/DownloadStreamBug.7z?by-user=t
  
 
 http://apache-wicket.1842946.n4.nabble.com/file/n3056036/DownloadStreamBug.7z?by-user=thttp://apache-wicket.1842946.n4.nabble.com/file/n3056036/DownloadStreamBug.7z?by-user=tby-user=t

  
DownloadStreamBug.7z
   
   
--
View this message in context:
   
  
 
 http://apache-wicket.1842946.n4.nabble.com/Simple-Download-from-StringResourceStream-cause-NPE-wicket-1-5M3-possible-bug-tp3056036p3056036.htmlhttp://apache-wicket.1842946.n4.nabble.com/Simple-Download-from-StringResourceStream-cause-NPE-wicket-1-5M3-possible-bug-tp3056036p3056036.html?by-user=t
  
 
 http://apache-wicket.1842946.n4.nabble.com/Simple-Download-from-StringResourceStream-cause-NPE-wicket-1-5M3-possible-bug-tp3056036p3056036.html?by-user=thttp://apache-wicket.1842946.n4.nabble.com/Simple-Download-from-StringResourceStream-cause-NPE-wicket-1-5M3-possible-bug-tp3056036p3056036.html?by-user=tby-user=t

  
Sent from the Users forum mailing list archive at Nabble.com.
   
   
 -
To unsubscribe, e-mail: [hidden email]
  http://user/SendEmail.jtp?type=nodenode=3056080i=2
For additional commands, e-mail: [hidden email]
  http://user/SendEmail.jtp?type=nodenode=3056080i=3
   
   
   
  
  
   --
View message @
  
 
 http://apache-wicket.1842946.n4.nabble.com/Simple-Download-from-StringResourceStream-cause-NPE-wicket-1-5M3-possible-bug-tp3056036p3056080.htmlhttp

Possible bug in HttpsRequestCycleProcessor?

[Thomas Götz]

In HttpsRequestCycleProcessor, line 214 (Wicket 1.4.10):

Session.get().bind();

With the comment that the session needs to be persisted before 
redirecting to https. But this is called before checking if a redirect 
is necessary or not (line 217, request could already be https). Result: 
no temporary sessions.


In our scenario this causes severe trouble:
we have a Tomcat cluster consisting of 3 different nodes, every request 
to a page is loadbalanced between these 3 nodes (loading of resource 
files for that page, i.e. images/css/js). The Tomcats are configured to 
use jsessionid for session management. As requests to resources 
referenced from within css files (images) do not contain jsessionid, a 
new session is created upon every single call to an image resource. With 
the Session.get().bind() as mentioned above (we use https for 
everything), this results in several new (not temporary) sessions for 
every single page ...


My proposal would be to call Session.get().bind() in line 200, where you 
are sure that a redirect is needed.


Or am I getting something wrong here?

Cheers,
   -Tom





-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Possible bug in HttpsRequestCycleProcessor?

[Thomas Götz]

Ah, I found https://issues.apache.org/jira/browse/WICKET-2629

   -Tom

On 16.09.2010 10:52, Thomas Götz wrote:

In HttpsRequestCycleProcessor, line 214 (Wicket 1.4.10):

Session.get().bind();

With the comment that the session needs to be persisted before
redirecting to https. But this is called before checking if a redirect
is necessary or not (line 217, request could already be https). Result:
no temporary sessions.

In our scenario this causes severe trouble:
we have a Tomcat cluster consisting of 3 different nodes, every request
to a page is loadbalanced between these 3 nodes (loading of resource
files for that page, i.e. images/css/js). The Tomcats are configured to
use jsessionid for session management. As requests to resources
referenced from within css files (images) do not contain jsessionid, a
new session is created upon every single call to an image resource. With
the Session.get().bind() as mentioned above (we use https for
everything), this results in several new (not temporary) sessions for
every single page ...

My proposal would be to call Session.get().bind() in line 200, where you
are sure that a redirect is needed.

Or am I getting something wrong here?

Cheers,
-Tom



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: possible bug?

[vladimir.kovalyuk]

There is JIRA issue for the problem 
https://issues.apache.org/jira/browse/WICKET-2933
https://issues.apache.org/jira/browse/WICKET-2933 

Igor I believe what you wrote works fine for single form. But when the page
contains nested forms the outer form still finds component - inner form.
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/possible-bug-tp1894220p2330830.html
Sent from the Wicket - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

possible bug?

[Vladimir Kovalyuk]

It seems the following trick does not work for nested forms:

protected void onRender(final MarkupStream markupStream)
{
// clear multipart hint, it will be set if necessary by the visitor
this.multiPart = ~MULTIPART_HINT;

// Force multi-part on if any child form component is multi-part
visitFormComponents(new FormComponent.AbstractVisitor()
{
@Override
public void onFormComponent(FormComponent? formComponent)
{
if (formComponent.isVisible() 
formComponent.isMultiPart())
{
multiPart |= MULTIPART_HINT;
}
}
});

super.onRender(markupStream);
}

Since multiPart is serializable it will remember multipart hint for the next
render on nested form even when the component tree does not contain file
upload component anymore. As the result the form will be multipart encoded
(see onComponentTag) but then handled with stardard request handler because
the hint in nested form is cleared only on its own onRender invocation.

Does it sound like a bug? Should I proceed with creating a test for that?

Re: possible bug?

[Igor Vaynberg]

the first thing it does is clear the multipart flag, it then tries to
find a multipart component which will set the flag to true again...so
if you remove the component that caused multipart to be true it would
reset before the render

-igor

On Wed, Mar 31, 2010 at 9:40 AM, Vladimir Kovalyuk koval...@gmail.com wrote:
 It seems the following trick does not work for nested forms:

    protected void onRender(final MarkupStream markupStream)
    {
        // clear multipart hint, it will be set if necessary by the visitor
        this.multiPart = ~MULTIPART_HINT;

        // Force multi-part on if any child form component is multi-part
        visitFormComponents(new FormComponent.AbstractVisitor()
        {
           �...@override
            public void onFormComponent(FormComponent? formComponent)
            {
                if (formComponent.isVisible() 
 formComponent.isMultiPart())
                {
                    multiPart |= MULTIPART_HINT;
                }
            }
        });

        super.onRender(markupStream);
    }

 Since multiPart is serializable it will remember multipart hint for the next
 render on nested form even when the component tree does not contain file
 upload component anymore. As the result the form will be multipart encoded
 (see onComponentTag) but then handled with stardard request handler because
 the hint in nested form is cleared only on its own onRender invocation.

 Does it sound like a bug? Should I proceed with creating a test for that?


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

possible bug in ComponentFeedBackPanel

[Fernando Wermus]

ComponentFeedBackPanel called to org.apache.wicket.util.lang.Objects.equals
to decide if there is a error message to show.

The implementation of this method is the following,

if (a == b)

{

return true;

}


 if ((a != null)  (b != null)  a.equals(b))

{

return true;

}


 return false;


For instance,


a is

[MarkupContainer [Component id = date]]

and in eclipse variables appears as [DateTextField id=460]


while


b is

[MarkupContainer [Component id = date]]

and in eclipse variables appears as [DateTextField id=463]

then this is returing false. This behavior only happens if the
ComponentFeedBackPanel
*is refreshed by ajax. ** *


I develop another class to test if I was misunderstanding the problem, but
it worked:


package com.misPartidos.web.eventos.paneles;


import org.apache.wicket.Component;

import org.apache.wicket.feedback.FeedbackMessage;

import org.apache.wicket.feedback.IFeedbackMessageFilter;

import org.apache.wicket.markup.html.panel.FeedbackPanel;


public class MyComponentFeedbackPanel extends FeedbackPanel {


 private static final long serialVersionUID = 1080609018238015083L;


 public MyComponentFeedbackPanel(String id, final Component filter) {

super(id);

setFilter(new IFeedbackMessageFilter(){

private static final long serialVersionUID = 3610826326194213455L;


 @Override

public boolean accept(FeedbackMessage message) {

final Component a=filter;

final Component b=message.getReporter();

if (a == b)

{

return true;

}

 if ((a!= null)  (b != null)  *a.getId().equals(b.getId()))*

{

return true;

}


 return false;

}

 });

}


}

I am just testing ids between a and b.

Does anyone has expirienced this wrong behavior with ComponentFeedBackPanel
in an ajax refreshed?

thanks in advance.


-- 
Fernando Wermus.

www.linkedin.com/in/fernandowermus

Re: possible bug in ComponentFeedBackPanel

[Martijn Dashorst]

Probably you are not refreshing the component but rather recreating
it. Hence the different eclipse debugger id's. If this is inside a
listview, setReuseItems(true)

This behavior is most certainly not a bug in the Objects.equals().

Martijn

On Wed, Mar 10, 2010 at 5:03 PM, Fernando Wermus
fernando.wer...@gmail.com wrote:
 ComponentFeedBackPanel called to org.apache.wicket.util.lang.Objects.equals
 to decide if there is a error message to show.

 The implementation of this method is the following,

 if (a == b)

 {

 return true;

 }


  if ((a != null)  (b != null)  a.equals(b))

 {

 return true;

 }


  return false;


 For instance,


 a is

 [MarkupContainer [Component id = date]]

 and in eclipse variables appears as [DateTextField id=460]


 while


 b is

 [MarkupContainer [Component id = date]]

 and in eclipse variables appears as [DateTextField id=463]

 then this is returing false. This behavior only happens if the
 ComponentFeedBackPanel
 *is refreshed by ajax. ** *


 I develop another class to test if I was misunderstanding the problem, but
 it worked:


 package com.misPartidos.web.eventos.paneles;


 import org.apache.wicket.Component;

 import org.apache.wicket.feedback.FeedbackMessage;

 import org.apache.wicket.feedback.IFeedbackMessageFilter;

 import org.apache.wicket.markup.html.panel.FeedbackPanel;


 public class MyComponentFeedbackPanel extends FeedbackPanel {


  private static final long serialVersionUID = 1080609018238015083L;


  public MyComponentFeedbackPanel(String id, final Component filter) {

 super(id);

 setFilter(new IFeedbackMessageFilter(){

 private static final long serialVersionUID = 3610826326194213455L;


 �...@override

 public boolean accept(FeedbackMessage message) {

 final Component a=filter;

 final Component b=message.getReporter();

 if (a == b)

 {

 return true;

 }

  if ((a!= null)  (b != null)  *a.getId().equals(b.getId()))*

 {

 return true;

 }


  return false;

 }

  });

 }


 }

 I am just testing ids between a and b.

 Does anyone has expirienced this wrong behavior with ComponentFeedBackPanel
 in an ajax refreshed?

 thanks in advance.


 --
 Fernando Wermus.

 www.linkedin.com/in/fernandowermus




-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: possible bug in ComponentFeedBackPanel

[Fernando Wermus]

Martijn,

I am recreating the components as you mentioned. But there is a line
which I dont understand in Objects.equals,

 if ((a != null)  (b != null)  a.equals(b))

I look for the implementation of equals in class Component and other classes
 and I havent found any. Then this is equivalent to do a==b.

Just for curiosity,
Are there any component which has an implementation of equals?
and,
why is not enought to compare id between components in
ComponentFeedbackMessageFilter.accept
instead of Objects.equals? Because I think I cant have more than a component
with the same id in same container.

thanks


On Wed, Mar 10, 2010 at 2:09 PM, Martijn Dashorst 
martijn.dasho...@gmail.com wrote:

 Probably you are not refreshing the component but rather recreating
 it. Hence the different eclipse debugger id's. If this is inside a
 listview, setReuseItems(true)

 This behavior is most certainly not a bug in the Objects.equals().

 Martijn

 On Wed, Mar 10, 2010 at 5:03 PM, Fernando Wermus
 fernando.wer...@gmail.com wrote:
  ComponentFeedBackPanel called to
 org.apache.wicket.util.lang.Objects.equals
  to decide if there is a error message to show.
 
  The implementation of this method is the following,
 
  if (a == b)
 
  {
 
  return true;
 
  }
 
 
   if ((a != null)  (b != null)  a.equals(b))
 
  {
 
  return true;
 
  }
 
 
   return false;
 
 
  For instance,
 
 
  a is
 
  [MarkupContainer [Component id = date]]
 
  and in eclipse variables appears as [DateTextField id=460]
 
 
  while
 
 
  b is
 
  [MarkupContainer [Component id = date]]
 
  and in eclipse variables appears as [DateTextField id=463]
 
  then this is returing false. This behavior only happens if the
  ComponentFeedBackPanel
  *is refreshed by ajax. ** *
 
 
  I develop another class to test if I was misunderstanding the problem,
 but
  it worked:
 
 
  package com.misPartidos.web.eventos.paneles;
 
 
  import org.apache.wicket.Component;
 
  import org.apache.wicket.feedback.FeedbackMessage;
 
  import org.apache.wicket.feedback.IFeedbackMessageFilter;
 
  import org.apache.wicket.markup.html.panel.FeedbackPanel;
 
 
  public class MyComponentFeedbackPanel extends FeedbackPanel {
 
 
   private static final long serialVersionUID = 1080609018238015083L;
 
 
   public MyComponentFeedbackPanel(String id, final Component filter) {
 
  super(id);
 
  setFilter(new IFeedbackMessageFilter(){
 
  private static final long serialVersionUID = 3610826326194213455L;
 
 
   @Override
 
  public boolean accept(FeedbackMessage message) {
 
  final Component a=filter;
 
  final Component b=message.getReporter();
 
  if (a == b)
 
  {
 
  return true;
 
  }
 
   if ((a!= null)  (b != null)  *a.getId().equals(b.getId()))*
 
  {
 
  return true;
 
  }
 
 
   return false;
 
  }
 
   });
 
  }
 
 
  }
 
  I am just testing ids between a and b.
 
  Does anyone has expirienced this wrong behavior with
 ComponentFeedBackPanel
  in an ajax refreshed?
 
  thanks in advance.
 
 
  --
  Fernando Wermus.
 
  www.linkedin.com/in/fernandowermus
 



 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.4 increases type safety for web applications
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-- 
Fernando Wermus.

www.linkedin.com/in/fernandowermus

Possible bug in interaction between FeedbackMessages and FeedbackMessagesModel

[Per Lundholm]

Hi!

I've bumped into a problem with feedback messages not being rendered and
given the warning about it in the log.

While tracing down how this really works, it is complicated I think, I
bumped into some code that looks a bit nasty to me. It may have effect on my
problem.

If the getObjcet method is called on FeedbackMessageModel is called, it
checks whether it has set its internal messages variable, else it asks the
current Session for messages.

public final ListFeedbackMessage getObject()
{
if (messages == null)
{
// Get filtered messages from page where component lives
messages = Session.get().getFeedbackMessages().messages(filter);

// Sort the list before returning it
if (sortingComparator != null)
{
Collections.sort(messages, sortingComparator);
}

// Let subclass do any extra processing it wants to on the
messages.
// It may want to do something special, such as removing a given
// message under some special condition or perhaps eliminate
// duplicate messages. It could even add a message under certain
// conditions.
messages = processMessages(messages);
}
return messages;
}

That means that it actually *cache* the address to the list of message. Ok,
why is that a good idea?

However, if we look how the Session returns the list of messages we see that
it will return what FeedbackMessages returns. And here comes the
interaction, FeedbackMessages returns the Collections.emptyList() if there
are no messages. In effect, FeedbackMessageModel is *caching* the address of
the Collections.emptyList() result.

If somebody later adds a message, FeedbackMesssageModel will be unaware of
that since it will keep looking at Collections.emtyList() that it has cached
and not take the trouble to ask FeedbackMessages again.

public final ListFeedbackMessage messages(final IFeedbackMessageFilter
filter)
{
if (messages.size() == 0)
{
return Collections.emptyList();
}

final ListFeedbackMessage list = new ArrayListFeedbackMessage();
for (final IteratorFeedbackMessage iterator = messages.iterator();
iterator.hasNext();)
{
final FeedbackMessage message = iterator.next();
if (filter == null || filter.accept(message))
{
list.add(message);
}
}
return list;
}

Now, I think it is complicated with how these feedback messages work, but
this does not look good, IMHO.

I am talking about 1.4rc6 and earlier versions as well.

Regards,
  Per

possible bug

[Serkan Camurcuoglu]

Hi all,
We need to have the oracle xml parser in our tomcat /lib/ directory since we 
have to use the client api of Oracle BPEL in our application.
But when using xml property files, I get the following exception if I use a 
comment inside the property file:

java.lang.ClassCastException: oracle.xml.parser.v2.XMLComment
at org.apache.wicket.util.io.Streams.loadFromXml(Streams.java:158)
at 
org.apache.wicket.resource.PropertiesFactory.loadPropertiesFile(PropertiesFactory.java:199)
at 
org.apache.wicket.resource.PropertiesFactory.loadPropertiesFileAndWatchForChanges(PropertiesFactory.java:289)
at 
org.apache.wicket.resource.PropertiesFactory.load(PropertiesFactory.java:118)
at 
org.apache.wicket.resource.loader.ComponentStringResourceLoader.loadStringResource(ComponentStringResourceLoader.java:148)
at 
org.apache.wicket.resource.loader.ComponentStringResourceLoader.loadStringResource(ComponentStringResourceLoader.java:225)
at org.apache.wicket.Localizer.getString(Localizer.java:225)
at org.apache.wicket.Localizer.getString(Localizer.java:116)
at org.apache.wicket.Component.getString(Component.java:1807)
at org.apache.wicket.Component.getString(Component.java:1794)

I'm using wicket 1.3.4. Do you think I should open a jira issue for this?

Regards,

SerkanC



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: possible bug

[Martijn Dashorst]

Nope. This is not a bug in wicket, but a bug in your configuration or
the oracle parser. Either don't use the oracle xml parser, configure
it to use the correct DOM tree parser, ensure you can use another
parser next to the oracle parser or don't use xml property files.

Apparently XMLComment does not extend org.w3c.dom.Element

Martijn

On Tue, May 12, 2009 at 2:23 PM, Serkan Camurcuoglu
serkan.camurcuo...@telenity.com wrote:
 Hi all,
 We need to have the oracle xml parser in our tomcat /lib/ directory since we
 have to use the client api of Oracle BPEL in our application.
 But when using xml property files, I get the following exception if I use a
 comment inside the property file:

 java.lang.ClassCastException: oracle.xml.parser.v2.XMLComment
    at org.apache.wicket.util.io.Streams.loadFromXml(Streams.java:158)
    at
 org.apache.wicket.resource.PropertiesFactory.loadPropertiesFile(PropertiesFactory.java:199)
    at
 org.apache.wicket.resource.PropertiesFactory.loadPropertiesFileAndWatchForChanges(PropertiesFactory.java:289)
    at
 org.apache.wicket.resource.PropertiesFactory.load(PropertiesFactory.java:118)
    at
 org.apache.wicket.resource.loader.ComponentStringResourceLoader.loadStringResource(ComponentStringResourceLoader.java:148)
    at
 org.apache.wicket.resource.loader.ComponentStringResourceLoader.loadStringResource(ComponentStringResourceLoader.java:225)
    at org.apache.wicket.Localizer.getString(Localizer.java:225)
    at org.apache.wicket.Localizer.getString(Localizer.java:116)
    at org.apache.wicket.Component.getString(Component.java:1807)
    at org.apache.wicket.Component.getString(Component.java:1794)

 I'm using wicket 1.3.4. Do you think I should open a jira issue for this?

 Regards,

 SerkanC



 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org





-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.5 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Possible bug in FormComponent$MessageSource regarding resource string lookups

[Christian Oldiges]

Done: WICKET-1888


igor.vaynberg wrote:
 
 request for enhancement. add it to our jria.
 
 -igor
 
 

-- 
View this message in context: 
http://www.nabble.com/Possible-bug-in-FormComponent%24MessageSource-regarding-resource-string-lookups-tp19951394p20130775.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Possible bug in FormComponent$MessageSource regarding resource string lookups

[Per Newgro]

Am Montag, 13. Oktober 2008 11:28:07 schrieb Christian Oldiges:
 Hello!

 First here is my setup and the situation in which I discovered the problem
 which might be a bug in FormComponent$MessageSource:

 I am using v1.3.4 and I have a problem placing a resource string for a
 customized subclass of CheckBox.

 My component tree looks like this:

 page.form.main.data

 -page is a subclass of WebPage, the page.html file contains several
 wicket:fragment tags which are used to create a wizard style UI
 -form is a Form object
 -main is a Fragment object
 -data is a customized subclass of CheckBox

 Now my problem:

 We have created the CheckBox subclass because it contains spezialized
 behaviour and we need customized error messages, especially for the case
 when the checkbox is NOT marked by the user when the form is submitted.

 For that reason we created a data.xml next to the data.class which is
 supposed to contain the error messages. Now, the data component marks
 itself as required and thus triggers a Required error resource key lookup
 upon form validation when the checkbox wasnt checked.

 I was surprised to find that the Required key is never ever tried on the
 data.xml resource file, so I fired up the debugger to check out whats
 happening and I think the problem is located in

 FormComponent$MessageSource.getMessage(String key):

 ---
--- public String getMessage(String key)
   {
   final FormComponent formComponent = FormComponent.this;

   // retrieve prefix that will be used to construct 
 message keys
   String prefix = formComponent.getValidatorKeyPrefix();
   if (Strings.isEmpty(prefix))
   {
   prefix = ;
   }

   final Localizer localizer = 
 formComponent.getLocalizer();

   String resource = prefix + getId() + . + key;

   // First use the parent for resolving so that
   // form1.textfield1.Required can be used.

   // Note: It is important that the default value of  
 is provided
   // to getString() not to throw a 
 MissingResourceException or to
   // return a default string like [Warning: String ...
   String message = getString(localizer, resource,
 formComponent.getParent());

   // If not found, than ...
   if (Strings.isEmpty(message))
   {
   // Try a variation of the resource key

   resource = prefix + key;

   message = getString(localizer, resource, 
 formComponent.getParent());
   }
 ---
---

 This method is called with key=Required on the instance belonging to the
 data FormComponent.

 At first the id of the FormComponent is prefixed and getString() is called
 for the parent of the FormComponent. This would be data.Required and the
 component would be the main Fragment. That call doesnt return any useful
 value, which is expected.

 Now, the second call of the getString() method doesnt include any component
 id anymore in the resource key, so it is Required and is called again for
 the parent of the FormComponent. The getString() at some point gets into
 the ComponentStringResourceLoader class to the
 loadStringResource(component,key) method.

 key = Required and component is again the main Fragment and that is the
 problem IMO.

 The component stack created in loadStringResource contains:

 page, form and main but NOT the data component, so the key
 Required is never tried on the resource file data.xml.

 If the second getString call

   message = getString(localizer, resource, 
 formComponent.getParent());

 were changed like this:

   message = getString(localizer, resource, 
 formComponent);

 the component stack would go all the way down to the component itself and
 would not stop at the parent.


 Is this a bug or am I missing something regarding the lookup mechanism???



 BTW: Great job on the WiA book!!!

Small question for understanding: Did you set your own localizer? AFAIK wicket 
uses property files for localization and if it finds no file on the 
appropriate place it goes up the component hirarchie. So you would need a 
Data.properties file with the strings in it. Maybe im missed something.

Cheers
Per

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Possible bug in FormComponent$MessageSource regarding resource string lookups

[Igor Vaynberg]

first thing to get is that each getstring() traverses the hierarchy.
so first we try with id and then without just in case the user forgot.

the problem here is that formcomponents do not provide their own
resource bundles. you need to add an rfe to support this.
traditionally only top-level markup containers provide bundles, eg
page and panel.

-igor

On Mon, Oct 13, 2008 at 2:28 AM, Christian Oldiges [EMAIL PROTECTED] wrote:

 Hello!

 First here is my setup and the situation in which I discovered the problem
 which might be a bug in FormComponent$MessageSource:

 I am using v1.3.4 and I have a problem placing a resource string for a
 customized subclass of CheckBox.

 My component tree looks like this:

 page.form.main.data

 -page is a subclass of WebPage, the page.html file contains several
 wicket:fragment tags which are used to create a wizard style UI
 -form is a Form object
 -main is a Fragment object
 -data is a customized subclass of CheckBox

 Now my problem:

 We have created the CheckBox subclass because it contains spezialized
 behaviour and we need customized error messages, especially for the case
 when the checkbox is NOT marked by the user when the form is submitted.

 For that reason we created a data.xml next to the data.class which is
 supposed to contain the error messages. Now, the data component marks itself
 as required and thus triggers a Required error resource key lookup upon
 form validation when the checkbox wasnt checked.

 I was surprised to find that the Required key is never ever tried on the
 data.xml resource file, so I fired up the debugger to check out whats
 happening and I think the problem is located in

 FormComponent$MessageSource.getMessage(String key):

 --
public String getMessage(String key)
{
final FormComponent formComponent = FormComponent.this;

// retrieve prefix that will be used to construct 
 message keys
String prefix = formComponent.getValidatorKeyPrefix();
if (Strings.isEmpty(prefix))
{
prefix = ;
}

final Localizer localizer = 
 formComponent.getLocalizer();

String resource = prefix + getId() + . + key;

// First use the parent for resolving so that
// form1.textfield1.Required can be used.

// Note: It is important that the default value of  
 is provided
// to getString() not to throw a 
 MissingResourceException or to
// return a default string like [Warning: String ...
String message = getString(localizer, resource,
 formComponent.getParent());

// If not found, than ...
if (Strings.isEmpty(message))
{
// Try a variation of the resource key

resource = prefix + key;

message = getString(localizer, resource, 
 formComponent.getParent());
}
 --

 This method is called with key=Required on the instance belonging to the
 data FormComponent.

 At first the id of the FormComponent is prefixed and getString() is called
 for the parent of the FormComponent. This would be data.Required and the
 component would be the main Fragment. That call doesnt return any useful
 value, which is expected.

 Now, the second call of the getString() method doesnt include any component
 id anymore in the resource key, so it is Required and is called again for
 the parent of the FormComponent. The getString() at some point gets into the
 ComponentStringResourceLoader class to the loadStringResource(component,key)
 method.

 key = Required and component is again the main Fragment and that is the
 problem IMO.

 The component stack created in loadStringResource contains:

 page, form and main but NOT the data component, so the key
 Required is never tried on the resource file data.xml.

 If the second getString call

message = getString(localizer, resource, 
 formComponent.getParent());

 were changed like this:

message = getString(localizer, resource, 
 formComponent);

 the component stack would go all the way down to the component itself and
 would not stop at the parent.


 Is this a bug or am I missing something regarding the lookup mechanism???



 BTW: Great job on the WiA book!!!
 --
 View this message in context: 
 http://www.nabble.com/Possible-bug-in-FormComponent%24MessageSource-regarding-resource-string-lookups-tp19951394p19951394.html
 Sent from

Re: Possible bug in FormComponent$MessageSource regarding resource string lookups

[Christian Oldiges]

 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Possible-bug-in-FormComponent%24MessageSource-regarding-resource-string-lookups-tp19951394p19957041.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Possible bug in FormComponent$MessageSource regarding resource string lookups

[Christian Oldiges]

 for
 the parent of the FormComponent. The getString() at some point gets into
 the
 ComponentStringResourceLoader class to the
 loadStringResource(component,key)
 method.

 key = Required and component is again the main Fragment and that is
 the
 problem IMO.

 The component stack created in loadStringResource contains:

 page, form and main but NOT the data component, so the key
 Required is never tried on the resource file data.xml.

 If the second getString call

message = getString(localizer, resource,
 formComponent.getParent());

 were changed like this:

message = getString(localizer, resource,
 formComponent);

 the component stack would go all the way down to the component itself and
 would not stop at the parent.


 Is this a bug or am I missing something regarding the lookup mechanism???



 BTW: Great job on the WiA book!!!
 --
 View this message in context:
 http://www.nabble.com/Possible-bug-in-FormComponent%24MessageSource-regarding-resource-string-lookups-tp19951394p19951394.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Possible-bug-in-FormComponent%24MessageSource-regarding-resource-string-lookups-tp19951394p19957156.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Possible bug in FormComponent$MessageSource regarding resource string lookups

[Igor Vaynberg]

 of the getString() method doesnt include any
 component
 id anymore in the resource key, so it is Required and is called again
 for
 the parent of the FormComponent. The getString() at some point gets into
 the
 ComponentStringResourceLoader class to the
 loadStringResource(component,key)
 method.

 key = Required and component is again the main Fragment and that is
 the
 problem IMO.

 The component stack created in loadStringResource contains:

 page, form and main but NOT the data component, so the key
 Required is never tried on the resource file data.xml.

 If the second getString call

message = getString(localizer, resource,
 formComponent.getParent());

 were changed like this:

message = getString(localizer, resource,
 formComponent);

 the component stack would go all the way down to the component itself and
 would not stop at the parent.


 Is this a bug or am I missing something regarding the lookup mechanism???



 BTW: Great job on the WiA book!!!
 --
 View this message in context:
 http://www.nabble.com/Possible-bug-in-FormComponent%24MessageSource-regarding-resource-string-lookups-tp19951394p19951394.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 --
 View this message in context: 
 http://www.nabble.com/Possible-bug-in-FormComponent%24MessageSource-regarding-resource-string-lookups-tp19951394p19957156.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Possible bug in FormComponent$MessageSource regarding resource string lookups

[Christian Oldiges]

Hello!

First here is my setup and the situation in which I discovered the problem
which might be a bug in FormComponent$MessageSource:

I am using v1.3.4 and I have a problem placing a resource string for a
customized subclass of CheckBox.

My component tree looks like this:

page.form.main.data

-page is a subclass of WebPage, the page.html file contains several
wicket:fragment tags which are used to create a wizard style UI
-form is a Form object
-main is a Fragment object
-data is a customized subclass of CheckBox

Now my problem:

We have created the CheckBox subclass because it contains spezialized
behaviour and we need customized error messages, especially for the case
when the checkbox is NOT marked by the user when the form is submitted.

For that reason we created a data.xml next to the data.class which is
supposed to contain the error messages. Now, the data component marks itself
as required and thus triggers a Required error resource key lookup upon
form validation when the checkbox wasnt checked.

I was surprised to find that the Required key is never ever tried on the
data.xml resource file, so I fired up the debugger to check out whats
happening and I think the problem is located in 

FormComponent$MessageSource.getMessage(String key):

--
public String getMessage(String key)
{
final FormComponent formComponent = FormComponent.this;

// retrieve prefix that will be used to construct 
message keys
String prefix = formComponent.getValidatorKeyPrefix();
if (Strings.isEmpty(prefix))
{
prefix = ;
}

final Localizer localizer = 
formComponent.getLocalizer();

String resource = prefix + getId() + . + key;

// First use the parent for resolving so that
// form1.textfield1.Required can be used.

// Note: It is important that the default value of  
is provided
// to getString() not to throw a 
MissingResourceException or to
// return a default string like [Warning: String ...
String message = getString(localizer, resource,
formComponent.getParent());

// If not found, than ...
if (Strings.isEmpty(message))
{
// Try a variation of the resource key

resource = prefix + key;

message = getString(localizer, resource, 
formComponent.getParent());
}
--

This method is called with key=Required on the instance belonging to the
data FormComponent.

At first the id of the FormComponent is prefixed and getString() is called
for the parent of the FormComponent. This would be data.Required and the
component would be the main Fragment. That call doesnt return any useful
value, which is expected.

Now, the second call of the getString() method doesnt include any component
id anymore in the resource key, so it is Required and is called again for
the parent of the FormComponent. The getString() at some point gets into the
ComponentStringResourceLoader class to the loadStringResource(component,key)
method.

key = Required and component is again the main Fragment and that is the
problem IMO.

The component stack created in loadStringResource contains:

page, form and main but NOT the data component, so the key
Required is never tried on the resource file data.xml.

If the second getString call

message = getString(localizer, resource, 
formComponent.getParent());

were changed like this:

message = getString(localizer, resource, 
formComponent);

the component stack would go all the way down to the component itself and
would not stop at the parent.


Is this a bug or am I missing something regarding the lookup mechanism???



BTW: Great job on the WiA book!!!
-- 
View this message in context: 
http://www.nabble.com/Possible-bug-in-FormComponent%24MessageSource-regarding-resource-string-lookups-tp19951394p19951394.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Possible bug in Localizer?

[Jeremy Thomerson]

Please take a look at this and tell me what you think.  I'm on 1.4-m2
(haven't upgraded to m3 yet - but looking forward to it).

Localizer : 332
while (cursor != null)
{
buffer.append(-).append(cursor.getClass().getName());
buffer.append(:).append(cursor.getId());
cursor = cursor.getParent();
if (cursor instanceof Page)
break;
}

I think that the cursor = cursor.getParent(); needs to go after the if /
break check.  In my case, I have two subclasses of SomePage, each containing
SomePanel, which contains SomeOtherPanel, which has a label in it with
string resource model (same happens with wicket:message).  The cache key
ends up being
RESOURCE-KEY-SomeOtherPanelClassName:SomeOtherPanelWicketID-SomePanelClassName:SomeOtherPanelWicketID

If it were:
RESOURCE-KEY-SomeOtherPanelClassName:SomeOtherPanelWicketID-SomePanelClassName:SomeOtherPanelWicketID:SomePageTypeOne
and
RESOURCE-KEY-SomeOtherPanelClassName:SomeOtherPanelWicketID-SomePanelClassName:SomeOtherPanelWicketID:SomePageTypeTwo
then the resources would be looked up properly in SomePageTypeOne.properties
and SomePageTypeTwo.properties - which is the exact situation I have.

Is there a reason the page isn't included in the cache key?  This seems
suspicious to me.  There are many times that you might have the same
component tree, but in different pages, and need different resources loaded
for each, especially with naming patterns where your panels end up with
similar names across many pages.

I tried this by copying the code for Localizer to my local source tree and
changing it there - it works great.  Something must've changed in one of the
1.4 versions (I haven't looked to see where) because this used to work fine
for me, pulling the values from the correct properties files.

Thanks!
Jeremy Thomerson

Re: Possible bug in Localizer?

[Igor Vaynberg]

already fixed in m3

-igor

On Fri, Jul 25, 2008 at 10:41 PM, Jeremy Thomerson
[EMAIL PROTECTED] wrote:
 Please take a look at this and tell me what you think.  I'm on 1.4-m2
 (haven't upgraded to m3 yet - but looking forward to it).

 Localizer : 332
while (cursor != null)
{
buffer.append(-).append(cursor.getClass().getName());
buffer.append(:).append(cursor.getId());
cursor = cursor.getParent();
if (cursor instanceof Page)
break;
}

 I think that the cursor = cursor.getParent(); needs to go after the if /
 break check.  In my case, I have two subclasses of SomePage, each containing
 SomePanel, which contains SomeOtherPanel, which has a label in it with
 string resource model (same happens with wicket:message).  The cache key
 ends up being
 RESOURCE-KEY-SomeOtherPanelClassName:SomeOtherPanelWicketID-SomePanelClassName:SomeOtherPanelWicketID

 If it were:
 RESOURCE-KEY-SomeOtherPanelClassName:SomeOtherPanelWicketID-SomePanelClassName:SomeOtherPanelWicketID:SomePageTypeOne
 and
 RESOURCE-KEY-SomeOtherPanelClassName:SomeOtherPanelWicketID-SomePanelClassName:SomeOtherPanelWicketID:SomePageTypeTwo
 then the resources would be looked up properly in SomePageTypeOne.properties
 and SomePageTypeTwo.properties - which is the exact situation I have.

 Is there a reason the page isn't included in the cache key?  This seems
 suspicious to me.  There are many times that you might have the same
 component tree, but in different pages, and need different resources loaded
 for each, especially with naming patterns where your panels end up with
 similar names across many pages.

 I tried this by copying the code for Localizer to my local source tree and
 changing it there - it works great.  Something must've changed in one of the
 1.4 versions (I haven't looked to see where) because this used to work fine
 for me, pulling the values from the correct properties files.

 Thanks!
 Jeremy Thomerson


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Possible bug in Localizer?

[Jeremy Thomerson]

Sorry I missed it.  I was on the road, connected over my phone, and didn't
have the bandwidth to scour the code changes.

You guys are just too good!

THANKS!

Jeremy

On Sat, Jul 26, 2008 at 12:48 AM, Igor Vaynberg [EMAIL PROTECTED]
wrote:

 already fixed in m3

 -igor

 On Fri, Jul 25, 2008 at 10:41 PM, Jeremy Thomerson
 [EMAIL PROTECTED] wrote:
  Please take a look at this and tell me what you think.  I'm on 1.4-m2
  (haven't upgraded to m3 yet - but looking forward to it).
 
  Localizer : 332
 while (cursor != null)
 {
 buffer.append(-).append(cursor.getClass().getName());
 buffer.append(:).append(cursor.getId());
 cursor = cursor.getParent();
 if (cursor instanceof Page)
 break;
 }
 
  I think that the cursor = cursor.getParent(); needs to go after the if /
  break check.  In my case, I have two subclasses of SomePage, each
 containing
  SomePanel, which contains SomeOtherPanel, which has a label in it with
  string resource model (same happens with wicket:message).  The cache key
  ends up being
 
 RESOURCE-KEY-SomeOtherPanelClassName:SomeOtherPanelWicketID-SomePanelClassName:SomeOtherPanelWicketID
 
  If it were:
 
 RESOURCE-KEY-SomeOtherPanelClassName:SomeOtherPanelWicketID-SomePanelClassName:SomeOtherPanelWicketID:SomePageTypeOne
  and
 
 RESOURCE-KEY-SomeOtherPanelClassName:SomeOtherPanelWicketID-SomePanelClassName:SomeOtherPanelWicketID:SomePageTypeTwo
  then the resources would be looked up properly in
 SomePageTypeOne.properties
  and SomePageTypeTwo.properties - which is the exact situation I have.
 
  Is there a reason the page isn't included in the cache key?  This seems
  suspicious to me.  There are many times that you might have the same
  component tree, but in different pages, and need different resources
 loaded
  for each, especially with naming patterns where your panels end up with
  similar names across many pages.
 
  I tried this by copying the code for Localizer to my local source tree
 and
  changing it there - it works great.  Something must've changed in one of
 the
  1.4 versions (I haven't looked to see where) because this used to work
 fine
  for me, pulling the values from the correct properties files.
 
  Thanks!
  Jeremy Thomerson
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: Possible BUG - discrepancy in component.onBeforeRender and IBehavior.beforeRender.

[Matej Knopp]

Hi,

beforeRender on behavior has different semantics than onBeforeRender
on component. I agree that this is confusing and it i think it should
be improved in 1.4.

beforeRender and afterRender can be used to render markup before
component and after component output. Currently there is no method in
IBehavior that is invoked when component's onBeforeRender is called.

-Matej

On Thu, May 22, 2008 at 5:43 PM, gumnaam23 [EMAIL PROTECTED] wrote:

 The  following statement

 if (!component.isAuto()  getFlag(FLAG_RENDERING))

 in Component- checkHierarchyChange()

 returns false when a Behavior is added to the Component.onBeforeRender()
 phase, but returns true if
 a Behavior is added by another Behavior as part of it's beforeRender()
 phase.

 So
 new Component () {
  onBeforeRender() {
add(some behavior);
 }

 Works.

 but
 new Component().add(new AbstractBehavior() {

   beforeRender(Component c) {
 c.addBehavior(some behavior);
  }

 }

 doesn't work, as the getFlag(FLAG_RENDERING) returns false in the first case
 and true in the next case.
 So in the second case, I get an Exception.

 Is this an expected behavior or a possible bug ?




 --
 View this message in context: 
 http://www.nabble.com/Possible-BUG---discrepancy-in-component.onBeforeRender-and-IBehavior.beforeRender.-tp17407123p17407123.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Possible BUG - discrepancy in component.onBeforeRender and IBehavior.beforeRender.

[Johan Compagner]

and what is a good name? :)

On Fri, May 23, 2008 at 4:03 PM, Matej Knopp [EMAIL PROTECTED] wrote:

 Hi,

 beforeRender on behavior has different semantics than onBeforeRender
 on component. I agree that this is confusing and it i think it should
 be improved in 1.4.

 beforeRender and afterRender can be used to render markup before
 component and after component output. Currently there is no method in
 IBehavior that is invoked when component's onBeforeRender is called.

 -Matej

 On Thu, May 22, 2008 at 5:43 PM, gumnaam23 [EMAIL PROTECTED] wrote:
 
  The  following statement
 
  if (!component.isAuto()  getFlag(FLAG_RENDERING))
 
  in Component- checkHierarchyChange()
 
  returns false when a Behavior is added to the Component.onBeforeRender()
  phase, but returns true if
  a Behavior is added by another Behavior as part of it's beforeRender()
  phase.
 
  So
  new Component () {
   onBeforeRender() {
 add(some behavior);
  }
 
  Works.
 
  but
  new Component().add(new AbstractBehavior() {
 
beforeRender(Component c) {
  c.addBehavior(some behavior);
   }
 
  }
 
  doesn't work, as the getFlag(FLAG_RENDERING) returns false in the first
 case
  and true in the next case.
  So in the second case, I get an Exception.
 
  Is this an expected behavior or a possible bug ?
 
 
 
 
  --
  View this message in context:
 http://www.nabble.com/Possible-BUG---discrepancy-in-component.onBeforeRender-and-IBehavior.beforeRender.-tp17407123p17407123.html
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Possible BUG - discrepancy in component.onBeforeRender and IBehavior.beforeRender.

[gumnaam23]

The  following statement 

if (!component.isAuto()  getFlag(FLAG_RENDERING)) 

in Component- checkHierarchyChange()

returns false when a Behavior is added to the Component.onBeforeRender()
phase, but returns true if
a Behavior is added by another Behavior as part of it's beforeRender()
phase. 

So 
new Component () {
  onBeforeRender() {
add(some behavior);
}

Works.

but 
new Component().add(new AbstractBehavior() {
 
   beforeRender(Component c) {
 c.addBehavior(some behavior);
  }

}

doesn't work, as the getFlag(FLAG_RENDERING) returns false in the first case
and true in the next case.
So in the second case, I get an Exception.

Is this an expected behavior or a possible bug ?


  

-- 
View this message in context: 
http://www.nabble.com/Possible-BUG---discrepancy-in-component.onBeforeRender-and-IBehavior.beforeRender.-tp17407123p17407123.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: possible bug in 1.2.6 / 1.3 Include

[Al Maw]

Jeremy Levy wrote:

I found this while working on 1.2.6 and checked it out in 1.3 and it's the
same. It appears as though Include does not pay attention to the contextpath
if it is explicitly set.

Line 162 (In 1.2.6) or line 233 (in 1.3b4) of Include is the following line
which as I understands it builds a absolute URL from a relative path from
the model:

buildUrl.append(req.getContextPath()).append('/').append(url);

It's using the request's context path to build the absolute URL, if this is
behind a proxy it will fail, I changed my copy to this:

buildUrl.append
(getApplication().getApplicationSettings().getContextPath()).append('/').append(url);

Am I misunderstanding this?


Yeah, looks like a bug. Please open a JIRA issue and I'll look into it.

Regards,

Al

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

possible bug in 1.2.6 / 1.3 Include

[Jeremy Levy]

I found this while working on 1.2.6 and checked it out in 1.3 and it's the
same. It appears as though Include does not pay attention to the contextpath
if it is explicitly set.

Line 162 (In 1.2.6) or line 233 (in 1.3b4) of Include is the following line
which as I understands it builds a absolute URL from a relative path from
the model:

buildUrl.append(req.getContextPath()).append('/').append(url);

It's using the request's context path to build the absolute URL, if this is
behind a proxy it will fail, I changed my copy to this:

buildUrl.append
(getApplication().getApplicationSettings().getContextPath()).append('/').append(url);

Am I misunderstanding this?

Jeremy