Re: Wicket 6.0 + JavaScriptFilteredIntoFooterHeaderResponse + CssHeaderItem
Hi Rob, On Sun, Jan 8, 2012 at 8:12 AM, robert.mcguinness robert.mcguinness@gmail.com wrote: kk, got it working again by overriding /CssAcceptingHeaderResponseFilter#accepts/ /item instanceof CssHeaderItem || item instanceof PageHeaderItem/ also, for some js frameworks like *modernizr.js* and *respond.js*, they require these libs to live in the in the head tag. to target the head bucket for for these js libs, i created a new JavaScriptReference*In*HeaderItem that is used to accept these type of libs in the head. This sounds like a good addition to the default HeaderItems. Please create a ticket with your class(es) attached. Thanks! if i'm wrong about my assumptions let me know. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-6-0-JavaScriptFilteredIntoFooterHeaderResponse-CssHeaderItem-tp4274687p4275033.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 jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: stateless, not versioned pages - session problem
Hej, On Sun, Jan 8, 2012 at 12:24 AM, kamiseq kami...@gmail.com wrote: hej I have weird problem with session that I cannot explain and that I don't fully understand. I started with default application settings and stateful web page. and the flow is that I 1. request homepage 2. put data to session 3. redirect to authorize with oauth provider (facebook, gmail, etc) which in turn redirects back to my page 4. get data saved before in session 5. redirect to homepage then I made page stateless and it works perfectly fine until I set getPageSettings().setVersionPagesByDefault(false); (I dont need back button functionality) then session was not created even though I put there something (well it is not quite right session is created but not persisted between requests - just after I put to session I can get the data from session, but on next request to wicket data is gone). To solve it do: Session.get().bind() when you add the attribute(s). I think Wicket should do that for you automatically. Please file a ticket and we will consider it. can you explain why is that? one more thing after last redirect (step 5) wicket added ?#base_domain=mydomain.com to url. when I set getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); url is as oauth callback (from step 3) and I would expect it to be clean homepage url (ex mydomain.com/) for both render strategies can you try with Wicket 1.5-SNAPSHOT ? Recently we fixed something that automatically added the page parameters to the generated urls. thanks for help pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: stateless, not versioned pages - session problem
2012/1/8 Chris Colman chr...@stepaheadsoftware.com: Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. which worked. The interesting thing was it was not necessary to call: getPageSettings().setVersionPagesByDefault(false); explicitly. -Original Message- From: kamiseq [mailto:kami...@gmail.com] Sent: Sunday, 8 January 2012 9:25 AM To: users@wicket.apache.org Subject: stateless, not versioned pages - session problem hej I have weird problem with session that I cannot explain and that I don't fully understand. I started with default application settings and stateful web page. and the flow is that I 1. request homepage 2. put data to session 3. redirect to authorize with oauth provider (facebook, gmail, etc) which in turn redirects back to my page 4. get data saved before in session 5. redirect to homepage then I made page stateless and it works perfectly fine until I set getPageSettings().setVersionPagesByDefault(false); (I dont need back button functionality) then session was not created even though I put there something (well it is not quite right session is created but not persisted between requests - just after I put to session I can get the data from session, but on next request to wicket data is gone). can you explain why is that? one more thing after last redirect (step 5) wicket added ?#base_domain=mydomain.com to url. when I set getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.RenderStr ategy.ONE_PASS_RENDER); url is as oauth callback (from step 3) and I would expect it to be clean homepage url (ex mydomain.com/) for both render strategies thanks for help pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.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 -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: stateless, not versioned pages - session problem
Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. So would getPageSettings().setVersionPagesByDefault(false); have been a better/safer option for turning off page versioning? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: stateless, not versioned pages - session problem
On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman chr...@stepaheadsoftware.com wrote: Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. So would getPageSettings().setVersionPagesByDefault(false); have been a better/safer option for turning off page versioning? Yes. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: stateless, not versioned pages - session problem
ok currently im using 1.5.3 i ll check with snapshot pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: stateless, not versioned pages - session problem
On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman chr...@stepaheadsoftware.com wrote: Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. So would getPageSettings().setVersionPagesByDefault(false); have been a better/safer option for turning off page versioning? Yes. I tried setVesionPagesByDefault(false) on its own but the version parameters still appeared in the URL in the browser address bar. Should we use both of the above to make page versioning disappear so as to make Wicket 1.5 behave just like version 1.5? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.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: Wicket 6.0 + JavaScriptFilteredIntoFooterHeaderResponse + CssHeaderItem
done. thank martin. https://issues.apache.org/jira/browse/WICKET-4328 -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-6-0-JavaScriptFilteredIntoFooterHeaderResponse-CssHeaderItem-tp4274687p4276477.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
AJAX upload in modal window hangs when file size is too large @L
Hello, I have an upload form which uploads files using AJAX. When the file size is less than maxUploadSize the form work correctly on the page and modal window. When file size is greater than maxUploadSize then form works correctly and displays an error on the page, but hangs in modal window after INFO: Invoking pre-call handler(s)... and before INFO: Response parsed. Now invoking steps What could be the reason for AJAX upload request to hang in modal window when the file uploaded is too large? Thanks, Alec - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
AjaxLink causes list model to be detached before rendering!
Hi, Can anyone tell me why when I refresh a wicket page which has on it an AjaxLink, my list model is being detached just before its contents are rendered by a list view? I would expect detach only to be called after everything has been rendered. Detaching just before rendering would call a potentially 2nd unnecessary expensive database operation to load the model. I have an AjaxLink call back which seems to be creating this behaviour. Without it the models are detached afer rendering as expected. E.g. for the attached simple test page, pressing refresh in the browser, when there is no AjaxLink I get the following diagnostic output from Testpage.java... LOAD LIST MODEL 79e14338 populateItem 79e14338 populateItem 79e14338 populateItem 79e14338 DETACH MODELS 79e14338 DETACH LIST MODEL 79e14338 DETACH MODELS 79e14338 DETACH LIST MODEL 79e14338 When I surround the label with an ajax link, pressing refresh in the browser, I get.. LOAD LIST MODEL 62b512e7 DETACH LIST MODEL 62b512e7 //1st DETACH LIST MODEL 62b512e7 //2nd DETACH LIST MODEL 62b512e7 //3rd populateItem 62b512e7 // render A populateItem 62b512e7 // render B populateItem 62b512e7 // render C LOAD LIST MODEL 62b512e7 DETACH MODELS 62b512e7 DETACH LIST MODEL 62b512e7 //4th DETACH LIST MODEL 62b512e7 //5th DETACH LIST MODEL 62b512e7 //6th DETACH LIST MODEL 62b512e7 //7th DETACH MODELS 62b512e7 DETACH LIST MODEL 62b512e7 //8th DETACH LIST MODEL 62b512e7 //9th DETACH LIST MODEL 62b512e7 //10th DETACH LIST MODEL 62b512e7 //11th WRITE OBJECT 62b512e7 .. 11 calls to .detach() on the list model! between the 3rd and 4th detach list model the list is actually rendered. Had this been for real this would have ment that the list model would have been loaded again at this point. Here's the detail stack traces of where these 11 detach list models are being called from when refresh on my test page with the AjaxLink... *** 1st DETACH LIST MODEL *** TestPage$2.detach() line: 39 TestPage$3$1(Component).detachModel() line: 3536 TestPage$3$1(Component).detachModels() line: 1203 TestPage$3$1(Component).detach() line: 1154 ListItemT(MarkupContainer).detachChildren() line: 1710 ListItemT(Component).detach() line: 1161 TestPage$3(MarkupContainer).removeAll() line: 672 TestPage$3(ListViewT).onPopulate() line: 498 TestPage$3(AbstractRepeater).onBeforeRender() line: 119 TestPage$3(Component).internalBeforeRender() line: 981 TestPage$3(Component).beforeRender() line: 1015 TestPage(MarkupContainer).onBeforeRenderChildren() line: 1785 TestPage(Component).onBeforeRender() line: 3774 TestPage(Page).onBeforeRender() line: 823 TestPage(Component).internalBeforeRender() line: 981 TestPage(Component).beforeRender() line: 1015 TestPage(Component).internalPrepareForRender(boolean) line: 2184 TestPage(Page).internalPrepareForRender(boolean) line: 280 TestPage(Component).render() line: 2271 TestPage(Page).renderPage() line: 1035 WebPageRenderer.renderPage(Url, RequestCycle) line: 105 WebPageRenderer.respond(RequestCycle) line: 182 RenderPageRequestHandler.respond(IRequestCycle) line: 167 *** 2nd DETACH LIST MODEL *** Same as before. *** 3rd DETACH LIST MODEL *** Same as before. *** Now populateItem is called 3 times on the list view to render the 3 list elements... *** 4th DETACH LIST MODEL *** TestPage$2.detach() line: 39 TestPage$3(Component).detachModel() line: 3536 TestPage$3(Component).detachModels() line: 1203 TestPage$3(Component).detach() line: 1154 TestPage(MarkupContainer).detachChildren() line: 1710 TestPage(Component).detach() line: 1161 PageProvider.detach() line: 318 RenderPageRequestHandler.detach(IRequestCycle) line: 148 RequestCycle$HandlerExecutor.detach(IRequestHandler) line: 761 RequestCycle$HandlerExecutor(RequestHandlerStack).detach() line: 180 RequestCycle.onDetach() line: 565 RequestCycle.detach() line: 508 RequestCycle.processRequestAndDetach() line: 284 WicketFilter.processRequest(ServletRequest, ServletResponse, FilterChain) line: 162 *** 5th DETACH LIST MODEL *** TestPage$2.detach() line: 39 TestPage$3$1(Component).detachModel() line: 3536 TestPage$3$1(Component).detachModels() line: 1203 TestPage$3$1(Component).detach() line: 1154 ListItemT(MarkupContainer).detachChildren() line: 1710 ListItemT(Component).detach() line: 1161 TestPage$3(MarkupContainer).detachChildren() line: 1710 TestPage$3(Component).detach() line: 1161 TestPage(MarkupContainer).detachChildren() line: 1710 TestPage(Component).detach() line: 1161 PageProvider.detach() line: 318 RenderPageRequestHandler.detach(IRequestCycle) line: 148 RequestCycle$HandlerExecutor.detach(IRequestHandler) line: 761 RequestCycle$HandlerExecutor(RequestHandlerStack).detach() line: 180 RequestCycle.onDetach() line: 565 RequestCycle.detach() line: 508 RequestCycle.processRequestAndDetach() line: 284 WicketFilter.processRequest(ServletRequest, ServletResponse, FilterChain) line: 162 *** 6th DETACH LIST MODEL *** Same as before *** 7th DETACH LIST MODEL *** Same as before
Re: stateless, not versioned pages - session problem
ok so bind on session does the trick. now I looked at setAttribute method and I dont understand why the flow is altered when session is temporary. unfortunately I still get this #base_domain=mydoamin. so 1.5-SNAPSHOT behaves like 1.5.3 now I looked closely to url after last redirect to homepage (using ONE_PASS_RENDER strategy) and it is exactly the same as oauth callback plus this #base_domain=mydomain.com parameter :/ when I use default RenderStrategy.REDIRECT_TO_BUFFER then I just get #base_domain=mydomain parameter any ideas? pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
getAssociatedMarkup() invoked twice
Hi,
I made my custom markup WebPage, not the default HTML and WebPage pair, to
generate JSON responses. My custom WebPage implemented
IMarkupCacheKeyProvider and IMarkupResourceStreamProvider interfaces.
I come to realize that my implementation of
IMarkupResourceStreamProvider.getMarkupResourceStream(...) was invoked twice
for every request. Upon further investigation, I found out that the Wicket
(1.5.x and 6.x) core code in Component.getMarkup() was the source of this.
...
if (container.hasAssociatedMarkup())
{
markup = container.getAssociatedMarkup();
return markup;
}
...
where container.hasAssociatedMarkup() will also invoke getAssociateMarkup()
i.e.
public boolean hasAssociatedMarkup()
{
return getAssociatedMarkup() != null;
}
As a result, my IMarkupResourceStreamProvider.getMarkupResourceStream(...)
is invoked twice. What I did now is I override hasAssociatedMarkup() to
return a true to avoid my implementation to be invoked twice. My question
is, is this the way going forward or is there a better way of doing this?
Thanks
/lim/
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/getAssociatedMarkup-invoked-twice-tp4277728p4277728.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
