Ah.. probably RequestCycle.onRuntimeException is the key.
**
Martin
2010/1/24 Martin Makundi :
> 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/1
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 :
> use a cookie. every time a user enters a "silo" set it in a silo
> cookie. when the session
> 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
--
I guess the servlet container handles jsessionid transparently.
**
Martin
2009/12/28 Wilhelmsen Tor Iver :
>> 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 Ive
> 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: users-unsubscr...@wic
jsessionid works
**
Martin
2009/12/28 Igor Vaynberg :
> lol, i guess you cant use most major sites out there eh?
>
> -igor
>
> On Mon, Dec 28, 2009 at 11:01 AM, Martin Makundi
> wrote:
>> Yes, many companies' security policies allow javascript but not cookies.
>>
>> **
>> Martin
>>
>> 2009/12/28
lol, i guess you cant use most major sites out there eh?
-igor
On Mon, Dec 28, 2009 at 11:01 AM, Martin Makundi
wrote:
> Yes, many companies' security policies allow javascript but not cookies.
>
> **
> Martin
>
> 2009/12/28 Igor Vaynberg :
>> so you think there are people out there that will us
Yes, many companies' security policies allow javascript but not cookies.
**
Martin
2009/12/28 Igor Vaynberg :
> 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
> wrote:
>> I agree. But what about
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
wrote:
> I agree. But what about cookie-less users. Just forget about them?
>
> 2009/12/28 Igor Vaynberg :
>> we have one, its called cookies
>>
>> -igor
>>
Haha, but jsessionid is probably destroyed when session dies..
**
Martin
2009/12/28 Martin Makundi :
> Can we get access to the jsessionid? Maybe we could use that to track
> cookieless users.
>
> **
> Martin
>
> 2009/12/28 Martin Makundi :
>> I agree. But what about cookie-less users. Just forge
Can we get access to the jsessionid? Maybe we could use that to track
cookieless users.
**
Martin
2009/12/28 Martin Makundi :
> I agree. But what about cookie-less users. Just forget about them?
>
> 2009/12/28 Igor Vaynberg :
>> we have one, its called cookies
>>
>> -igor
>>
>
--
I agree. But what about cookie-less users. Just forget about them?
2009/12/28 Igor Vaynberg :
> we have one, its called cookies
>
> -igor
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-
we have one, its called cookies
-igor
On Mon, Dec 28, 2009 at 10:22 AM, Martin Makundi
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 sessions.
>
> **
> Martin
>
> 20
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 :
> - sethome(string) needs to be called at a particular point in the
> request cycle,
- 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
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, Mar
> 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
>
On Mon, Dec 28, 2009 at 9:41 AM, Martin Makundi
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 :
>> use a cookie. every time a user enters a "silo" set it in
rfe? for what? cookies have nothing to do with wicket.
-igor
On Mon, Dec 28, 2009 at 9:41 AM, Martin Makundi
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?
>
> **
> Martin
>
> 2009/12/28 Igor Vaynbe
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 :
> use a cookie. every time a user enters a "silo" set it in a silo
> cookie. when the session expires, the cookie will still b
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
wrote:
> 2009/12/28 Ernesto Reinaldo Barreiro :
>> but I'm no core developer... So, why not wait to see what
>>
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. Diff
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
> Hi,
>
> 2009-12-28 15:57 keltezéssel, Jim Pinkham írta:
> > OK, but could you deploy mul
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 :
> Hmm, that's not correct. Different frontend apps should use the same EJB's.
> In that case, It's not so ugly anym
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. S
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 wor
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
h
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 :
> I think this suggestion is worth condsidering more carefully:
>
>>> Can you just achieve what you wan't making siloA, siloB, siloC been
>>> different "W
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 t
2009/12/28 Ernesto Reinaldo Barreiro :
> 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 <
> martin.maku...@koodaripalvelut.com
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 th
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 errorpage/ho
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/error
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 :
>>
>>
>> But where could we bind the silo information into urls globally?
>>
>>
> Mountin
>
>
> 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
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 :
> Neither do I... but
> maybe AbstractRequestCycleProcessor.respond(RuntimeException e, RequestCycle
> requestCycle) i
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
> 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?
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
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
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 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 thi
> 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 follow
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 l
> 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,
>
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
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 wonde
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 no
48 matches
Mail list logo
