Re: AjaxLink causes list model to be detached before rendering!
Hi Philip, ListView throws away all its children before rendering. When a component is removed, its model gets detached. Your AjaxLink has your LoadableDetachableModel as model, thus it forces it to be detached too. As a possible solution, don't keep a reference to the model as your AjaxLink's model: AjaxLinkVoid link = new AjaxLinkVoid(link) Hope this helps Sven On 01/08/2012 09:22 PM, Philip Wilkinson wrote: 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
Re: getAssociatedMarkup() invoked twice
Hi,
This can be easily optimized.
I'll take care.
On Mon, Jan 9, 2012 at 8:17 AM, TH Lim ssh...@gmail.com wrote:
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
--
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: getAssociatedMarkup() invoked twice
https://issues.apache.org/jira/browse/WICKET-4329
On Mon, Jan 9, 2012 at 11:05 AM, Martin Grigorov mgrigo...@apache.org wrote:
Hi,
This can be easily optimized.
I'll take care.
On Mon, Jan 9, 2012 at 8:17 AM, TH Lim ssh...@gmail.com wrote:
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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
--
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
On Sun, Jan 8, 2012 at 4:29 PM, Chris Colman chr...@stepaheadsoftware.com wrote: 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? Make your page stateless to not have page ids in the URL (and the page wont be saved in the page stores too). Otherwise you'll need special version of org.apache.wicket.request.mapper.MountedMapper#mapHandler that doesn't org.apache.wicket.request.mapper.AbstractComponentMapper#encodePageComponentInfo for IPageRequestHandler. - 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 -- 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
The stateless/stateful issue, on the surface at least, seems to be trivially easy because it's so black and white. Obviously in an ideal world most pages should be made stateless but in all but trivial sites this is near impossible. I'd like to suggest there is a fair amount of 'gray' - that things aren't so 'black and white' in the real world. For example - the content on most of the pages on our sites are essentially stateless - showing product details or FAQ pages or About Us pages until you realize that *every* web app that has authentication (which one doesn't these days?) shows the currently logged on user's username in an 'account details' component in the top/right of each page with an option to change profile settings and log out etc,. This has become much more than just a convention - it's virtually a defacto standard. Once we add that very common account details component to the top of each page the pages essentially become stateful so essentially a site with predominantly stateless pages now has to be stateful. The main issue that I am trying to avoid by removing page versions is SEO confusion whereby each time a search engine looks at a URL it sees a different page version parameter in the URL. It's a similar problem to the famous jsessionid parameter issue. Given that search engines never authenticate it prompts the question: is it possible for a given page to have multiple personalities? i.e. stateless if no authentication has taken place and stateful if authentication has taken place. User's don't really care if there is an extra page version parameter in the URL and this can be of great assistance in making the back button function correctly - especially if their interactions have changed content on the various pages (eg. showing contents of their shopping cart - hmmm, that's a problem - probably always want to show the 'current' shopping cart contents no matter how much they have gone 'back' otherwise things could get quite confusing) Search engines, on the other hand, don't really want to see the extra page version parameter. Setting up pages to have dual personalities would be a most excellent solution methinks. Is this possible/easy/a good idea in Wicket? Is it something that is such a common requirement that it could be added to the Wicket framework as a built in feature and save hours of work for both experienced and newbie Wicketeers? If it were a switchable option built into the framework wicket would only need to query the AuthenticatedWebSession.isSignedIn() to determine if each page should be stateless or stateful. Or perhaps an IAuthenticator interface needs to be supplied to allow it to work for developers who implement their own authenticated session object. Just thinking aloud ... again ;) Regards, Chrisco -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Monday, 9 January 2012 8:37 PM To: users@wicket.apache.org Subject: Re: stateless, not versioned pages - session problem On Sun, Jan 8, 2012 at 4:29 PM, Chris Colman chr...@stepaheadsoftware.com wrote: 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? Make your page stateless to not have page ids in the URL (and the page wont be saved in the page stores too). Otherwise you'll need special version of org.apache.wicket.request.mapper.MountedMapper#mapHandler that doesn't org.apache.wicket.request.mapper.AbstractComponentMapper#encodePageComponen tInfo for IPageRequestHandler. - 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 -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: hebrew text looks like ×׳—׳‘׳¨׳ •
HTML files should not have have an XML header. Only XHTML files should. From: armhold armh...@gmail.com To: users@wicket.apache.org Date: 01/06/2012 08:31 PM Subject:Re: hebrew text looks like ×׳—׳‘׳¨׳• I went though this pain a few months ago too. Here are all the places I had to hit: 1. In your HTML files: ?xml version=1.0 encoding=UTF-8? And also in your head: meta http-equiv=Content-Type content=text/html; charset=UTF-8 2. For property files, if you use i18n you will need to use the foo.xml format rather than foo.properties, and also include the above ?xml version=1.0 encoding=UTF-8? in each of them. 3. In your WicketApplication.java: // wicket 1.4; perhaps different in 1.5 getRequestCycleSettings().setResponseRequestEncoding(UTF-8); getMarkupSettings().setDefaultMarkupEncoding(UTF-8); 4. In your pom.xml (to cover any copied resources): properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties 5. Finally, in Intellij: File - Preferences - File Encodings - IDE Encoding: UTF-8. What made this frustrating is that it always seemed to render fine with the embedded Jetty, but not with Tomcat (so things would always look great locally, but fall apart in production). -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/hebrew-text-looks-like-tp4260875p4271694.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 ** This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies. **
Re: stateless, not versioned pages - session problem
Hi, I see there is a big misunderstanding of what stateless/ful actually is. Having an http session or not is related only to the fact that stateful pages are stored there. Nothing more. You still can have an authenticated user (i.e. http session) and show stateless pages. All user info panels that you mentioned below doesn't require stateful page by itself. A page is stateful if it has at least one stateful component or behavior. A stateful component/behavior (C/B)is one that keeps a state with it and that state is needed by the C/B in the next request(s). Such C/B may have a callback url - an url which uniquely identifies this C/B and this C/B can be requested. In the simple and most used case imagine a Link with its onClick() method. So if you keep your pages stateless (by avoiding components and behaviors which makes it stateful. See StatelessChecker in wicket-devutils.jar) you can still show user's account info. A common use case is with Ajax C/Bs. An Ajax call updates just a part of the page. By default Wicket provides stateful Ajax C/Bs, i.e. they update parts of the same page instance. Jolira's Ajax C/Bs are stateless - i.e. an Ajax call creates a completely new page, then updates the part(s) it needs, then delivers the markup for the updated components in the Ajax response and discards the newly created page. I guess we need to create a Wiki page that better explains what is the difference between stateless and stateful. On Mon, Jan 9, 2012 at 1:39 PM, Chris Colman chr...@stepaheadsoftware.com wrote: The stateless/stateful issue, on the surface at least, seems to be trivially easy because it's so black and white. Obviously in an ideal world most pages should be made stateless but in all but trivial sites this is near impossible. I'd like to suggest there is a fair amount of 'gray' - that things aren't so 'black and white' in the real world. For example - the content on most of the pages on our sites are essentially stateless - showing product details or FAQ pages or About Us pages until you realize that *every* web app that has authentication (which one doesn't these days?) shows the currently logged on user's username in an 'account details' component in the top/right of each page with an option to change profile settings and log out etc,. This has become much more than just a convention - it's virtually a defacto standard. Once we add that very common account details component to the top of each page the pages essentially become stateful so essentially a site with predominantly stateless pages now has to be stateful. The main issue that I am trying to avoid by removing page versions is SEO confusion whereby each time a search engine looks at a URL it sees a different page version parameter in the URL. It's a similar problem to the famous jsessionid parameter issue. Given that search engines never authenticate it prompts the question: is it possible for a given page to have multiple personalities? i.e. stateless if no authentication has taken place and stateful if authentication has taken place. User's don't really care if there is an extra page version parameter in the URL and this can be of great assistance in making the back button function correctly - especially if their interactions have changed content on the various pages (eg. showing contents of their shopping cart - hmmm, that's a problem - probably always want to show the 'current' shopping cart contents no matter how much they have gone 'back' otherwise things could get quite confusing) Search engines, on the other hand, don't really want to see the extra page version parameter. Setting up pages to have dual personalities would be a most excellent solution methinks. Is this possible/easy/a good idea in Wicket? Is it something that is such a common requirement that it could be added to the Wicket framework as a built in feature and save hours of work for both experienced and newbie Wicketeers? If it were a switchable option built into the framework wicket would only need to query the AuthenticatedWebSession.isSignedIn() to determine if each page should be stateless or stateful. Or perhaps an IAuthenticator interface needs to be supplied to allow it to work for developers who implement their own authenticated session object. Just thinking aloud ... again ;) Regards, Chrisco -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Monday, 9 January 2012 8:37 PM To: users@wicket.apache.org Subject: Re: stateless, not versioned pages - session problem On Sun, Jan 8, 2012 at 4:29 PM, Chris Colman chr...@stepaheadsoftware.com wrote: 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().
Re: AjaxLink causes list model to be detached before rendering!
Sven,
Thanks for your speedy reply.
Indeed you are correct, removing the model from the AjaxLink stops the
model from becoming detached immediately before rendering.
I now realise that my cut-down example was too cut-down! The AjaxLink
is actually there to remove the entry from the list, requiring the
list model to be accessible to the link. So the implementation would
be something like:-
public class TestPage extends WebPage
{
private ListString testList = new ArrayListString() {{
add(A); add(B); add(C);}};
public TestPage()
{
setOutputMarkupId(true);
final IModelListString model = new
LoadableDetachableModelListString()
{
@Override
protected ListString load()
{
System.out.println(LOAD LIST MODEL +
Integer.toHexString(TestPage.this.hashCode()));
return testList;
}
@Override
public void detach()
{
System.out.println(DETACH LIST MODEL +
Integer.toHexString(TestPage.this.hashCode()));
super.detach();
}
};
final ListViewString rows = new ListViewString(rows, model)
{
@Override
protected void populateItem(final ListItemString item)
{
System.out.println(populateItem +
Integer.toHexString(TestPage.this.hashCode()));
// with ajax link to remove entry.
AjaxLinkListString link = new
AjaxLinkListString(link, model)
{
@Override
public void onClick(AjaxRequestTarget target)
{
getModelObject().remove(item.getIndex()-1);
target.add(TestPage.this); // normally the
target would be a containing panel, but for this example, the page
will do!
}
};
link.add(new Label(label, item.getModel()));
item.add(link);
}
};
add(rows);
}
@Override
public void detachModels()
{
System.out.println(DETACH MODELS +
Integer.toHexString(TestPage.this.hashCode()));
super.detachModels();
}
}
Possibly I could get around this by not setting the model on the
AjaxLink, so wicket doesn't try to detach it, and passing the list
model in separately. But that feels like I'm not following the wicket
way if I do something like that :(. I think that knowing what the
AjaxLink is doing, removing an entry from the list, the most
appropriate model for the AjaxLink is the list model!
Do you think there's a case here for the wicket framework being a
little smarter about when it detaches its models?
I think that only the relevant models need to be detached only once
after every response has been rendered. So that they can be lazy
loaded again when required during the next response \ render cycle.
Regards,
Phil.
On Mon, Jan 9, 2012 at 8:03 AM, Sven Meier s...@meiers.net wrote:
Hi Philip,
ListView throws away all its children before rendering. When a component is
removed, its model gets detached.
Your AjaxLink has your LoadableDetachableModel as model, thus it forces it
to be detached too.
As a possible solution, don't keep a reference to the model as your
AjaxLink's model:
AjaxLinkVoid link = new AjaxLinkVoid(link)
Hope this helps
Sven
On 01/08/2012 09:22 PM, Philip Wilkinson wrote:
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
Re: stateless, not versioned pages - session problem
this should go to separate conversation I created stateless (no stateful components) page if user is authorized i put his id to session so I can load it on each page creation (since it is stateless and not versioned it will be created on each request) pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ On 9 January 2012 12:39, Chris Colman chr...@stepaheadsoftware.com wrote: The stateless/stateful issue, on the surface at least, seems to be trivially easy because it's so black and white. Obviously in an ideal world most pages should be made stateless but in all but trivial sites this is near impossible. I'd like to suggest there is a fair amount of 'gray' - that things aren't so 'black and white' in the real world. For example - the content on most of the pages on our sites are essentially stateless - showing product details or FAQ pages or About Us pages until you realize that *every* web app that has authentication (which one doesn't these days?) shows the currently logged on user's username in an 'account details' component in the top/right of each page with an option to change profile settings and log out etc,. This has become much more than just a convention - it's virtually a defacto standard. Once we add that very common account details component to the top of each page the pages essentially become stateful so essentially a site with predominantly stateless pages now has to be stateful. The main issue that I am trying to avoid by removing page versions is SEO confusion whereby each time a search engine looks at a URL it sees a different page version parameter in the URL. It's a similar problem to the famous jsessionid parameter issue. Given that search engines never authenticate it prompts the question: is it possible for a given page to have multiple personalities? i.e. stateless if no authentication has taken place and stateful if authentication has taken place. User's don't really care if there is an extra page version parameter in the URL and this can be of great assistance in making the back button function correctly - especially if their interactions have changed content on the various pages (eg. showing contents of their shopping cart - hmmm, that's a problem - probably always want to show the 'current' shopping cart contents no matter how much they have gone 'back' otherwise things could get quite confusing) Search engines, on the other hand, don't really want to see the extra page version parameter. Setting up pages to have dual personalities would be a most excellent solution methinks. Is this possible/easy/a good idea in Wicket? Is it something that is such a common requirement that it could be added to the Wicket framework as a built in feature and save hours of work for both experienced and newbie Wicketeers? If it were a switchable option built into the framework wicket would only need to query the AuthenticatedWebSession.isSignedIn() to determine if each page should be stateless or stateful. Or perhaps an IAuthenticator interface needs to be supplied to allow it to work for developers who implement their own authenticated session object. Just thinking aloud ... again ;) Regards, Chrisco -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Monday, 9 January 2012 8:37 PM To: users@wicket.apache.org Subject: Re: stateless, not versioned pages - session problem On Sun, Jan 8, 2012 at 4:29 PM, Chris Colman chr...@stepaheadsoftware.com wrote: 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? Make your page stateless to not have page ids in the URL (and the page wont be saved in the page stores too). Otherwise you'll need special version of org.apache.wicket.request.mapper.MountedMapper#mapHandler that doesn't org.apache.wicket.request.mapper.AbstractComponentMapper#encodePageComponen tInfo for IPageRequestHandler. - 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
Re: stateless, not versioned pages - session problem
any ideas about #base_domain=mydomain.com problem ;] 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: AjaxLink causes list model to be detached before rendering!
the problem here is that the listitem's model is tied to the
listview's model. so calling detach() on the listview item causes the
detachment of the listview's model.
you can either override getlistitemmodel() on the listview and give
each item an isolated model, or you can use a dataview or another
non-listview repeater.
as far as the many calls to detach(), they are nearly impossible to
avoid without making the framework much more complicated. in practice
the logic in detach() is very simple so having multiple calls to it is
not a problem.
-igor
On Mon, Jan 9, 2012 at 5:06 AM, Philip Wilkinson
wilkinson.phi...@gmail.com wrote:
Sven,
Thanks for your speedy reply.
Indeed you are correct, removing the model from the AjaxLink stops the
model from becoming detached immediately before rendering.
I now realise that my cut-down example was too cut-down! The AjaxLink
is actually there to remove the entry from the list, requiring the
list model to be accessible to the link. So the implementation would
be something like:-
public class TestPage extends WebPage
{
private ListString testList = new ArrayListString() {{
add(A); add(B); add(C);}};
public TestPage()
{
setOutputMarkupId(true);
final IModelListString model = new
LoadableDetachableModelListString()
{
@Override
protected ListString load()
{
System.out.println(LOAD LIST MODEL +
Integer.toHexString(TestPage.this.hashCode()));
return testList;
}
@Override
public void detach()
{
System.out.println(DETACH LIST MODEL +
Integer.toHexString(TestPage.this.hashCode()));
super.detach();
}
};
final ListViewString rows = new ListViewString(rows, model)
{
@Override
protected void populateItem(final ListItemString item)
{
System.out.println(populateItem +
Integer.toHexString(TestPage.this.hashCode()));
// with ajax link to remove entry.
AjaxLinkListString link = new
AjaxLinkListString(link, model)
{
@Override
public void onClick(AjaxRequestTarget target)
{
getModelObject().remove(item.getIndex()-1);
target.add(TestPage.this); // normally the
target would be a containing panel, but for this example, the page
will do!
}
};
link.add(new Label(label, item.getModel()));
item.add(link);
}
};
add(rows);
}
@Override
public void detachModels()
{
System.out.println(DETACH MODELS +
Integer.toHexString(TestPage.this.hashCode()));
super.detachModels();
}
}
Possibly I could get around this by not setting the model on the
AjaxLink, so wicket doesn't try to detach it, and passing the list
model in separately. But that feels like I'm not following the wicket
way if I do something like that :(. I think that knowing what the
AjaxLink is doing, removing an entry from the list, the most
appropriate model for the AjaxLink is the list model!
Do you think there's a case here for the wicket framework being a
little smarter about when it detaches its models?
I think that only the relevant models need to be detached only once
after every response has been rendered. So that they can be lazy
loaded again when required during the next response \ render cycle.
Regards,
Phil.
On Mon, Jan 9, 2012 at 8:03 AM, Sven Meier s...@meiers.net wrote:
Hi Philip,
ListView throws away all its children before rendering. When a component is
removed, its model gets detached.
Your AjaxLink has your LoadableDetachableModel as model, thus it forces it
to be detached too.
As a possible solution, don't keep a reference to the model as your
AjaxLink's model:
AjaxLinkVoid link = new AjaxLinkVoid(link)
Hope this helps
Sven
On 01/08/2012 09:22 PM, Philip Wilkinson wrote:
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
Re: AjaxLink causes list model to be detached before rendering!
you can ... give each item an isolated model
Actually ListItemModel doesn't detach the owning list's model, so it's
'isolated' already.
For your AjaxLink you can access the list view instead:
IModelListString model = ... // not final !!
final ListViewString rows = new ListViewString(rows, model)
{
@Override
protected void populateItem(final ListItemString item)
{
AjaxLinkVoid link = new AjaxLinkVoid(link)
{
@Override
public void onClick(AjaxRequestTarget target)
{
rows.getModelObject().remove(item.getIndex()-1);
target.add(TestPage.this);
}
};
link.add(new Label(label, item.getModel()));
item.add(link);
}
};
Sven
On 01/09/2012 05:13 PM, Igor Vaynberg wrote:
the problem here is that the listitem's model is tied to the
listview's model. so calling detach() on the listview item causes the
detachment of the listview's model.
you can either override getlistitemmodel() on the listview and give
each item an isolated model, or you can use a dataview or another
non-listview repeater.
as far as the many calls to detach(), they are nearly impossible to
avoid without making the framework much more complicated. in practice
the logic in detach() is very simple so having multiple calls to it is
not a problem.
-igor
On Mon, Jan 9, 2012 at 5:06 AM, Philip Wilkinson
wilkinson.phi...@gmail.com wrote:
Sven,
Thanks for your speedy reply.
Indeed you are correct, removing the model from the AjaxLink stops the
model from becoming detached immediately before rendering.
I now realise that my cut-down example was too cut-down! The AjaxLink
is actually there to remove the entry from the list, requiring the
list model to be accessible to the link. So the implementation would
be something like:-
public class TestPage extends WebPage
{
private ListString testList = new ArrayListString() {{
add(A); add(B); add(C);}};
public TestPage()
{
setOutputMarkupId(true);
final IModelListString model = new
LoadableDetachableModelListString()
{
@Override
protected ListString load()
{
System.out.println(LOAD LIST MODEL +
Integer.toHexString(TestPage.this.hashCode()));
return testList;
}
@Override
public void detach()
{
System.out.println(DETACH LIST MODEL +
Integer.toHexString(TestPage.this.hashCode()));
super.detach();
}
};
final ListViewString rows = new ListViewString(rows, model)
{
@Override
protected void populateItem(final ListItemString item)
{
System.out.println(populateItem +
Integer.toHexString(TestPage.this.hashCode()));
// with ajax link to remove entry.
AjaxLinkListString link = new
AjaxLinkListString(link, model)
{
@Override
public void onClick(AjaxRequestTarget target)
{
getModelObject().remove(item.getIndex()-1);
target.add(TestPage.this); // normally the
target would be a containing panel, but for this example, the page
will do!
}
};
link.add(new Label(label, item.getModel()));
item.add(link);
}
};
add(rows);
}
@Override
public void detachModels()
{
System.out.println(DETACH MODELS +
Integer.toHexString(TestPage.this.hashCode()));
super.detachModels();
}
}
Possibly I could get around this by not setting the model on the
AjaxLink, so wicket doesn't try to detach it, and passing the list
model in separately. But that feels like I'm not following the wicket
way if I do something like that :(. I think that knowing what the
AjaxLink is doing, removing an entry from the list, the most
appropriate model for the AjaxLink is the list model!
Do you think there's a case here for the wicket framework being a
little smarter about when it detaches its models?
I think that only the relevant models need to be detached only once
after every response has been rendered. So that they can be lazy
loaded again when required during the next response \ render cycle.
Regards,
Phil.
On Mon, Jan 9, 2012 at 8:03 AM, Sven Meiers...@meiers.net wrote:
Hi Philip,
ListView throws away all its children before rendering. When a component is
removed, its model gets detached.
Your AjaxLink has your LoadableDetachableModel
Re: hebrew text looks like ×׳—׳‘׳¨׳ •
Hi, the header is ok, but Wicket's xml parser won't be able to infer the encoding. Use IMarkupSettings#setDefaultMarkupEncoding() as Martin has suggested. Regards Sven On 01/09/2012 03:53 PM, Bertrand Guay-Paquet wrote: After some research, I'm now using the following html header : !DOCTYPE html html xmlns:wicket=http://wicket.apache.org; head meta charset=UTF-8 [xmlns:wicket=http://wicket.apache.org;] is stripped by Wicket when pages are rendered by default. This header does not trigger quirks mode and is valid for html5, which also works for html4 content. Please correct me if this header is wrong for some reason. Regards, Bertrand On 09/01/2012 7:52 AM, Richard W. Adams wrote: HTML files should not have have an XML header. Only XHTML files should. From: armholdarmh...@gmail.com To: users@wicket.apache.org Date: 01/06/2012 08:31 PM Subject:Re: hebrew text looks like ×׳—׳‘׳¨׳• I went though this pain a few months ago too. Here are all the places I had to hit: 1. In your HTML files: ?xml version=1.0 encoding=UTF-8? And also in yourhead: meta http-equiv=Content-Type content=text/html; charset=UTF-8 2. For property files, if you use i18n you will need to use the foo.xml format rather than foo.properties, and also include the above?xml version=1.0 encoding=UTF-8? in each of them. 3. In your WicketApplication.java: // wicket 1.4; perhaps different in 1.5 getRequestCycleSettings().setResponseRequestEncoding(UTF-8); getMarkupSettings().setDefaultMarkupEncoding(UTF-8); 4. In your pom.xml (to cover any copied resources): properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties 5. Finally, in Intellij: File - Preferences - File Encodings - IDE Encoding: UTF-8. What made this frustrating is that it always seemed to render fine with the embedded Jetty, but not with Tomcat (so things would always look great locally, but fall apart in production). -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/hebrew-text-looks-like-tp4260875p4271694.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 ** This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies. ** - 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: hebrew text looks like ×׳—׳‘׳¨׳ •
Yes this is good advice. I actually use the html header + setDefaultMarkupEncoding(). On 09/01/2012 1:36 PM, Sven Meier wrote: Hi, the header is ok, but Wicket's xml parser won't be able to infer the encoding. Use IMarkupSettings#setDefaultMarkupEncoding() as Martin has suggested. Regards Sven On 01/09/2012 03:53 PM, Bertrand Guay-Paquet wrote: After some research, I'm now using the following html header : !DOCTYPE html html xmlns:wicket=http://wicket.apache.org; head meta charset=UTF-8 [xmlns:wicket=http://wicket.apache.org;] is stripped by Wicket when pages are rendered by default. This header does not trigger quirks mode and is valid for html5, which also works for html4 content. Please correct me if this header is wrong for some reason. Regards, Bertrand On 09/01/2012 7:52 AM, Richard W. Adams wrote: HTML files should not have have an XML header. Only XHTML files should. From: armholdarmh...@gmail.com To: users@wicket.apache.org Date: 01/06/2012 08:31 PM Subject:Re: hebrew text looks like ×׳—׳‘׳¨׳• I went though this pain a few months ago too. Here are all the places I had to hit: 1. In your HTML files: ?xml version=1.0 encoding=UTF-8? And also in yourhead: meta http-equiv=Content-Type content=text/html; charset=UTF-8 2. For property files, if you use i18n you will need to use the foo.xml format rather than foo.properties, and also include the above?xml version=1.0 encoding=UTF-8? in each of them. 3. In your WicketApplication.java: // wicket 1.4; perhaps different in 1.5 getRequestCycleSettings().setResponseRequestEncoding(UTF-8); getMarkupSettings().setDefaultMarkupEncoding(UTF-8); 4. In your pom.xml (to cover any copied resources): properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties 5. Finally, in Intellij: File - Preferences - File Encodings - IDE Encoding: UTF-8. What made this frustrating is that it always seemed to render fine with the embedded Jetty, but not with Tomcat (so things would always look great locally, but fall apart in production). -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/hebrew-text-looks-like-tp4260875p4271694.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 ** This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies. ** - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxLink causes list model to be detached before rendering!
Thanks Sven, interesting idea however, rows is not accessible to
onClick() method as compilation error, rows not accessible as may
not be initialised. I guess Id have to getParent() loop until I found
a ListView component :(
Cheers, Phil.
On Mon, Jan 9, 2012 at 6:31 PM, Sven Meier s...@meiers.net wrote:
you can ... give each item an isolated model
Actually ListItemModel doesn't detach the owning list's model, so it's
'isolated' already.
For your AjaxLink you can access the list view instead:
IModelListString model = ... // not final !!
final ListViewString rows = new ListViewString(rows, model)
{
@Override
protected void populateItem(final ListItemString item)
{
AjaxLinkVoid link = new AjaxLinkVoid(link)
{
@Override
public void onClick(AjaxRequestTarget target)
{
rows.getModelObject().remove(item.getIndex()-1);
target.add(TestPage.this);
}
};
link.add(new Label(label, item.getModel()));
item.add(link);
}
};
Sven
On 01/09/2012 05:13 PM, Igor Vaynberg wrote:
the problem here is that the listitem's model is tied to the
listview's model. so calling detach() on the listview item causes the
detachment of the listview's model.
you can either override getlistitemmodel() on the listview and give
each item an isolated model, or you can use a dataview or another
non-listview repeater.
as far as the many calls to detach(), they are nearly impossible to
avoid without making the framework much more complicated. in practice
the logic in detach() is very simple so having multiple calls to it is
not a problem.
-igor
On Mon, Jan 9, 2012 at 5:06 AM, Philip Wilkinson
wilkinson.phi...@gmail.com wrote:
Sven,
Thanks for your speedy reply.
Indeed you are correct, removing the model from the AjaxLink stops the
model from becoming detached immediately before rendering.
I now realise that my cut-down example was too cut-down! The AjaxLink
is actually there to remove the entry from the list, requiring the
list model to be accessible to the link. So the implementation would
be something like:-
public class TestPage extends WebPage
{
private ListString testList = new ArrayListString() {{
add(A); add(B); add(C);}};
public TestPage()
{
setOutputMarkupId(true);
final IModelListString model = new
LoadableDetachableModelListString()
{
@Override
protected ListString load()
{
System.out.println(LOAD LIST MODEL +
Integer.toHexString(TestPage.this.hashCode()));
return testList;
}
@Override
public void detach()
{
System.out.println(DETACH LIST MODEL +
Integer.toHexString(TestPage.this.hashCode()));
super.detach();
}
};
final ListViewString rows = new ListViewString(rows, model)
{
@Override
protected void populateItem(final ListItemString item)
{
System.out.println(populateItem +
Integer.toHexString(TestPage.this.hashCode()));
// with ajax link to remove entry.
AjaxLinkListString link = new
AjaxLinkListString(link, model)
{
@Override
public void onClick(AjaxRequestTarget target)
{
getModelObject().remove(item.getIndex()-1);
target.add(TestPage.this); // normally the
target would be a containing panel, but for this example, the page
will do!
}
};
link.add(new Label(label, item.getModel()));
item.add(link);
}
};
add(rows);
}
@Override
public void detachModels()
{
System.out.println(DETACH MODELS +
Integer.toHexString(TestPage.this.hashCode()));
super.detachModels();
}
}
Possibly I could get around this by not setting the model on the
AjaxLink, so wicket doesn't try to detach it, and passing the list
model in separately. But that feels like I'm not following the wicket
way if I do something like that :(. I think that knowing what the
AjaxLink is doing, removing an entry from the list, the most
appropriate model for the AjaxLink is the list model!
Do you think there's a case here for the wicket framework being a
little smarter about when it detaches its models?
I think that only the relevant models need to be detached only once
after every response has been
Re: AjaxLink causes list model to be detached before rendering!
Ah, yes, stupid compiler ;).
You can keep the model final and use it on your onClick(), but *not*
passing it to the AjaxLink constructor:
final IModelListStringmodel = ... // final again !!
final ListViewStringrows = new ListViewString(rows, model)
{
@Override
protected void populateItem(final ListItemStringitem)
{
AjaxLinkVoidlink = new AjaxLinkVoid(link) // no model
{
@Override
public void onClick(AjaxRequestTarget target)
{
model.remove(item.getIndex()-1);
target.add(TestPage.this);
}
};
...
}
};
On 01/09/2012 10:05 PM, Philip Wilkinson wrote:
Thanks Sven, interesting idea however, rows is not accessible to
onClick() method as compilation error, rows not accessible as may
not be initialised. I guess Id have to getParent() loop until I found
a ListView component :(
Cheers, Phil.
On Mon, Jan 9, 2012 at 6:31 PM, Sven Meiers...@meiers.net wrote:
you can ... give each item an isolated model
Actually ListItemModel doesn't detach the owning list's model, so it's
'isolated' already.
For your AjaxLink you can access the list view instead:
IModelListStringmodel = ... // not final !!
final ListViewStringrows = new ListViewString(rows, model)
{
@Override
protected void populateItem(final ListItemStringitem)
{
AjaxLinkVoidlink = new AjaxLinkVoid(link)
{
@Override
public void onClick(AjaxRequestTarget target)
{
rows.getModelObject().remove(item.getIndex()-1);
target.add(TestPage.this);
}
};
link.add(new Label(label, item.getModel()));
item.add(link);
}
};
Sven
On 01/09/2012 05:13 PM, Igor Vaynberg wrote:
the problem here is that the listitem's model is tied to the
listview's model. so calling detach() on the listview item causes the
detachment of the listview's model.
you can either override getlistitemmodel() on the listview and give
each item an isolated model, or you can use a dataview or another
non-listview repeater.
as far as the many calls to detach(), they are nearly impossible to
avoid without making the framework much more complicated. in practice
the logic in detach() is very simple so having multiple calls to it is
not a problem.
-igor
On Mon, Jan 9, 2012 at 5:06 AM, Philip Wilkinson
wilkinson.phi...@gmail.comwrote:
Sven,
Thanks for your speedy reply.
Indeed you are correct, removing the model from the AjaxLink stops the
model from becoming detached immediately before rendering.
I now realise that my cut-down example was too cut-down! The AjaxLink
is actually there to remove the entry from the list, requiring the
list model to be accessible to the link. So the implementation would
be something like:-
public class TestPage extends WebPage
{
private ListStringtestList = new ArrayListString() {{
add(A); add(B); add(C);}};
public TestPage()
{
setOutputMarkupId(true);
final IModelListStringmodel = new
LoadableDetachableModelListString()
{
@Override
protected ListStringload()
{
System.out.println(LOAD LIST MODEL +
Integer.toHexString(TestPage.this.hashCode()));
return testList;
}
@Override
public void detach()
{
System.out.println(DETACH LIST MODEL +
Integer.toHexString(TestPage.this.hashCode()));
super.detach();
}
};
final ListViewStringrows = new ListViewString(rows, model)
{
@Override
protected void populateItem(final ListItemStringitem)
{
System.out.println(populateItem +
Integer.toHexString(TestPage.this.hashCode()));
// with ajax link to remove entry.
AjaxLinkListStringlink = new
AjaxLinkListString(link, model)
{
@Override
public void onClick(AjaxRequestTarget target)
{
getModelObject().remove(item.getIndex()-1);
target.add(TestPage.this); // normally the
target would be a containing panel, but for this example, the page
will do!
}
};
link.add(new Label(label, item.getModel()));
item.add(link);
Re: AjaxLink causes list model to be detached before rendering!
Hi Sven,
OK thanks, that's good, with this..
final IModelListString model = new
LoadableDetachableModelListString()
{
@Override
protected ListString load()
{
System.out.println(LOAD LIST MODEL +
Integer.toHexString(TestPage.this.hashCode()));
return testList;
}
@Override
public void detach()
{
System.out.println(DETACH LIST MODEL +
Integer.toHexString(TestPage.this.hashCode()));
super.detach();
}
};
final ListViewString rows = new ListViewString(rows, model)
{
@Override
protected void populateItem(final ListItemString item)
{
System.out.println(populateItem +
Integer.toHexString(TestPage.this.hashCode()));
// with ajax link to remove entry.
AjaxLinkVoid link = new AjaxLinkVoid(link)
{
@Override
public void onClick(AjaxRequestTarget target)
{
model.getObject().remove(item.getIndex()-1);
target.add(TestPage.this);
}
};
link.add(new Label(label, item.getModel()));
item.add(link);
}
};
I get the following diagnostic output..
LOAD LIST MODEL 12d9a936
populateItem 12d9a936
populateItem 12d9a936
populateItem 12d9a936
DETACH MODELS 12d9a936
DETACH LIST MODEL 12d9a936
DETACH MODELS 12d9a936
DETACH LIST MODEL 12d9a936
which is perfect!
So now I (and everyone else) just has to remember not to pass the List
Views model into the constructor of a component in a List Views Item!
On Mon, Jan 9, 2012 at 9:13 PM, Sven Meier s...@meiers.net wrote:
Ah, yes, stupid compiler ;).
You can keep the model final and use it on your onClick(), but *not* passing
it to the AjaxLink constructor:
final IModelListString model = ... // final again !!
final ListViewString rows = new ListViewString(rows, model)
{
@Override
protected void populateItem(final ListItemString item)
{
AjaxLinkVoid link = new AjaxLinkVoid(link) // no model
{
@Override
public void onClick(AjaxRequestTarget target)
{
model.remove(item.getIndex()-1);
target.add(TestPage.this);
}
};
...
}
};
On 01/09/2012 10:05 PM, Philip Wilkinson wrote:
Thanks Sven, interesting idea however, rows is not accessible to
onClick() method as compilation error, rows not accessible as may
not be initialised. I guess Id have to getParent() loop until I found
a ListView component :(
Cheers, Phil.
On Mon, Jan 9, 2012 at 6:31 PM, Sven Meiers...@meiers.net wrote:
you can ... give each item an isolated model
Actually ListItemModel doesn't detach the owning list's model, so it's
'isolated' already.
For your AjaxLink you can access the list view instead:
IModelListString model = ... // not final !!
final ListViewString rows = new ListViewString(rows,
model)
{
@Override
protected void populateItem(final ListItemString item)
{
AjaxLinkVoid link = new AjaxLinkVoid(link)
{
@Override
public void onClick(AjaxRequestTarget target)
{
rows.getModelObject().remove(item.getIndex()-1);
target.add(TestPage.this);
}
};
link.add(new Label(label, item.getModel()));
item.add(link);
}
};
Sven
On 01/09/2012 05:13 PM, Igor Vaynberg wrote:
the problem here is that the listitem's model is tied to the
listview's model. so calling detach() on the listview item causes the
detachment of the listview's model.
you can either override getlistitemmodel() on the listview and give
each item an isolated model, or you can use a dataview or another
non-listview repeater.
as far as the many calls to detach(), they are nearly impossible to
avoid without making the framework much more complicated. in practice
the logic in detach() is very simple so having multiple calls to it is
not a problem.
-igor
On Mon, Jan 9, 2012 at 5:06 AM, Philip Wilkinson
wilkinson.phi...@gmail.com wrote:
Sven,
Thanks for your speedy reply.
Indeed you are correct, removing the model from the AjaxLink stops the
model from becoming detached immediately before rendering.
I now realise that
Re: stateless, not versioned pages - session problem
ok I found the reason oAuth provider adds this #base_domain to callback url. I just dont understand why it stayed after redirection. the other issue (that after redirect urls looks like callback) is that I use ReplaceHandlerException and I rewrite data from original response to preserve cookies. so I will look at this 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
Problem with relative URLs
I'm having a problem with relative URLs.
If the current page is:
content/mypage/n1/p1/n2/fred
And it contains a link to
content/mypage/n1/p1/n2/jane
The relative URL rendered to HTML is:
../../../../../../jane
Which of course is wrong as the browser tries to jump to:
jane
instead of
content/mypage/n1/p1/n2/jane
I looked at the URL renderer and it was returning just 'jane' instead of
../jane
I'm not sure if this is the right approach but I changed
UrlRenderer.java (seemed like an 'out by 1' bug) so that it returns the
correct relative URL string. The git diff with a very recent
wicket-1.5.x branch HEAD is shown below.
../jane
Even though this now returns the correct relative URL this doesn't the
problem. Somehow later at render time the extra ../../../../ sequence
was prefixed to the already correct URL.
I think I know why - the URL is double processed by the UrlRenderer.
First it is converted from a Url object to a relative string via String
UrlRenderer.renderRelativeUrl(final Url url) - returning ../jane as
above (after patch is applied).
Second, during rendering it is passed to
RelativePathPrefixHandler.onComponentTag which makes a relative path of
the path that is already relative, using String
UrlRenderer.renderContextRelativeUrl(String url) - of course this time
there is no common path segments so the sequence of ../ segments
prefixed to the given URL string takes it right back to the root.
Why would the relative path be processed again?
I can understand that UrlRenderer might need two relative Url creation
methods - one that works on a Url object and one that works on a String
object but I can't understand why both would be called as that breaks
things.
Path to 'fix' (maybe, if it is actually broken)
UrlRenderer.renderRelativeUrl(final Url url).
index d636450..ebe87f5 100644
---
a/wicket-request/src/main/java/org/apache/wicket/request/UrlRenderer.jav
a
+++
b/wicket-request/src/main/java/org/apache/wicket/request/UrlRenderer.jav
a
@@ -25,6 +25,8 @@ import org.apache.wicket.util.lang.Args;
import org.apache.wicket.util.string.PrependingStringBuffer;
import org.apache.wicket.util.string.Strings;
+import javax.servlet.http.HttpServletRequest;
+
/**
* Takes care of rendering URLs.
* p
@@ -211,30 +213,41 @@ public class UrlRenderer
}
}
- // we want the new URL to have at least one
segment (other than possible ../)
- if ((last != null) (urlSegments.isEmpty() ||
(baseUrlSegments.size() == common)))
- {
- --common;
- urlSegments.add(0, last);
- }
-
- int baseUrlSize = baseUrlSegments.size();
- if (common + 1 == baseUrlSize
urlSegments.isEmpty())
+ if ( common 0 )
{
- newSegments.add(.);
+ // URL has some elements common to
baseUrl so output a relative URL
+
+ // we want the new URL to have at least
one segment (other than possible ../)
+ if ((last != null)
(urlSegments.isEmpty() || (baseUrlSegments.size() == common)))
+ {
+ --common;
+ urlSegments.add(0, last);
+ }
+
+ int baseUrlSize =
baseUrlSegments.size();
+ if (common + 1 == baseUrlSize
urlSegments.isEmpty())
+ {
+ newSegments.add(.);
+ }
+ else
+ {
+
+ for (int i = common; i
baseUrlSize; ++i)
+ {
+ newSegments.add(..);
+ }
+ }
+ newSegments.addAll(urlSegments);
+
+ String renderedUrl = new
Url(newSegments, url.getQueryParameters()).toString();
+ return Strings.isEmpty(renderedUrl) ?
. : renderedUrl;
}
else
{
-
- for (int i = common + 1; i
baseUrlSize; ++i)
- {
- newSegments.add(..);
- }
+ // Url has no common elements so convert
to an absolute URL
+ return / + url.toString();
}
- newSegments.addAll(urlSegments);
-
- String renderedUrl =
Re: Problem with relative URLs
On Mon, Jan 9, 2012 at 5:51 PM, Chris Colman
chr...@stepaheadsoftware.com wrote:
I'm having a problem with relative URLs.
If the current page is:
content/mypage/n1/p1/n2/fred
And it contains a link to
content/mypage/n1/p1/n2/jane
The relative URL rendered to HTML is:
../../../../../../jane
Which of course is wrong as the browser tries to jump to:
jane
instead of
content/mypage/n1/p1/n2/jane
I looked at the URL renderer and it was returning just 'jane' instead of
../jane
actually jane is correct and ../jane is incorrect.
if the browser is on content/mypage/n1/p1/n2/fred
then going to a relative url jane will produce
content/mypage/n1/p1/n2/jane
which is what you want, no...?
I'm not sure if this is the right approach but I changed
UrlRenderer.java (seemed like an 'out by 1' bug) so that it returns the
correct relative URL string. The git diff with a very recent
wicket-1.5.x branch HEAD is shown below.
../jane
Even though this now returns the correct relative URL this doesn't the
problem. Somehow later at render time the extra ../../../../ sequence
was prefixed to the already correct URL.
I think I know why - the URL is double processed by the UrlRenderer.
First it is converted from a Url object to a relative string via String
UrlRenderer.renderRelativeUrl(final Url url) - returning ../jane as
above (after patch is applied).
Second, during rendering it is passed to
RelativePathPrefixHandler.onComponentTag which makes a relative path of
the path that is already relative, using String
UrlRenderer.renderContextRelativeUrl(String url) - of course this time
there is no common path segments so the sequence of ../ segments
prefixed to the given URL string takes it right back to the root.
why is RelativePathPrefixHandler invoked on that tag? sounds a little funky...
-igor
Why would the relative path be processed again?
I can understand that UrlRenderer might need two relative Url creation
methods - one that works on a Url object and one that works on a String
object but I can't understand why both would be called as that breaks
things.
Path to 'fix' (maybe, if it is actually broken)
UrlRenderer.renderRelativeUrl(final Url url).
index d636450..ebe87f5 100644
---
a/wicket-request/src/main/java/org/apache/wicket/request/UrlRenderer.jav
a
+++
b/wicket-request/src/main/java/org/apache/wicket/request/UrlRenderer.jav
a
@@ -25,6 +25,8 @@ import org.apache.wicket.util.lang.Args;
import org.apache.wicket.util.string.PrependingStringBuffer;
import org.apache.wicket.util.string.Strings;
+import javax.servlet.http.HttpServletRequest;
+
/**
* Takes care of rendering URLs.
* p
@@ -211,30 +213,41 @@ public class UrlRenderer
}
}
- // we want the new URL to have at least one
segment (other than possible ../)
- if ((last != null) (urlSegments.isEmpty() ||
(baseUrlSegments.size() == common)))
- {
- --common;
- urlSegments.add(0, last);
- }
-
- int baseUrlSize = baseUrlSegments.size();
- if (common + 1 == baseUrlSize
urlSegments.isEmpty())
+ if ( common 0 )
{
- newSegments.add(.);
+ // URL has some elements common to
baseUrl so output a relative URL
+
+ // we want the new URL to have at least
one segment (other than possible ../)
+ if ((last != null)
(urlSegments.isEmpty() || (baseUrlSegments.size() == common)))
+ {
+ --common;
+ urlSegments.add(0, last);
+ }
+
+ int baseUrlSize =
baseUrlSegments.size();
+ if (common + 1 == baseUrlSize
urlSegments.isEmpty())
+ {
+ newSegments.add(.);
+ }
+ else
+ {
+
+ for (int i = common; i
baseUrlSize; ++i)
+ {
+ newSegments.add(..);
+ }
+ }
+ newSegments.addAll(urlSegments);
+
+ String renderedUrl = new
Url(newSegments, url.getQueryParameters()).toString();
+ return Strings.isEmpty(renderedUrl) ?
. : renderedUrl;
}
else
{
-
-
RE: Problem with relative URLs
I looked at the URL renderer and it was returning just 'jane' instead of ../jane actually jane is correct and ../jane is incorrect. if the browser is on content/mypage/n1/p1/n2/fred then going to a relative url jane will produce content/mypage/n1/p1/n2/jane which is what you want, no...? Yeah, my bad. I forgot the last segment is not actually treated as a directory but the resource you want to fetch from that directory. Too many late nights ;) why is RelativePathPrefixHandler invoked on that tag? sounds a little funky... Yeah. Ok so this funkiness sounds like the real problem. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Problem with relative URLs
why is RelativePathPrefixHandler invoked on that tag? sounds a little funky... -igor I'm using UrlPathPageParametersEncoder for backwards compatibility with 1.5 links. I'm not sure if that could be causing the funkiness of RelativePathPrefixHandler being invoked. Are BookmarkablePageLinks treated as absolute or relative URLs? They could probably be quite safely be treated as absolute URLs because they always contain all segments from the root anyway. Initially I had mounted the pages without a leading slash in the path. I added the leading slash but it made no difference - I guess it could be implied. Is there any benefit in converting a URLs like: /content/page/n1/v1/n2/jane to On a page /content/page/n1/v1/n2/fred to jane apart from the obvious shorter URL? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Problem with relative URLs
wicket by default always generates relative urls. this is the safest/easiest approach for fronting the app with a proxy, which most people do... -igor On Mon, Jan 9, 2012 at 6:59 PM, Chris Colman chr...@stepaheadsoftware.com wrote: why is RelativePathPrefixHandler invoked on that tag? sounds a little funky... -igor I'm using UrlPathPageParametersEncoder for backwards compatibility with 1.5 links. I'm not sure if that could be causing the funkiness of RelativePathPrefixHandler being invoked. Are BookmarkablePageLinks treated as absolute or relative URLs? They could probably be quite safely be treated as absolute URLs because they always contain all segments from the root anyway. Initially I had mounted the pages without a leading slash in the path. I added the leading slash but it made no difference - I guess it could be implied. Is there any benefit in converting a URLs like: /content/page/n1/v1/n2/jane to On a page /content/page/n1/v1/n2/fred to jane apart from the obvious shorter URL? - 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: Problem with relative URLs
wicket by default always generates relative urls. this is the
safest/easiest approach for fronting the app with a proxy, which most
people do...
-igor
I guess there are three types of urls:
Relative: Url with no leading protocol or '/'
Absolute: Urls with a leading /
Complete: Urls with http://hostname/
The absolute I'm referring to is just the one with the leading slash but
no http://hostname/
Should a URL with a leading / but no protocol+hostname cause problems
with proxies?
In regards to the rewriteToContextRelative funkiness:
The RelativePathPrefixHandler is modifying the already relative URL
because it has been generated by the MountedMapper.buildUrl with no
leading / and so passes the test that checks if it is relative:
public void onComponentTag(Component component, ComponentTag tag)
{
// Modify all relevant attributes
for (String attrName : attributeNames)
{
String attrValue =
tag.getAttributes().getString(attrName);
if
(
(attrValue != null)
(attrValue.startsWith(/) == false)
(!attrValue.contains(:))
!(attrValue.startsWith(#))
)
{
tag.getAttributes().put
(
attrName,
UrlUtils.rewriteToContextRelative(
attrValue,RequestCycle.get()
)
);
}
}
}
This could actually be a boundary case as I have other
BookmarkablePageLinks with a different number of segments in common with
the current page and they work fine as relative links.
The case that doesn't seem to work is where the number of non common
segments (i.e. at the end of the URL) is equal to 1.
Maybe the UrlRenderer should be returning ./jane instead of just jane.
Hm.
On Mon, Jan 9, 2012 at 6:59 PM, Chris Colman
chr...@stepaheadsoftware.com wrote:
why is RelativePathPrefixHandler invoked on that tag? sounds a little
funky...
-igor
I'm using UrlPathPageParametersEncoder for backwards compatibility
with
1.5 links. I'm not sure if that could be causing the funkiness of
RelativePathPrefixHandler being invoked.
Are BookmarkablePageLinks treated as absolute or relative URLs? They
could probably be quite safely be treated as absolute URLs because
they
always contain all segments from the root anyway.
Initially I had mounted the pages without a leading slash in the
path. I
added the leading slash but it made no difference - I guess it could
be
implied.
Is there any benefit in converting a URLs like:
/content/page/n1/v1/n2/jane to
On a page
/content/page/n1/v1/n2/fred to
jane
apart from the obvious shorter URL?
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
