Re: svn commit: r1031432 - /wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java
This commits breaks all header contributions when the ajaxrequesttarget has more then 1 component that it must render and the component after the first one also wants to render something in the head.. i committed a fix: commit -m fix form previous commit: 1031432... C:/workspace_wicket14/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java Sending C:/workspace_wicket14/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java Transmitting file data ... Committed revision 1040980. so that the header is now only closed after all components are rendered. Don't we have any test that would cover this? That should have failed? So a test that renders 2 components in an ajax request and both contribute some css or js. johan On Fri, Nov 5, 2010 at 06:07, jrthomer...@apache.org wrote: Author: jrthomerson Date: Fri Nov 5 05:07:52 2010 New Revision: 1031432 URL: http://svn.apache.org/viewvc?rev=1031432view=rev Log: AjaxRequestTarget was not calling IHeaderResponse.close() after traversing hierarchy to renderhead on all appropriate iheadercontributors Modified: wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java Modified: wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java URL: http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java?rev=1031432r1=1031431r2=1031432view=diff == --- wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java (original) +++ wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java Fri Nov 5 05:07:52 2010 @@ -1143,6 +1143,7 @@ public class AjaxRequestTarget implement } }); } + header.getHeaderResponse().close(); // revert to old response
Re: svn commit: r1031432 - /wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java
Johan, See the discussion from Nov 11 with subject mentioning ...svn commit: r1033843... There we tried to figure out the meaning of the single failing test. I still wonder where that 'B' comes from in the expected result :...javascriptUrl[B]... On Wed, Dec 1, 2010 at 1:34 PM, Johan Compagner jcompag...@gmail.comwrote: This commits breaks all header contributions when the ajaxrequesttarget has more then 1 component that it must render and the component after the first one also wants to render something in the head.. i committed a fix: commit -m fix form previous commit: 1031432... C:/workspace_wicket14/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java Sending C:/workspace_wicket14/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java Transmitting file data ... Committed revision 1040980. so that the header is now only closed after all components are rendered. Don't we have any test that would cover this? That should have failed? So a test that renders 2 components in an ajax request and both contribute some css or js. johan On Fri, Nov 5, 2010 at 06:07, jrthomer...@apache.org wrote: Author: jrthomerson Date: Fri Nov 5 05:07:52 2010 New Revision: 1031432 URL: http://svn.apache.org/viewvc?rev=1031432view=rev Log: AjaxRequestTarget was not calling IHeaderResponse.close() after traversing hierarchy to renderhead on all appropriate iheadercontributors Modified: wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java Modified: wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java URL: http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java?rev=1031432r1=1031431r2=1031432view=diff == --- wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java (original) +++ wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java Fri Nov 5 05:07:52 2010 @@ -1143,6 +1143,7 @@ public class AjaxRequestTarget implement } }); } + header.getHeaderResponse().close(); // revert to old response
Re: svn commit: r1033843 - in /wicket/trunk/wicket/src: main/java/org/apache/wicket/markup/html/ main/java/org/apache/wicket/resource/ main/java/org/apache/wicket/resource/aggregation/ main/java/org/a
ok this test was then correct that it failed.. Ajax does have to push it to the client because it doesnt know if it is there yet or not that you only know because of the id script id=xxx that can be set i believe then at the client side it is checked if that id is there already For example if you have a main page with tabs and those tabs are switched through an ajax request then everything that is inside that tab needs to be render and also the js and css contributions.. It could be that those are the same as the previous tab.. But the second tab doesn't know that. I think that is all resolved at the client side in the browser, but i guess matej or igor knows that a bit better them me. But all the components that are added to the AjaxRequestTarget should contribute.. Not only the first one and Jeremy's commit broke that johan On Fri, Nov 12, 2010 at 00:57, Jeremy Thomerson jrthomer...@apache.org wrote: On Thu, Nov 11, 2010 at 6:02 PM, Jeremy Thomerson jrthomer...@apache.org wrote: On Thu, Nov 11, 2010 at 4:04 AM, Martin Grigorov mgrigo...@apache.org wrote: Notice that I touched AjaxHeaderContributionPage2_ajax_expected.html and removed expected javascript header contribution after Ajax request. I think this is the proper fix because this JS url is already contributed by normal (non-Ajax) page load and it should not be redelivered later by Ajax contributions. So, the strange thing is that what makes this fail is that close() is now called after the component hierarchy traversal. The fact that it was not being called before really seems like a bug. But, closing it stops this contribution from being rendered because it is rendered after the header response is closed (and is therefore skipped). So, I have a couple questions: First - is your statement above correct? If I add a css file in the page, and then contribute the same URL via AJAX, should it be added to the page a second time? You say no, but it appears that we've been testing to make sure that it is. I think there could be cases where it should - what if that URL returns dynamic css (js, etc) that has changed since the page was originally loaded? It could be JSON, for instance, that has changed. Second - there's some strange order of operations happening here that's causing this. I am about to walk out the door and haven't had a chance to fully investigate why this is happening. I wonder why AjaxHeaderContribution2 overrides renderHead(HtmlHeaderContainer container) rather than implementing the normal IHeaderContributor method. Anybody know off the top of their head? Jeremy
Re: svn commit: r1033843 - in /wicket/trunk/wicket/src: main/java/org/apache/wicket/markup/html/ main/java/org/apache/wicket/resource/ main/java/org/apache/wicket/resource/aggregation/ main/java/org/a
Now I see where the [B] comes from: AjaxHeaderContribution2.java ... Later today I will merge your fix to 1.5 and revert mine from th revision discussed here. On Wed, Dec 1, 2010 at 2:33 PM, Johan Compagner jcompag...@gmail.comwrote: ok this test was then correct that it failed.. Ajax does have to push it to the client because it doesnt know if it is there yet or not that you only know because of the id script id=xxx that can be set i believe then at the client side it is checked if that id is there already For example if you have a main page with tabs and those tabs are switched through an ajax request then everything that is inside that tab needs to be render and also the js and css contributions.. It could be that those are the same as the previous tab.. But the second tab doesn't know that. I think that is all resolved at the client side in the browser, but i guess matej or igor knows that a bit better them me. But all the components that are added to the AjaxRequestTarget should contribute.. Not only the first one and Jeremy's commit broke that johan On Fri, Nov 12, 2010 at 00:57, Jeremy Thomerson jrthomer...@apache.org wrote: On Thu, Nov 11, 2010 at 6:02 PM, Jeremy Thomerson jrthomer...@apache.org wrote: On Thu, Nov 11, 2010 at 4:04 AM, Martin Grigorov mgrigo...@apache.org wrote: Notice that I touched AjaxHeaderContributionPage2_ajax_expected.html and removed expected javascript header contribution after Ajax request. I think this is the proper fix because this JS url is already contributed by normal (non-Ajax) page load and it should not be redelivered later by Ajax contributions. So, the strange thing is that what makes this fail is that close() is now called after the component hierarchy traversal. The fact that it was not being called before really seems like a bug. But, closing it stops this contribution from being rendered because it is rendered after the header response is closed (and is therefore skipped). So, I have a couple questions: First - is your statement above correct? If I add a css file in the page, and then contribute the same URL via AJAX, should it be added to the page a second time? You say no, but it appears that we've been testing to make sure that it is. I think there could be cases where it should - what if that URL returns dynamic css (js, etc) that has changed since the page was originally loaded? It could be JSON, for instance, that has changed. Second - there's some strange order of operations happening here that's causing this. I am about to walk out the door and haven't had a chance to fully investigate why this is happening. I wonder why AjaxHeaderContribution2 overrides renderHead(HtmlHeaderContainer container) rather than implementing the normal IHeaderContributor method. Anybody know off the top of their head? Jeremy
Re: svn commit: r1031432 - /wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java
I think it does. I haven't had the opportunity to look through the entire thread, but it looks like Johan has a fix. As long as the fix still includes calling close somewhere near the end of the request, it works for me. In that case, if there are VP objections, I'll plan on building a release to vote on in the next 48 hours. Thoughts? Jeremy Thomerson http://wickettraining.com -- sent from my smart phone, so please excuse spelling, formatting, or compiler errors On Dec 1, 2010 8:42 AM, Ernesto Reinaldo Barreiro reier...@gmail.com wrote: Thanks for the explanation. So, this makes 1.4.14 a really dangerous version to use:-( Does this merits rolling out a 1.4.15? Regards, Ernesto On Wed, Dec 1, 2010 at 2:26 PM, Johan Compagner jcompag...@gmail.com wrote: that really sounds ...
Re: HTML 5 input types support
Single inheritance should not be a problem if your design is good, which means that your components' taxonomy must be consistent. On the other hand having more component classes brings developers a stronger abstraction and a more readable code. I'm -1 on adding more subclasses to Wicket's type hierarchy. We have single inheritance in Java, why waste it for something which could equally well be implemented with behaviors? Sven Am 30.11.2010 um 13:18 schrieb Andrea Del Bene:
Re: svn commit: r1031432 - /wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java
i just moved your all a bit up the call chain so no when it handles 1 component but when it handles all components, see my commit. On Wed, Dec 1, 2010 at 15:15, Jeremy Thomerson jer...@wickettraining.com wrote: I think it does. I haven't had the opportunity to look through the entire thread, but it looks like Johan has a fix. As long as the fix still includes calling close somewhere near the end of the request, it works for me. In that case, if there are VP objections, I'll plan on building a release to vote on in the next 48 hours. Thoughts? Jeremy Thomerson http://wickettraining.com -- sent from my smart phone, so please excuse spelling, formatting, or compiler errors On Dec 1, 2010 8:42 AM, Ernesto Reinaldo Barreiro reier...@gmail.com wrote: Thanks for the explanation. So, this makes 1.4.14 a really dangerous version to use:-( Does this merits rolling out a 1.4.15? Regards, Ernesto On Wed, Dec 1, 2010 at 2:26 PM, Johan Compagner jcompag...@gmail.com wrote: that really sounds ...
wicket-shiro stateless login panel
Can we make the class org.wicketstuff.shiro.component.LoginPanel$SignInForm extend StatelessForm instead of Form ? I put the panel on my stateless home page and if I do a re-login I always end-up with a Page expired exception. Making the login form stateless fixes this. Regards, Seb
Re: wicket-shiro stateless login panel
+1 On Wed, Dec 1, 2010 at 7:16 PM, Sebastian nospam...@gmx.net wrote: Can we make the class org.wicketstuff.shiro.component.LoginPanel$SignInForm extend StatelessForm instead of Form ? I put the panel on my stateless home page and if I do a re-login I always end-up with a Page expired exception. Making the login form stateless fixes this. Regards, Seb
Re: wicket-shiro stateless login panel
Makes sense to me. Is there a Jira that this can be created in to make sure someone works on it? On Wed, Dec 1, 2010 at 10:43 AM, Martin Grigorov mgrigo...@apache.org wrote: +1 On Wed, Dec 1, 2010 at 7:16 PM, Sebastian nospam...@gmx.net wrote: Can we make the class org.wicketstuff.shiro.component.LoginPanel$SignInForm extend StatelessForm instead of Form ? I put the panel on my stateless home page and if I do a re-login I always end-up with a Page expired exception. Making the login form stateless fixes this. Regards, Seb
Re: wicket-shiro stateless login panel
It's part of wicketstuff, so no JIRA. I can just commit the change and add it to the changelog. Just wanted to have some feedback first. Regards, Seb On 01.12.2010 19:49, Les Hazlewood wrote: Makes sense to me. Is there a Jira that this can be created in to make sure someone works on it? On Wed, Dec 1, 2010 at 10:43 AM, Martin Grigorovmgrigo...@apache.org wrote: +1 On Wed, Dec 1, 2010 at 7:16 PM, Sebastiannospam...@gmx.net wrote: Can we make the class org.wicketstuff.shiro.component.LoginPanel$SignInForm extend StatelessForm instead of Form ? I put the panel on my stateless home page and if I do a re-login I always end-up with a Page expired exception. Making the login form stateless fixes this. Regards, Seb
Re: wicket-shiro stateless login panel
It's in wicketstuff 1.4.15-SNAPSHOT now. On 01.12.2010 19:49, Les Hazlewood wrote: Makes sense to me. Is there a Jira that this can be created in to make sure someone works on it? On Wed, Dec 1, 2010 at 10:43 AM, Martin Grigorovmgrigo...@apache.org wrote: +1 On Wed, Dec 1, 2010 at 7:16 PM, Sebastiannospam...@gmx.net wrote: Can we make the class org.wicketstuff.shiro.component.LoginPanel$SignInForm extend StatelessForm instead of Form ? I put the panel on my stateless home page and if I do a re-login I always end-up with a Page expired exception. Making the login form stateless fixes this. Regards, Seb
wicket-shiro LoginPanel always redirects to a stateful homepage instance
Is there any good reason why in org.wicketstuff.shiro.component.LoginPanel.onSignInSucceeded the redirect to the homepage is done using setResponsePage(getApplication().getSessionSettings().getPageFactory().newPage(getApplication().getHomePage())) instead of setResponsePage(getApplication().getHomePage()) The former eventually results in the page being flagged automatically as stateful at one point of the request cylce. I changed it in my local copy branch, the login and redirect still works, and the StatelesChecker does not raise an exception after login anymore. So I'd like to change that in the wicketstuff SVN too. any thoughts? Regards, Seb
