It seems like we're talking about different things...
I don't *care* if the page of the example expires... that's fine by me.
It's the source code windows that keep expiring and really don't need to!
There bookmarkable page links could be used instead of ajax links IMHO.
I don't care if the u
And it wouldn't guide our users into the right direction either: only
apply stateless pages where really necessary.
Martijn
On 3/18/08, Matej Knopp <[EMAIL PROTECTED]> wrote:
> Not everything in wicket can be bookmarkable and not everything can be
> statelesss. None of the ajax examples could wo
Not everything in wicket can be bookmarkable and not everything can be
statelesss. None of the ajax examples could work on stateless pages
for example.
-Matej
On Tue, Mar 18, 2008 at 10:52 AM, Sebastiaan van Erk
<[EMAIL PROTECTED]> wrote:
> Matej Knopp wrote:
> > Why can't we just put a 5 minute
Matej Knopp wrote:
Why can't we just put a 5 minute timer on each page which would casuse
active sessions never expire?
That's fine by me, :-) though I tend to leave windows open in my browser
for hours or days even, so that would be less server friendly than
bookmarkable links...
Regards,
+1
On 3/17/08, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> Everybody is invited to vote! Please use
>
> [ ] +1, Wicket 1.4 is 1.3 + generics, drop support for 1.3
> [ ] -1, I need a supported version running on Java 1.4
>
> Let your voices be heard!
>
> Martijn
>
> --
> Buy Wicket in Actio
I try to use Wicket 1.3.2 together with wicketstuff dojo (both 1.3.0
beta and 1.3.0 latest) Everything works fine if I deploy my applicatioin
in development mode. Some lines like
DEBUG: Initialized drop contianer for dropContainer01, dropIds:
*,
DEBUG: Callback url base:
?wicke
Why can't we just put a 5 minute timer on each page which would casuse
active sessions never expire?
-Matej
On Tue, Mar 18, 2008 at 8:52 AM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
> Martijn Dashorst wrote:
> > Making the source code viewing pages stateless won't help: next
> > question:
Hi,
I'm also using the ModalWindow, with some very small enhancements.
Regards,
Cristi Manole
On Mon, Mar 17, 2008 at 10:39 PM, jeredm <[EMAIL PROTECTED]>
wrote:
>
> I am using the ModalWindow.
>
> mnwicket wrote:
> >
> > Just out of curiosity, are most people using the ModalWindow provided by
Hi,
I think in that case (deserializing with a changed class) an
InvalidClassException is thrown. See
http://java.sun.com/j2se/1.5.0/docs/api/java/io/ObjectInputStream.html#readObject()and
http://java.sun.com/j2se/1.5.0/docs/api/java/io/InvalidClassException.html
According to the docs the Stream
Its not wicket that chooses for 1.4 this long. Its for example IBM
(webspere) that takes a long long time to move to jdk versions. For
example i dont think there is a webspere version in sight yet for 1.6
and how long do we have that now? (except mac thats also a small
problem in that area)
On 3/1
Martijn Dashorst wrote:
Making the source code viewing pages stateless won't help: next
question: but when I close the source code, my page doesn't work
anymore.
The source code opens up in separate window. If the URL's there were
bookmarkable pages they would always work. Since the source is
I think 30 minutes is too long. The server is already maxed out on
capacity, so that needs to be fixed before we start tampering with
session expiries.
Just download the examples throw it in a web container, or check out
Wicket from svn and run mvn jetty:run. Then you can look at the code
as long
Making the source code viewing pages stateless won't help: next
question: but when I close the source code, my page doesn't work
anymore.
The online examples are not fit for a long studying session: they are
for demoing, or visitors. Studying or long running demoes: DOWNLOAD
the thing and run them
Yes, or just even increase the timeout as a temporary fix. :-)
It's like 5 minutes now, which means that if you go to your own code to
implement something like in the example, and then want to view the
source code of the next logical file, it says "page expired". If it was
30 minutes, then for
are you using a class reloading mechanism of any sort? this error
would make sense if wicket saved a page to store, you changed the
class def and wicket tried to deserialize an instance of that changed
class
-igor
On Tue, Mar 18, 2008 at 12:42 AM, lars vonk <[EMAIL PROTECTED]> wrote:
> Have
Have you found out which Page it tries to deserialize? Did you try to
deserialize this exact page using another widget? The exception indicates
the internal object stream format is corrupted. So this would indeed mean it
would also occur if you try to to deserialize it using a "normal" widget.
Here
i think they meant to make only source code viewing pages stateless...
-igor
On Tue, Mar 18, 2008 at 12:26 AM, Martijn Dashorst
<[EMAIL PROTECTED]> wrote:
> -1
>
> You can download and run the examples yourself if you want to do so.
> The examples are just that: examples of normal wicket pages
-1
You can download and run the examples yourself if you want to do so.
The examples are just that: examples of normal wicket pages. Forcing
them stateless gives new users the wrong impressions.
Martijn
On 3/18/08, Ned Collyer <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I enjoy clicking around the
101 - 118 of 118 matches
Mail list logo
