i could provide the bookmarkable hint to the link also if that is something that more would prefer?johanOn 6/22/06, John Patterson <
[EMAIL PROTECTED]> wrote:A link could exist on a Stateless page that creates state. This would be the point where a stateless site moves to being stateful.
For examp
A link could exist on a Stateless page that creates state. This would be the point where a stateless site moves to being stateful.For example, On my stateless home page I could have a link that has an onClick() handler which stores something in the users session (creating it also).On 22 Jun 2006,
yes we could but then a link really doesn't have state.The form has its new state pushed anyway,. And a link not. So then you need to encode something in the url..Because what should the link do? If it is only a next page and no state of the current page is touched you can use bookmarkable links.
We weren't only eating Tapas... I drank a lot of wine. That must have
blurred my memory a bit :)
Cool Johan. So my hunch is that Links can be done in the same fashion?
Though we should draw the line somewhere too.
Eelco
On 6/14/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> WHAT! you have to
Exactly. That's a half baked solution at best. And though unlikely a
real problem, I wouldn't want to have to depend on the user-agent the
client sends. The solution we have got now - stateless pages (and you
can actually use forms on them like you would normally do, except for
the fact that any st
Exactly. That's a half baked solution at best. And though unlikely a
real problem, I wouldn't want to have to depend on the user-agent the
client sends. The solution we have got now - stateless pages (and you
can actually use forms on them like you would normally do, except for
the fact that any st
wicket 1.2.x and earlier create a session on first request so this approach would mean a new session created from every hit from the spider. something to consider.-IgorOn 6/14/06,
Aaron Metzger <[EMAIL PROTECTED]> wrote:
John Patterson wrote:> On 13 Jun 2006, at 19:55, Eelco Hillenius wrote:>>> Or
John Patterson wrote:
> On 13 Jun 2006, at 19:55, Eelco Hillenius wrote:
>
>> Or maybe there will be more trade offs. Depends on how badly people
>> want it, and who will work on it. In 2.0, Johan built in a form that
>> posts back to a bookmarkable page, so you can even build pages with
>> forms
and why the hell did i just spell tappas with two ps? its all your fault johan!-IgorOn 6/14/06, Igor Vaynberg <
[EMAIL PROTECTED]> wrote:well, cmon, eating tappas can make anyone distracted. you should def not discuss anything important while eating tappas!
-IgorOn 6/14/06, Johan Compagner
<[EMAIL
well, cmon, eating tappas can make anyone distracted. you should def not discuss anything important while eating tappas!-IgorOn 6/14/06, Johan Compagner
<[EMAIL PROTECTED]> wrote:
WHAT! you have to listen more eelco :)i told you that i want to have exactly the same behaviour as a normal Form!when
Alexandru Popescu schrieb:
>>> Unfortunately this is not completely accurate information.
>> I was writing about my experience and I wrote it down accurately.
>>
>
> Timo, sorry if you found my comments as offending.
Nah, I didn't.
___
Wicket-user mai
WHAT! you have to listen more eelco :)i told you that i want to have exactly the same behaviour as a normal Form!when we where eating tappas you wanted to go directly the to resulting page. And i said noi want to go first to the form page and go on from that so that the processing is exactly the sa
Perfect. Wicket just keeps getting better and better.
On 13 Jun 2006, at 20:59, Eelco Hillenius wrote:
> Really? I haven't looked at it, but just remember Johan told me
> processing would go via the pageparameters constructor. If it's via
> the onSubmit handler, that's all the nicer.
>
> Eelco
>
you would use the onclick. what happens when a stateless form is submitted is that a new page instance is created instead of looked up from session stored, and then processing continues as usual.-Igor
On 6/13/06, John Patterson <[EMAIL PROTECTED]> wrote:
On 13 Jun 2006, at 19:55, Eelco Hillenius wr
The latter.
Eelco
On 6/13/06, John Patterson <[EMAIL PROTECTED]> wrote:
>
> On 13 Jun 2006, at 19:55, Eelco Hillenius wrote:
>
> > Or maybe there will be more trade offs. Depends on how badly people
> > want it, and who will work on it. In 2.0, Johan built in a form that
> > posts back to a bookm
Really? I haven't looked at it, but just remember Johan told me
processing would go via the pageparameters constructor. If it's via
the onSubmit handler, that's all the nicer.
Eelco
On 6/13/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> you would use the onclick. what happens when a stateless fo
On 13 Jun 2006, at 19:55, Eelco Hillenius wrote:
> Or maybe there will be more trade offs. Depends on how badly people
> want it, and who will work on it. In 2.0, Johan built in a form that
> posts back to a bookmarkable page, so you can even build pages with
> forms that are still stateless.
>
>
Or maybe there will be more trade offs. Depends on how badly people
want it, and who will work on it. In 2.0, Johan built in a form that
posts back to a bookmarkable page, so you can even build pages with
forms that are still stateless.
Eelco
On 6/13/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote
That's not in 2.0 and I don't think it will be. Before you know it we
will be doing premature optimization everywhere. Those stateless
optimizations make sense for some cases, but for the rest, Wicket
should focus on it's strong points: being OO and statefull. If we
would have liked the way Tapestr
Just a quick question about how this will work in 2.0; is it
possible to have a page that has a normal link with an onClick
handler which is not stored in the session?
In this case the link target would need to specify both the
BookmarkablePage and the Listener to call and when the target i
Anyway, there is a solution for it now... deferred session creation
:). It's in 2.0, didn't make 1.2 unfortunately, as it would mean two
API breaks, but it is scheduled for 1.3 whenever that comes out (I
guess that depends on how badly people want it) and you can apply the
patch I sent earlier for
> > Unfortunately this is not completely accurate information.
>
> I was writing about my experience and I wrote it down accurately.
>
Timo, sorry if you found my comments as offending. There was no such intention.
> The session id is stripped from the link in the search result page. At
> least i
> Unfortunately this is not completely accurate information.I was writing about my experience and I wrote it down accurately.
:)-Igor
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Alexandru Popescu schrieb:
> On 6/8/06, Timo Stamm <[EMAIL PROTECTED]> wrote:
>> John Patterson schrieb:
>>> Currently, I am considering either apache url rewriting to remove all
>>> session ids from non-conversational pages or hacking wicket to disable
>>> url encoding for all pages that do not ab
On 6/8/06, Timo Stamm <[EMAIL PROTECTED]> wrote:
> John Patterson schrieb:
> > Currently, I am considering either apache url rewriting to remove all
> > session ids from non-conversational pages or hacking wicket to disable
> > url encoding for all pages that do not absolutely require a session.
>
Brilliant! I'll definitely try out this patch.
On 9 Jun 2006, at 12:21, Eelco Hillenius wrote:
> Sorry, we (comitters) couldn't come to an agreement. Backporting
> deferring the session creation can be done in 1.2 (in fact, it's
> working on my laptop now), but it means two API breaks:
> IBehavi
Yeah, it's in 2.0. We're having the - heated - discussion about
backporting it so that it will be available in 1.2.
Eelco
On 6/8/06, Michael Day <[EMAIL PROTECTED]> wrote:
> I thought that was the point of 2.0--to break the API for a better
> product. =D
>
> Michael Day
>
> On Jun 8, 2006, at 6:
I thought that was the point of 2.0--to break the API for a better
product. =D
Michael Day
On Jun 8, 2006, at 6:17 PM, Eelco Hillenius wrote:
> I'm just about to check in changes that - finally - lets Wicket defer
> session creation until it is actually needed. The change is done for
> 2.0/ tr
On 8 Jun 2006, at 18:17, Eelco Hillenius wrote:
> I'm just about to check in changes that - finally - lets Wicket defer
> session creation until it is actually needed. The change is done for
> 2.0/ trunk, but we're currently voting on whether it is worth an API
> break. IBehavior has one addition
I'm just about to check in changes that - finally - lets Wicket defer
session creation until it is actually needed. The change is done for
2.0/ trunk, but we're currently voting on whether it is worth an API
break. IBehavior has one additional method. If you haven't been
reading the API docs not to
On 8 Jun 2006, at 09:52, Johan Compagner wrote:
> you could return your own versions of ISessionStore
> that pretty much doesn't do anything..
> Dont know if that always works..
Thanks, I think I will try this approach and see what happens! I
will be building a new site in the next month or t
you could return your own versions of ISessionStorethat pretty much doesn't do anything..Dont know if that always works..johanOn 6/8/06,
John Patterson <[EMAIL PROTECTED]> wrote:
On 8 Jun 2006, at 05:10, Johan Compagner wrote:>>> Or make your own buffered response object> (WebApplication.newWebRes
On 8 Jun 2006, at 01:43, Timo Stamm wrote:
> Are you sure this issue is that important? In my experience, Google
> does
> index pages with a session id parameter in the URL. The session id is
> stripped in the search result URL, so I don't see any problems.
See the quotes in my previous post fr
On 8 Jun 2006, at 05:10, Johan Compagner wrote:
>
>
> Or make your own buffered response object
> (WebApplication.newWebResponse())
> and override in the response object the
> public CharSequence encodeURL(CharSequence url)
>
> but then you have to analize the url and know which one you want to
All my pages which should be indexed by bots require no "conversation" state to be storedand would all be bookmarkable. Would it be possible to have common pages (or page components) stored in the application scope instead? They could then have their rendered content cached too.
i dont think so,
John Patterson schrieb:
> Currently, I am considering either apache url rewriting to remove all
> session ids from non-conversational pages or hacking wicket to disable
> url encoding for all pages that do not absolutely require a session.
Are you sure this issue is that important? In my experie
If you say that you don't want sessionids in all (or most) bookmarkable linksmake your own: WebRequestCodingStrategyoverride the method: protected CharSequence encode(RequestCycle requestCycle,
IBookmarkablePageRequestTarget requestTarget)and copy the complete code of that method. bu
On 7 Jun 2006, at 22:15, Igor Vaynberg wrote:Because wicket components are stateful that state needs to live somewhere. So far it can only live in session for wicket 1.2 or on client in wicket 2.0. Thanks for the update. I look forward to using this new facility.Maybe in 2.0 what we do is check fo
Because wicket components are stateful that state needs to live somewhere. So far it can only live in session for wicket 1.2 or on client in wicket 2.0. Maybe in 2.0 what we do is check for the bot and then switch from
server to client state. But even then the problem is that urls are not
stable, t
On 7 Jun 2006, at 17:32, Eelco Hillenius wrote:Well, people can still argue whether it is in Google's way or not. Seemy comment at http://technically.us/n8/articles/2006/05/07/baking-for-google#commentsI have read quotes on Matt Cutts blog that session ids should be avoided. Also quotes from Googl
Well, people can still argue whether it is in Google's way or not. See
my comment at
http://technically.us/n8/articles/2006/05/07/baking-for-google#comments
A session will still be created, even if you only have bookmarkable
pages. We tried to get rid of it, but it prooved undoable at this
time.
41 matches
Mail list logo
