You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martin Grigorov <mg...@apache.org> on 2016/04/02 00:07:41 UTC
(Stupid) idea how to get rid of ?pageId in the url
Hi,
https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0#IdeasforWicket8.0-BetterSEOforstatefulpages
The best way to send the page id with each request without "polluting" the
url is to use request headers. Unfortunately there is no way to add request
headers for non-Ajax requests, so this won't work.
Now I'm thinking of another approach - store the id in the Session.
(It is 01:00 so forgive me if I miss something).
?pageId is added only for stateful pages, i.e. Wicket binds a Session
already.
Instead of encoding the pageId in the query string we can store it (e.g. as
<pageId, pageClass> struct) in the Session.
All links in the page will still use ?pageId. They do not appear in the
browser's address bar so they do not need to be changed!
Only the url for the page redirects won't have it.
Whenever a page is rendered the struct will be updated. If the page is
stateless then the struct will be null-ified.
If the user reloads the page (F5) then Wicket will detect that this is the
same page class as the one in the struct and use the page id.
If the application uses setResponsePage(Class) or
RestartResponseException(Class) then the struct will be null-ified. So the
application will be able to redirect to a new instance of the same page
type.
The only problem that I see is using BookmarkablePageLink that links to the
current page. In that case Wicket will serve the old instance instead of
creating a new one.
What other problems do you see in this approach ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
Re: (Stupid) idea how to get rid of ?pageId in the url
Posted by Martin Grigorov <mg...@apache.org>.
Thanks, Sven!
Back button might work with HTML5 history APIs but multi window support is
indeed a problem.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Sat, Apr 2, 2016 at 10:37 AM, Sven Meier <sv...@meiers.net> wrote:
> ... and what about back-button support?
>
> Sven
>
>
> On 02.04.2016 09:41, Sven Meier wrote:
>
>> Hi Martin,
>>
>> what about multi-window support?
>>
>> I.e. the user is working on different page instances of same type
>> simultaneously?
>>
>> Sven
>>
>> On 02.04.2016 00:07, Martin Grigorov wrote:
>>
>>> Hi,
>>>
>>>
>>> https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0#IdeasforWicket8.0-BetterSEOforstatefulpages
>>>
>>> The best way to send the page id with each request without "polluting"
>>> the
>>> url is to use request headers. Unfortunately there is no way to add
>>> request
>>> headers for non-Ajax requests, so this won't work.
>>>
>>> Now I'm thinking of another approach - store the id in the Session.
>>> (It is 01:00 so forgive me if I miss something).
>>> ?pageId is added only for stateful pages, i.e. Wicket binds a Session
>>> already.
>>> Instead of encoding the pageId in the query string we can store it (e.g.
>>> as
>>> <pageId, pageClass> struct) in the Session.
>>> All links in the page will still use ?pageId. They do not appear in the
>>> browser's address bar so they do not need to be changed!
>>> Only the url for the page redirects won't have it.
>>> Whenever a page is rendered the struct will be updated. If the page is
>>> stateless then the struct will be null-ified.
>>> If the user reloads the page (F5) then Wicket will detect that this is
>>> the
>>> same page class as the one in the struct and use the page id.
>>> If the application uses setResponsePage(Class) or
>>> RestartResponseException(Class) then the struct will be null-ified. So
>>> the
>>> application will be able to redirect to a new instance of the same page
>>> type.
>>>
>>> The only problem that I see is using BookmarkablePageLink that links to
>>> the
>>> current page. In that case Wicket will serve the old instance instead of
>>> creating a new one.
>>>
>>> What other problems do you see in this approach ?
>>>
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>>
>>
>
Re: (Stupid) idea how to get rid of ?pageId in the url
Posted by Sven Meier <sv...@meiers.net>.
... and what about back-button support?
Sven
On 02.04.2016 09:41, Sven Meier wrote:
> Hi Martin,
>
> what about multi-window support?
>
> I.e. the user is working on different page instances of same type
> simultaneously?
>
> Sven
>
> On 02.04.2016 00:07, Martin Grigorov wrote:
>> Hi,
>>
>> https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0#IdeasforWicket8.0-BetterSEOforstatefulpages
>>
>>
>> The best way to send the page id with each request without
>> "polluting" the
>> url is to use request headers. Unfortunately there is no way to add
>> request
>> headers for non-Ajax requests, so this won't work.
>>
>> Now I'm thinking of another approach - store the id in the Session.
>> (It is 01:00 so forgive me if I miss something).
>> ?pageId is added only for stateful pages, i.e. Wicket binds a Session
>> already.
>> Instead of encoding the pageId in the query string we can store it
>> (e.g. as
>> <pageId, pageClass> struct) in the Session.
>> All links in the page will still use ?pageId. They do not appear in the
>> browser's address bar so they do not need to be changed!
>> Only the url for the page redirects won't have it.
>> Whenever a page is rendered the struct will be updated. If the page is
>> stateless then the struct will be null-ified.
>> If the user reloads the page (F5) then Wicket will detect that this
>> is the
>> same page class as the one in the struct and use the page id.
>> If the application uses setResponsePage(Class) or
>> RestartResponseException(Class) then the struct will be null-ified.
>> So the
>> application will be able to redirect to a new instance of the same page
>> type.
>>
>> The only problem that I see is using BookmarkablePageLink that links
>> to the
>> current page. In that case Wicket will serve the old instance instead of
>> creating a new one.
>>
>> What other problems do you see in this approach ?
>>
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>
Re: (Stupid) idea how to get rid of ?pageId in the url
Posted by Sven Meier <sv...@meiers.net>.
Hi Martin,
what about multi-window support?
I.e. the user is working on different page instances of same type
simultaneously?
Sven
On 02.04.2016 00:07, Martin Grigorov wrote:
> Hi,
>
> https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0#IdeasforWicket8.0-BetterSEOforstatefulpages
>
> The best way to send the page id with each request without "polluting" the
> url is to use request headers. Unfortunately there is no way to add request
> headers for non-Ajax requests, so this won't work.
>
> Now I'm thinking of another approach - store the id in the Session.
> (It is 01:00 so forgive me if I miss something).
> ?pageId is added only for stateful pages, i.e. Wicket binds a Session
> already.
> Instead of encoding the pageId in the query string we can store it (e.g. as
> <pageId, pageClass> struct) in the Session.
> All links in the page will still use ?pageId. They do not appear in the
> browser's address bar so they do not need to be changed!
> Only the url for the page redirects won't have it.
> Whenever a page is rendered the struct will be updated. If the page is
> stateless then the struct will be null-ified.
> If the user reloads the page (F5) then Wicket will detect that this is the
> same page class as the one in the struct and use the page id.
> If the application uses setResponsePage(Class) or
> RestartResponseException(Class) then the struct will be null-ified. So the
> application will be able to redirect to a new instance of the same page
> type.
>
> The only problem that I see is using BookmarkablePageLink that links to the
> current page. In that case Wicket will serve the old instance instead of
> creating a new one.
>
> What other problems do you see in this approach ?
>
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>