Hi!
What is the best way to change the PageExpiredErrorPage or
InternalErrorPage depending on a silo?
Application.getApplicationSettings() is shared among all silos.
**
Martin
2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com:
use a cookie. every time a user enters a silo set it in a silo
Ah.. probably RequestCycle.onRuntimeException is the key.
**
Martin
2010/1/24 Martin Makundi martin.maku...@koodaripalvelut.com:
Hi!
What is the best way to change the PageExpiredErrorPage or
InternalErrorPage depending on a silo?
Application.getApplicationSettings() is shared among all
I guess the servlet container handles jsessionid transparently.
Yes, coming in (either cookie or in the URI) and setting the cookie; but it
does not normally add it to links in the output from your webapp, that is the
framework or developer's responsibility.
- Tor Iver
Hi,
When a client has a page in his browser that he does not touch for a while
and the session expired. after that if he hits an ajax link for example - an
exception occurs in the wicket level due to the session expired state.
How can I gracefully handle such a situation assuming that there is
Hi!
Yes, I hate this situation too. Our application has various different
silos and whenever the user session expires, he loses his silo and is
redirected to a generic homepage and an inexperienced user will never
know how to get back to where he was. Some information should be in
the url. I
Can you just simply track user activity and store it into a persistence
layer that do not expires with session and then once session expires
redirect them to that last page (after they have logged in?)?. You could add
a check that sees if the user had some pending actions (that are cleaned
out if
Can you just simply track user activity and store it into a persistence
layer that do not expires with session and then once session expires
redirect them to that last page (after they have logged in?)?.
Maybe wicket could do this automatically using Servlet Context?
**
Martin
Best,
How exactly do you see this implemented? There will be plenty of details to
be taken care for. e.g. For how long should this information stay on
that Servlet Context? If your application has many users what information
should go there?...
Wouldn't it be simpler to have a component instantiation
How exactly do you see this implemented? There will be plenty of details to
be taken care for. e.g. For how long should this information stay on
that Servlet Context? If your application has many users what information
should go there?...
Somehow configure that
- my application has following
Hi Martin,
Can you just achieve what you wan't making siloA, siloB, siloC been
different Wicket applications?
I still see the problem of how this state will be stored on Servlet Context
and how do you manage/recover/delete it for a certain user... How is this
generic user defined? Isn't this a
Hi,
i have the same problems for our heavy ajax wicket site. I use
wicket-ajax so the stateless flag can not be used. If the session
expires i make some assumptions:
* all user generated content is thrown away. (e.g. shopingbasket)
* the pagecomponents the user is on is in initial hierarchie,
Hi!
Can you just achieve what you wan't making siloA, siloB, siloC been
different Wicket applications?
No, that is not the proper solution. They are the same application.
I still see the problem of how this state will be stored on Servlet Context
and how do you manage/recover/delete it for
So essentially what you want to use is the (failing) request URL to redirect
users to different pages? Some kind of strategy for redirecting to Expired
Pages and to Home Pages based on the URL instead of fixed pages? Isn't
this possible by rolling out your own WebRequestCycleProcessor?
Ernesto
So essentially what you want to use is the (failing) request URL to redirect
users to different pages? Some kind of strategy for redirecting to Expired
Pages and to Home Pages based on the URL instead of fixed pages? Isn't
this possible by rolling out your own WebRequestCycleProcessor?
I do
Neither do I... but
maybe AbstractRequestCycleProcessor.respond(RuntimeException e, RequestCycle
requestCycle) is the method to override?
Best,
Ernesto
On Mon, Dec 28, 2009 at 12:32 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
So essentially what you want to use is the
That's where we have our workaround, currenlty. And it is ugly.
But where could we bind the silo information into urls globally?
**
Martin
2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com:
Neither do I... but
maybe AbstractRequestCycleProcessor.respond(RuntimeException e, RequestCycle
But where could we bind the silo information into urls globally?
Mounting pages? Or better having some kind of configuration class that you
use to mount the pages and do the ugly URL plumbing on that method?
Best,
Ernesto
It should be automatic and global, like a url encoding scheme, and it
should come with an interpreter that will process the
homepage/errorpage when necessary.
**
Martin
2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com:
But where could we bind the silo information into urls globally?
Create a RFE? Maybe on 1.5 it is already possible?
Ernesto
On Mon, Dec 28, 2009 at 1:16 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
It should be automatic and global, like a url encoding scheme, and it
should come with an interpreter that will process the
homepage/errorpage
How would you formulate such RFE?
Wicket needs an autonomus but parametrizable global behavior, that is
transparent to all url encoding schemes, that can be used to identify
users's silo in the application. When session is invalidated or other
errors occur, each silo can have its own
Maybe if you replace users's silo with user location and then say
Example, if location=silo... things will be a little less bound to your
use case... Otherwise your description of what you want to achieve looks
fine fine to me... but I'm no core developer... So, why not wait to see what
do they
2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com:
but I'm no core developer... So, why not wait to see what
do they comment on this issue?
Maybe they just want us to weather this out on ourselves ... ;)
**
Martin
On Mon, Dec 28, 2009 at 1:44 PM, Martin Makundi
I think this suggestion is worth condsidering more carefully:
Can you just achieve what you wan't making siloA, siloB, siloC been
different Wicket applications?
No, that is not the proper solution. They are the same application.
OK, but could you deploy multiple copies of the same app to
Might work, but I do not know if it has any consequences such as will
the user have a single wicketsession?
**
Martin
2009/12/28 Jim Pinkham pinkh...@gmail.com:
I think this suggestion is worth condsidering more carefully:
Can you just achieve what you wan't making siloA, siloB, siloC been
Actually, I think Martin has a solution but he doesn't like it: because it
is not a clean solution. What he is asking for, if I didn't get it wrong at
the end, is been able to have more than one HomePage, ErrorPage, and so on
based on incoming URLs. But this included as a framework feature... not
I guess wicketsessions will be different. I know I proposed to do that but
not sure is the best solution. I your case I would surelly opt for the
solution you have in place right now.
Ernesto
On Mon, Dec 28, 2009 at 4:09 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Might work,
Hi,
2009-12-28 15:57 keltezéssel, Jim Pinkham írta:
OK, but could you deploy multiple copies of the same app to different root
contexts - that would give you the info you want in each URL and thus be
able to do different home/error pages with some config along with each copy
of the app.
I am more worried about the session duplication. I want to get
multi-homed single application look and feel. Single wicketsession
per user.
**
Martin
2009/12/28 Pieter Degraeuwe pieter.degrae...@systemworks.be:
Hmm, that's not correct. Different frontend apps should use the same EJB's.
In that
Hmm, that's not correct. Different frontend apps should use the same EJB's.
In that case, It's not so ugly anymore in my opinion. (I don't want to
advocate the use of EJB's though..)
2009/12/28 Major Péter majorpe...@sch.bme.hu
Hi,
2009-12-28 15:57 keltezéssel, Jim Pinkham írta:
OK, but
Right, right, my bad. But then you should create three different
webmodules for a single application, that's why wicket would be loaded 3
times only for this separation.. It's just unneccesary resource usage IMHO.
2009-12-28 16:30 keltezéssel, Pieter Degraeuwe írta:
Hmm, that's not correct.
use a cookie. every time a user enters a silo set it in a silo
cookie. when the session expires, the cookie will still be there.
-igor
On Mon, Dec 28, 2009 at 5:04 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com:
but I'm no
Ok, something could be built on that. Not as robust as an url but
works. Requires a nice design in the request processing. Still RFE?
**
Martin
2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com:
use a cookie. every time a user enters a silo set it in a silo
cookie. when the session expires, the
rfe? for what? cookies have nothing to do with wicket.
-igor
On Mon, Dec 28, 2009 at 9:41 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Ok, something could be built on that. Not as robust as an url but
works. Requires a nice design in the request processing. Still RFE?
**
On Mon, Dec 28, 2009 at 9:41 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Not as robust as an url but works.
you can build your own url conding strategy that postprocesses urls in
any way you want.
-igor
**
Martin
2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com:
use a
rfe? for what? cookies have nothing to do with wicket.
Not as robust as an url but works.
you can build your own url conding strategy that postprocesses urls in
any way you want.
RFE for built-in support of multi-homing in wicket, out-of-the-box.
**
Martin
-igor
that does what?
so we provide sethome(string) and gethome(string) which are analogues
to setcookie(cookie) and getcookies() which does not lock you into a
single way of doing multihoming.
there is some code you have to write to build an application
-igor
On Mon, Dec 28, 2009 at 9:56 AM,
- sethome(string) needs to be called at a particular point in the
request cycle, could be built-in or not?
- gethome() with homepage handling needs to be done in a particular
manner in the request cycle, could be built-in or not?
- alternative url encoding scheme, could be built-in or not?
does
yah.. styles won't work either.. they're in the session so when
invalidation occurs...the data is lost. So Wicket needs some built-in
method to pass tokens between sessions.
**
Martin
2009/12/28 Martin Makundi martin.maku...@koodaripalvelut.com:
- sethome(string) needs to be called at a
we have one, its called cookies
-igor
On Mon, Dec 28, 2009 at 10:22 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
yah.. styles won't work either.. they're in the session so when
invalidation occurs...the data is lost. So Wicket needs some built-in
method to pass tokens between
I agree. But what about cookie-less users. Just forget about them?
2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com:
we have one, its called cookies
-igor
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For
Can we get access to the jsessionid? Maybe we could use that to track
cookieless users.
**
Martin
2009/12/28 Martin Makundi martin.maku...@koodaripalvelut.com:
I agree. But what about cookie-less users. Just forget about them?
2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com:
we have one,
Haha, but jsessionid is probably destroyed when session dies..
**
Martin
2009/12/28 Martin Makundi martin.maku...@koodaripalvelut.com:
Can we get access to the jsessionid? Maybe we could use that to track
cookieless users.
**
Martin
2009/12/28 Martin Makundi
so you think there are people out there that will use ajax but not
allow cookies...
-igor
On Mon, Dec 28, 2009 at 10:35 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
I agree. But what about cookie-less users. Just forget about them?
2009/12/28 Igor Vaynberg
Yes, many companies' security policies allow javascript but not cookies.
**
Martin
2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com:
so you think there are people out there that will use ajax but not
allow cookies...
-igor
On Mon, Dec 28, 2009 at 10:35 AM, Martin Makundi
lol, i guess you cant use most major sites out there eh?
-igor
On Mon, Dec 28, 2009 at 11:01 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Yes, many companies' security policies allow javascript but not cookies.
**
Martin
2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com:
so
jsessionid works
**
Martin
2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com:
lol, i guess you cant use most major sites out there eh?
-igor
On Mon, Dec 28, 2009 at 11:01 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Yes, many companies' security policies allow javascript
jsessionid works
... but leads to lots of boilerplate where you need to rewrite all URLs
targeted at your app's code. I guess Wicket can do that for you, but still...
- Tor Iver
-
To unsubscribe, e-mail:
I guess the servlet container handles jsessionid transparently.
**
Martin
2009/12/28 Wilhelmsen Tor Iver toriv...@arrive.no:
jsessionid works
... but leads to lots of boilerplate where you need to rewrite all URLs
targeted at your app's code. I guess Wicket can do that for you, but still...
48 matches
Mail list logo
