Re: Possible bug / edge case found where page is not detached
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
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
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
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)
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)
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)
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)
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)
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)
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)
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?
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:
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: WicketTester's possible bug?
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?
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?
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.
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 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
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
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
Re: Possible bug with AjaxLazyLoadPanel
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 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/>
Possible bug with AjaxLazyLoadPanel
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]
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:
>
> *
> * NOTE:
> *
> * 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.
> *
> * 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.
> *
>
> 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:
> >
> >
> >
> >
> >
> >
> > 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 ListView {
> > /**
> > *
> > */
> > 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 IModel>(){
> >
> > /**
> > *
> > */
> > private static final long serialVersionUID = 1L;
> >
> > @Override
> > public void detach() {
> > // TODO Auto-generated method stub
> > }
> >
> > @Override
> > public List getObject() {
> > return region.getRegionWidgets();
> > }
> >
> > @Override
> > public void setObject(List 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...
> >
> >
> > ...
> >
> >
> >
> > 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]
Short answer is in ListView's javadoc:
*
* NOTE:
*
* 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.
*
* 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.
*
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:
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 ListView {
/**
*
*/
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 IModel>(){
/**
*
*/
private static final long serialVersionUID = 1L;
@Override
public void detach() {
// TODO Auto-generated method stub
}
@Override
public List getObject() {
return region.getRegionWidgets();
}
@Override
public void setObject(List 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...
...
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]
Try
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:
>
>
>
>
>
>
> 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 ListView {
> /**
> *
> */
> 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 IModel>(){
>
> /**
> *
> */
> private static final long serialVersionUID = 1L;
>
> @Override
> public void detach() {
> // TODO Auto-generated method stub
> }
>
> @Override
> public List getObject() {
> return region.getRegionWidgets();
> }
>
> @Override
> public void setObject(List 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...
>
>
> ...
>
>
>
> So, is this a bug or a feature?
>
>
--
Regards - Ernesto Reinaldo Barreiro
Antilia Soft
http://antiliasoft.com/
Possible bug in ListView [Cannot change attributes in ListView div]
Hello,
I think I found something that may not be working right.
I have an html that looks like:
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 ListView {
/**
*
*/
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 IModel>(){
/**
*
*/
private static final long serialVersionUID = 1L;
@Override
public void detach() {
// TODO Auto-generated method stub
}
@Override
public List getObject() {
return region.getRegionWidgets();
}
@Override
public void setObject(List 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...
...
So, is this a bug or a feature?
Re: UploadProgressBar Possible Bug
we already have a quickstart :) https://issues.apache.org/jira/browse/WICKET-3594 On Mon, Apr 4, 2011 at 6:10 PM, 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 > 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, 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: UploadProgressBar Possible Bug
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 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, 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
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, 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
UploadProgressBar Possible Bug
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: [1.5.0-rc2] possible bug with danish characters
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: ... http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> 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 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 > 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 > > > > > 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 > > > > > > > > > Charset are UTF8... Anyhow there's no problem on rc1.. > > > > > > > > > > 2011/3/2 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
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 > > > > > 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 > > > > > > > > > Charset are UTF8... Anyhow there's no problem on rc1.. > > > > > > > > > > 2011/3/2 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
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
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 > > > 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 > > > > > > > Charset are UTF8... Anyhow there's no problem on rc1.. > > > > > > > > 2011/3/2 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
is there a server somewhere where rc2 live examples are running on? 2011/3/2 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 > > > > > Charset are UTF8... Anyhow there's no problem on rc1.. > > > > > > 2011/3/2 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
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 > > > Charset are UTF8... Anyhow there's no problem on rc1.. > > > > 2011/3/2 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
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 > Charset are UTF8... Anyhow there's no problem on rc1.. > > 2011/3/2 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
Charset are UTF8... Anyhow there's no problem on rc1.. 2011/3/2 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
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 > 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
> 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
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: radio group stated not updated via AJAX. Possible bug?
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
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
> 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
>> 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
>>> 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() {
Form form = new Form("form");
add(form);
context = new WebMarkupContainer("context");
context.setOutputMarkupId(true);
form.add(context);
RadioGroup gender = new RadioGroup("gender",
new PropertyModel(this,"gender"));
gender.setRequired(true);
context.add(gender);
// hombre
Radio sexoH = new Radio("male", new
Model(Gender.MALE), gender);
gender.add(sexoH);
Radio sexoM = new Radio("female", new
Model(Gender.FEMALE), gender);
gender.add(sexoM);
add(new AjaxLink("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 AjaxLink("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;
}
}
---
Re: radio group stated not updated via AJAX. Possible bug?
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 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
> 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
>> 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() {
>>> Form form = new Form("form");
>>> add(form);
>>> context = new WebMarkupContainer("context");
>>> context.setOutputMarkupId(true);
>>> form.add(context);
>>>
>>>
>>> RadioGroup gender = new RadioGroup("gender",
>>> new PropertyModel(this,"gender"));
>>>
>>> gender.setRequired(true);
>>> context.add(gender);
>>> // hombre
>>> Radio sexoH = new Radio("male", new
>>> Model(Gender.MALE), gender);
>>> gender.add(sexoH);
>>>
>>> Radio sexoM = new Radio("female", new
>>> Model(Gender.FEMALE), gender);
>>> gender.add(sexoM);
>>>
>>> add(new AjaxLink("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 AjaxLink("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--
>>>
>>> >> xmlns:wicket="http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd";>
>>>
>>> Test
>>>
>>>
>>>
>>>
>>>
>>> >> wicket:id="male"/>
>>> Male
>>> >> wicket:id="female"/>
>>>
Re: radio group stated not updated via AJAX. Possible bug?
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
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
> 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() {
>> Form form = new Form("form");
>> add(form);
>> context = new WebMarkupContainer("context");
>> context.setOutputMarkupId(true);
>> form.add(context);
>>
>>
>> RadioGroup gender = new RadioGroup("gender",
>> new PropertyModel(this,"gender"));
>>
>> gender.setRequired(true);
>> context.add(gender);
>> // hombre
>> Radio sexoH = new Radio("male", new
>> Model(Gender.MALE), gender);
>> gender.add(sexoH);
>>
>> Radio sexoM = new Radio("female", new
>> Model(Gender.FEMALE), gender);
>> gender.add(sexoM);
>>
>> add(new AjaxLink("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 AjaxLink("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--
>>
>> > xmlns:wicket="http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd";>
>>
>> Test
>>
>>
>>
>>
>>
>>
>> Male
>> > wicket:id="female"/>
>> Female
>>
>>
>>
>>
>>
>>
>> Updating RadioGroup via AJAX does not work:
>> Make male and > wicket:id="makeFemale">Make female.
>>
>>
>>
>>
>> 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 be
Re: radio group stated not updated via AJAX. Possible bug?
I forgot to mentions this is with wicket 1.4.x.
Ernesto
On Thu, Dec 30, 2010 at 1:53 PM, Ernesto Reinaldo Barreiro
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() {
> Form form = new Form("form");
> add(form);
> context = new WebMarkupContainer("context");
> context.setOutputMarkupId(true);
> form.add(context);
>
>
> RadioGroup gender = new RadioGroup("gender",
> new PropertyModel(this,"gender"));
>
> gender.setRequired(true);
> context.add(gender);
> // hombre
> Radio sexoH = new Radio("male", new
> Model(Gender.MALE), gender);
> gender.add(sexoH);
>
> Radio sexoM = new Radio("female", new
> Model(Gender.FEMALE), gender);
> gender.add(sexoM);
>
> add(new AjaxLink("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 AjaxLink("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--
>
> xmlns:wicket="http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd";>
>
> Test
>
>
>
>
>
>
> Male
> wicket:id="female"/>
> Female
>
>
>
>
>
>
> Updating RadioGroup via AJAX does not work:
> Make male and wicket:id="makeFemale">Make female.
>
>
>
>
> 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 model objects of the group and self, if
> the same add the
> // checked attribute, first check if there was a raw input on
> the group.
> if (group.hasRawInput())
> {
>
radio group stated not updated via AJAX. Possible bug?
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() {
Form form = new Form("form");
add(form);
context = new WebMarkupContainer("context");
context.setOutputMarkupId(true);
form.add(context);
RadioGroup gender = new RadioGroup("gender",
new PropertyModel(this,"gender"));
gender.setRequired(true);
context.add(gender);
// hombre
Radio sexoH = new Radio("male", new
Model(Gender.MALE), gender);
gender.add(sexoH);
Radio sexoM = new Radio("female", new
Model(Gender.FEMALE), gender);
gender.add(sexoM);
add(new AjaxLink("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 AjaxLink("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--
http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd";>
Test
Male
Female
Updating RadioGroup via AJAX does not work:
Make male and Make female.
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 model objects of the group and self, if
the same add the
// checked attribute, first check if there was a raw input on
the group.
if (group.hasRawInput())
{
String rawInput = group.getRawInput();
if (rawInput != null && rawInput.eq
Re: StalePageException and AJAX possible bug
JIRA issue created https://issues.apache.org/jira/browse/WICKET-3252 2010/12/11 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 > wrote: > >> 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 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
Re: StalePageException and AJAX possible bug
Yes, please. Create a ticket with a quickstart. Even better - with a patch ;-) On Sat, Dec 11, 2010 at 10:26 AM, Michal Kurtak wrote: > 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 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 > >
StalePageException and AJAX possible bug
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 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: Simple Download from StringResourceStream cause NPE wicket 1.5M3 (possible bug??)
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.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=node&node=3056108&i=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=node&node=3056108&i=1><[hidden
> email] <http://user/SendEmail.jtp?type=node&node=3056108&i=2>>
> > <[hidden email]
> > <http://user/SendEmail.jtp?type=node&node=3056108&i=3><[hidden
> email] <http://user/SendEmail.jtp?type=node&node=3056108&i=4>>
> > >
> > > wrote:
> >
> > > Done.
> > > r1038292
> > >
> > > On Tue, Nov 23, 2010 at 8:20 PM, Martin Grigorov <[hidden email]<
> > http://user/SendEmail.jtp?type=node&node=3056080&i=0>>wrote:
> > >
> > >
> > > > 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=node&node=3056080&i=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]
> > > >>
> > > >>final StringBuilder content = new
> StringBuilder("Hello,world");
> > > >>add(new Link("downloadDoc") {
> > > >>@Override
> > > >>public void onClick() {
> > > >>StringResourceStream stream = new
> > > >> StringResourceStream(content.toString(),"html/csv");
> > > >>
> > > >> getRequestCycle().scheduleRequestHandlerAfterCurrent(new
> > > >> ResourceStreamRequestHandler(stream)
> > > >>.setFileName("demo.csv")
> > > >>
> > > >> .setContentDisposition(ContentDisposition.ATTACHMENT));
> > > >>}
> > > >>});
> > > >>
> > > >>
> > > >> 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]
Re: Simple Download from StringResourceStream cause NPE wicket 1.5M3 (possible bug??)
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 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.com
>
> >
> > wrote:
>
> > Done.
> > r1038292
> >
> > On Tue, Nov 23, 2010 at 8:20 PM, Martin Grigorov <[hidden email]<
> http://user/SendEmail.jtp?type=node&node=3056080&i=0>>wrote:
> >
> >
> > > 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=node&node=3056080&i=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]
> > >>
> > >>final StringBuilder content = new StringBuilder("Hello,world");
> > >>add(new Link("downloadDoc") {
> > >>@Override
> > >>public void onClick() {
> > >>StringResourceStream stream = new
> > >> StringResourceStream(content.toString(),"html/csv");
> > >>
> > >> getRequestCycle().scheduleRequestHandlerAfterCurrent(new
> > >> ResourceStreamRequestHandler(stream)
> > >>.setFileName("demo.csv")
> > >>
> > >> .setContentDisposition(ContentDisposition.ATTACHMENT));
> > >>}
> > >>});
> > >>
> > >>
> > >> 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=node&node=3056080&a
Re: Simple Download from StringResourceStream cause NPE wicket 1.5M3 (possible bug??)
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.com
> wrote:
> Done.
> r1038292
>
> On Tue, Nov 23, 2010 at 8:20 PM, Martin Grigorov <[hidden
> email]<http://user/SendEmail.jtp?type=node&node=3056080&i=0>>wrote:
>
>
> > 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=node&node=3056080&i=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]
> >>
> >>final StringBuilder content = new StringBuilder("Hello,world");
> >>add(new Link("downloadDoc") {
> >>@Override
> >>public void onClick() {
> >>StringResourceStream stream = new
> >> StringResourceStream(content.toString(),"html/csv");
> >>
> >> getRequestCycle().scheduleRequestHandlerAfterCurrent(new
> >> ResourceStreamRequestHandler(stream)
> >>.setFileName("demo.csv")
> >>
> >> .setContentDisposition(ContentDisposition.ATTACHMENT));
> >>}
> >>});
> >>
> >>
> >> 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=node&node=3056080&i=2>
> >> For additional commands, e-mail: [hidden
> >> email]<http://user/SendEmail.jtp?type=node&node=3056080&i=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_code&node=3056036&code=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??)
Done.
r1038292
On Tue, Nov 23, 2010 at 8:20 PM, Martin Grigorov wrote:
> 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 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]
>>
>>final StringBuilder content = new StringBuilder("Hello,world");
>>add(new Link("downloadDoc") {
>>@Override
>>public void onClick() {
>>StringResourceStream stream = new
>> StringResourceStream(content.toString(),"html/csv");
>>
>> getRequestCycle().scheduleRequestHandlerAfterCurrent(new
>> ResourceStreamRequestHandler(stream)
>>.setFileName("demo.csv")
>>
>> .setContentDisposition(ContentDisposition.ATTACHMENT));
>>}
>>});
>>
>>
>> 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??)
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 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]
>
>final StringBuilder content = new StringBuilder("Hello,world");
>add(new Link("downloadDoc") {
>@Override
>public void onClick() {
>StringResourceStream stream = new
> StringResourceStream(content.toString(),"html/csv");
>
> getRequestCycle().scheduleRequestHandlerAfterCurrent(new
> ResourceStreamRequestHandler(stream)
>.setFileName("demo.csv")
>
> .setContentDisposition(ContentDisposition.ATTACHMENT));
>}
>});
>
>
> 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
>
>
Simple Download from StringResourceStream cause NPE wicket 1.5M3 (possible bug??)
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]
final StringBuilder content = new StringBuilder("Hello,world");
add(new Link("downloadDoc") {
@Override
public void onClick() {
StringResourceStream stream = new
StringResourceStream(content.toString(),"html/csv");
getRequestCycle().scheduleRequestHandlerAfterCurrent(new
ResourceStreamRequestHandler(stream)
.setFileName("demo.csv")
.setContentDisposition(ContentDisposition.ATTACHMENT));
}
});
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: Possible bug in HttpsRequestCycleProcessor?
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
Possible bug in HttpsRequestCycleProcessor?
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?
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
Re: possible bug?
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 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?
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 in ComponentFeedBackPanel
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
> 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
Re: possible bug in ComponentFeedBackPanel
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
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
possible bug in ComponentFeedBackPanel
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
Possible bug in interaction between FeedbackMessages and FeedbackMessagesModel
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 List 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 List messages(final IFeedbackMessageFilter
filter)
{
if (messages.size() == 0)
{
return Collections.emptyList();
}
final List list = new ArrayList();
for (final Iterator 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
Re: possible bug
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 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
possible bug
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 in FormComponent$MessageSource regarding resource string lookups
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
// 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]
>>>
>>>
>>
>> -
>> 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]
Re: Possible bug in FormComponent$MessageSource regarding resource string lookups
{
>>// 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]
>>
>>
>
> -
> 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
>> 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] > > > -- 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
t; > 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]
Re: Possible bug in FormComponent$MessageSource regarding resource string lookups
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
> 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
Possible bug in FormComponent$MessageSource regarding resource string lookups
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
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]
Re: Possible bug in Localizer?
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 in Localizer?
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]
Possible bug in Localizer?
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 - discrepancy in component.onBeforeRender and IBehavior.beforeRender.
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]
>
>
Re: Possible BUG - discrepancy in component.onBeforeRender and IBehavior.beforeRender.
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.
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
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]
Re: possible bug in 1.2.6 / 1.3 Include
That looks like a good fix for 1.2. However, as far as I know, the
facility to manually set context paths was removed from 1.3. as that
always works with relative urls.
Eelco
On 10/16/07, Jeremy Levy <[EMAIL PROTECTED]> 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?
>
> Jeremy
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
possible bug in 1.2.6 / 1.3 Include
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
