Gili,
I think the confusion here is that you are confusing bookmarkable pages
and static pages. Even if a page is bookmarkable it can still be dynamic
(e.g. have different content each time it is visited). This content may
be built from a database and may even react to cookies that a user may
or may not have on their page (e.g. persistent login). Therefore, it is
still necessary to store the page in a session so that the components on
a bookmarkable page can receive events (because the component may change
each time the page is accessed).
What I think you are actually asking for is the ability to mark a page
as 'static' which indicates that its content does not change on each
access and thus the state does not need to be held in the session. This
is certainly something we would consider as part of stateless page
support in version 1.2.
regards,
Chris
Gili wrote:
I'm going to mass-reply to all the emails on this topic at once,
so please bear with me :)
If one clicks on a link from one bookmarkable page onto another,
why should a session get created? As far as I can tell, it shouldn't.
If one clicks on a link from a bookmarkable page to a
non-bookmarkable one, creating a session is fine.
And even if Google does somehow magically support cookies, what
about the hundreds of different other crawlers that might not?
Besides, we don't even know that Google does cookies :) I'd rather not
make this assumption if I can avoid it.
Matej Knopp wrote:
No, I'm afraid that wouldn't help. URLS without session id would
create new URL. I don't think it's desired behavior.
I meant ...would create new session (not new URL).
I disagree. This is *exactly* what we want. We want lazy session
creation, in order to ensure that moving from one bookmarkable page to
another does not require a session. Upon you hit a non-bookmarkable
page, go ahead and create a session, I don't see a problem with that.
I believe it's encodeURL method of HttpServletResponse that inserts
the jessionid in URL. The container itself has AFAIK no idea what in
the response body is url and what's not.
Right, but it is Wicket that is calling encodeURL in the first
place and we *do* know if the response is bookmarkable or not so we
can control this.
However, when the client has cookies enabled, jsessionid usually goes
away after the first request. That must be the container that decides
that, probably in it's implementation of the servlet API.
This is because jsessionid moves from URL rewriting to getting
stored in a cookie. I'm not 100% sure why it shows up even the first
time, but I don't think this is the point either. We shouldn't require
a session for bookmarkable pages.
yes, but it is the container's responsibilty. It is not Wicket adding
it.
It is Wicket's responsibility not to create the session in the
first place.
Gili
Matej Knopp wrote:
Johan Compagner wrote:
who is inserting the jsessionid?
I think it happens when we call encodeUrl() maybe we shouldn't do
that for bookmarkable urls?
Don't think so. When cookies are disabled clicking on URL without
session id would lose the session (resp. create a new one). So after
clicking on a bookmarkable page you wouldn't be able to continue
working on application.
I don't think jsessionid as a problem here. Google indexes it well.
Maybe it's not even generated for google. Maybe google crawler
pretends to support cookies and just throws them away.
-Matej
johan
Matej Knopp wrote:
Once again. The URLS of wicket application that need to be crawled
are bookmarkable pages (urls like
app?bookmarkablePage=foo.bar.pageClass).
Bookmarkable pages have only one parameter. So they are already
crawler friendly.
All other (app?component=, app?path=, etc) should not be crawled at
all, because they lead to session relative pages.
So the only thing to take care of is removing jsessionid form the
middle of the url and placing them as parameter to url tail.
-Matej
Gili wrote:
URL rewriting seems like a decent option so long as you recall
that Google limits you to two parameters. This means the problem
now becomes rewriting Wicket URLs to be "crawler-friendly" with
one or two parameters :)
Gili
Eelco Hillenius wrote:
Gili wrote:
http://www.google.com/webmasters/guidelines.html
Note that requiring cookies might prevent the crawler from
indexing your pages.
This is further discussed here:
http://www.searchengineguide.com/whalen/2004/0210_jw1.html and
http://www.optimizekit.com/kb/categories/Do's-and-Dont's/
Major points here: crawlers will absolutely refuse to index
pages with cookies or jsessionids.
If I had a choice between decent back support versus getting
indexed by Google, I'd choose the latter :) Hopefully we can do
both.
I take your point seriously, but as stated before, we just can't
do that. There are break out's though, the easiest one to do url
rewriting. This is from the site you sent a link to above:
<quote>
One way to circumvent this difficulty is to create static
versions of your site's dynamic pages for search engines to
crawl. Unfortunately, duplicating your pages is a huge amount of
extra work and a constant maintenance chore, plus the resulting
pages are never quite up-to-date — all the headaches dynamic
pages were designed to eliminate. A far better strategy is to
follow the lead of Amazon and rewrite your dynamic URLs in a
syntax that search engines will gladly crawl.
*URLs that look like this: *
amazon.com/store?shop=cd&sku= B00004WFIZ&ref=p_ir_m&sessionID=
107-6571839-6268523
*/become:/*
amazon.com/exec/obidos/ASIN/ref=
B00004WFIZ/ref=pd_ir_m/107-6571839-6268523
</quote>
You could do either the rewrite (the easiest) or create static
pages from your dynamic content now.
Another thing I'd like to note here is that Wicket doesn't force
you to use cookies. Wicket does all the encoding for you, where's
when working with e.g. plain JSP's or model 2 frameworks, it is a
common thing to forget to encode all links. And if you forget it,
it means your browser has to fall back on cookies, or that - in
case you configured your servlet engine to not use cookies - it
fails. I've seen this go wrong (developers forgetting it) in
/every/ webapplication I know of, allways resulting in complaints
that the webapp didn't work for some people (that is the people
that turned of cookies) after it was put in production.
Eelco
Gili
Eelco Hillenius wrote:
Nope, we do need a session for everything except a trivial page
(and from the framework to figure out whether the page is
'trivial' that would involve some major hacking). EVERYTHING
that can trigger a 'postback', be it forms, links or whatever,
needs that page to be in the session.
It might be a feature request for our next version (1.2 that
is) when we tackle the whole stateless page thing (if we ever
tackle that succesfully, as currently the disadvantages seem to
be greater than the very few advantages it would get you... but
that's another discussion for some other time). But for 1.0.1/
1.1, we can't change it.
Eelco
Gili wrote:
First, I like the new setPageAlias() functionality :)
I still don't understand however why one needs to store the
Page component ID on the session (at least for bookmarkable
pages the first time they are hit). Also, Eelco previously
mentioned that jsessionid is only showing up because we're
creating a session. My point is, we *shouldn't* be creating a
session for bookmarkable pages unless for example the page
contains a form, and someone submits it. We should be creating
session on-demand, not right away. Maybe once I understand
more about why we need path=X, this will make more sense.
Thanks,
Gili
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
from IBM. Find simple to follow Roadmaps, straightforward
articles,
informative Webcasts and more! Get everything you need to get
up to
speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
