No it doesn't yet generate stateless urls yet.
See (for starters)

public final CharSequence urlFor(final Component component,
           final RequestListenerInterface listener)

and

   public final CharSequence urlFor(final Component component,
           final IBehavior behaviour, final RequestListenerInterface
listener)


Long user request should really be avoided. Because every default
installation of
one of the webcontainers will break then.
i think resin/tomcat/jett? all default to a thread pool of 100?
So if you have a more then 100 sessions then more and more uses long running
things
they will eventually lock the rest out. Also make sure that the database
connection pool
is at least as big as the http thread pool of the container.

Also keeping a long running request going will result in browser timeouts
and so on.
(if you don't sent anything to the browser and wicket doesn't do that)

johan



On 2/14/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:

> But what kind of ajax behaviors do you have in mind?
> Things like FormComponentUpdatingBehaviour is ofcourse useless in a
> stateless fasion.
> AutoCompleteBehavior?

Well, it wouldn't work for component replacement obviously, but e.g.
rendering a component that's already in the hierarchy with fresh data
(or maybe even based on an extra provided parameter) should work fine.
I'm also thinking about that long running request issue we discussed
on the user list[1]

Also, other than immediately thinking about what it could be used for,
I just think there is no good reason why this wouldn't be possible, so
supporting this (if we don't already) is just a matter of consistency
with the rest of the framework imho.

Eelco

[1] http://www.nabble.com/multiple-rendering-at-same-time-tf3223945.html

Reply via email to