Re: Testing AjaxSubmitLink#onSubmit() with WicketTester @L
alecswan1 wrote: > > So, how do I test AjaxSubmitLink#onSubmit(AjaxRequestTarget target, Form > form) method? > You may try using http://wicketpagetest.sourceforge.net/ to test it instead. It supports real AJAX. - -- Kent Tong Better way to unit test Wicket pages (http://wicketpagetest.sourceforge.net) Books on CXF, Axis2, Wicket, JSF (http://http://agileskills2.org) -- View this message in context: http://old.nabble.com/Re%3A-Testing-AjaxSubmitLink-onSubmit%28%29-with-WicketTester-%40L-tp26947384p26951953.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 Iver > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: strange classcastexception
Just debug it to find the reason.
**
Martin
2009/12/29 Sam Barrow :
> tried that, didn't work.
> any other ideas?
>
> On Mon, 2009-12-28 at 16:11 +0100, Per Newgro wrote:
>> Hi Sam,
>>
>> did you try
>>
>> birthDateField = new TextField("birthDate", new Model(),
>> Date.class);
>>
>> Maybe it helps.
>>
>> Cheers
>> Per
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Quick question - Bad to serialize a class ref erence?
I doubt it's a problem, but if you're worried about the class reference you can
introduce a middle man that will handle the serialization as a string:
class ClassHolder implements Serializable {
private Class clazz;
// constructor, setter, and getter omitted...
private void readObject(ObjectInputStream ois) {
clazz = Class.forName(ois.readUTF());
}
private void writeObject(ObjectOutputStream oos) {
oos.writeUTF(clazz.getName());
}
}
Craig
_
From: Anthony DePalma [mailto:fatef...@gmail.com]
To: users@wicket.apache.org
Sent: Mon, 28 Dec 2009 15:41:00 -0500
Subject: Quick question - Bad to serialize a class reference?
I am making a modal window link component that will fallback to a
standard redirect if javascript is disabled. Traditionally I have been
overriding a method called onFallback() and forcing users to manually
setRedirect(true), setResponsePage(blah), but I would prefer it if I
could just pass the class reference in the constructor and handle that
logic myself in the onclick.
That means serializing the class reference across to the onclick. Are
there performance implications at all? My gut reaction is no because I
see a lot of transient objects in the Class object, but I wanted to
confirm.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: MultiPartServletRequest Exception
create a quickstart and attach it to a jira issue. -igor On Mon, Dec 28, 2009 at 3:35 PM, Corbin, James wrote: > Upgrading to 1.4.5 does not fix the problem. Something else is amiss here. > > I've even tried explicitly setting the form to multi-part (e.g., > myForm.setMultiPart(true)) > > More investigation is needed. > > j.D. > > -Original Message- > From: Corbin, James [mailto:jcor...@iqnavigator.com] > Sent: Monday, December 28, 2009 4:11 PM > To: users@wicket.apache.org > Subject: RE: MultiPartServletRequest Exception > > Yep, I read about that in the jira issue wicket-2621. > > The parent form has a fileupload field and I verified the generated HTML > defines the encoding on that form as multipart. > > The dialog that is popped up from that panel, also defines a form, in which > wicket converts to a div (can't have nested forms in HTML). The dialog popup > has does have an ajax button that submits the form, but at this point, the > form that is submitted is no longer multipart which is the cause of the error. > > It sounds like it should be fixed in 1.4.5 (jira issue wicket-2621) which I > am trying again now with clean builds. > > J.D. > > -Original Message- > From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] > Sent: Monday, December 28, 2009 4:00 PM > To: users@wicket.apache.org > Subject: Re: MultiPartServletRequest Exception > > in certain cases wicket will set multipart property on your forms for > you. eg if it detects a file upload field in the form. > > -igor > > On Mon, Dec 28, 2009 at 2:28 PM, Corbin, James > wrote: >> A little more information on this issue, >> >> I observed this error after a dialog is popped up that contains a form >> that isn't multipart. The page that launches this dialog also has a >> form that IS multipart. The thing I don't understand is how the parent >> form has multipart encoding because I never set it. >> >> J.D. >> >> -Original Message- >> From: Corbin, James [mailto:jcor...@iqnavigator.com] >> Sent: Monday, December 28, 2009 3:07 PM >> To: users@wicket.apache.org >> Subject: MultiPartServletRequest Exception >> >> As recent as the 1.4.4 release (dated December 10th, 2009), I started >> getting the following stack trace. >> >> >> >> This happens when submitting the form. >> >> >> >> Note: This doesn't seem to occur with the same code base running against >> Wicket 1.4.1. >> >> >> >> Did something break in 1.4.4 relating to this? >> >> >> >> java.lang.IllegalStateException: ServletRequest does not contain >> multipart content >> at >> org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.>>(MultipartServletWebRequest.java:113) >> at >> org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.>>(MultipartServletWebRequest.java:83) >> at >> org.apache.wicket.protocol.http.servlet.ServletWebRequest.newMultipartWe >> bRequest(ServletWebRequest.java:500) >> at >> org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1651) >> at >> org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:850) >> at >> org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmi >> tBehavior.java:135) >> at >> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java: >> 177) >> at >> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDef >> aultAjaxBehavior.java:299) >> at >> org.apache.wicket.request.target.component.listener.BehaviorRequestTarge >> t.processEvents(BehaviorRequestTarget.java:119) >> at >> org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(Ab >> stractRequestCycleProcessor.java:92) >> at >> org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java >> :1250) >> at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) >> at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428) >> >> ... >> >> J.D. Corbin | IQNavigator, Inc. | Technology 6465 Greenwood Village >> Blvd, Suite 800, Centennial, CO 80111 | Office 303.563.1503 | Mobile >> 303.912.0958 | www.iqnavigator.com | jcor...@iqnavigator.com >> >> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail:
RE: MultiPartServletRequest Exception
Upgrading to 1.4.5 does not fix the problem. Something else is amiss here. I've even tried explicitly setting the form to multi-part (e.g., myForm.setMultiPart(true)) More investigation is needed. j.D. -Original Message- From: Corbin, James [mailto:jcor...@iqnavigator.com] Sent: Monday, December 28, 2009 4:11 PM To: users@wicket.apache.org Subject: RE: MultiPartServletRequest Exception Yep, I read about that in the jira issue wicket-2621. The parent form has a fileupload field and I verified the generated HTML defines the encoding on that form as multipart. The dialog that is popped up from that panel, also defines a form, in which wicket converts to a div (can't have nested forms in HTML). The dialog popup has does have an ajax button that submits the form, but at this point, the form that is submitted is no longer multipart which is the cause of the error. It sounds like it should be fixed in 1.4.5 (jira issue wicket-2621) which I am trying again now with clean builds. J.D. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Monday, December 28, 2009 4:00 PM To: users@wicket.apache.org Subject: Re: MultiPartServletRequest Exception in certain cases wicket will set multipart property on your forms for you. eg if it detects a file upload field in the form. -igor On Mon, Dec 28, 2009 at 2:28 PM, Corbin, James wrote: > A little more information on this issue, > > I observed this error after a dialog is popped up that contains a form > that isn't multipart. The page that launches this dialog also has a > form that IS multipart. The thing I don't understand is how the parent > form has multipart encoding because I never set it. > > J.D. > > -Original Message- > From: Corbin, James [mailto:jcor...@iqnavigator.com] > Sent: Monday, December 28, 2009 3:07 PM > To: users@wicket.apache.org > Subject: MultiPartServletRequest Exception > > As recent as the 1.4.4 release (dated December 10th, 2009), I started > getting the following stack trace. > > > > This happens when submitting the form. > > > > Note: This doesn't seem to occur with the same code base running against > Wicket 1.4.1. > > > > Did something break in 1.4.4 relating to this? > > > > java.lang.IllegalStateException: ServletRequest does not contain > multipart content > at > org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.>(MultipartServletWebRequest.java:113) > at > org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.>(MultipartServletWebRequest.java:83) > at > org.apache.wicket.protocol.http.servlet.ServletWebRequest.newMultipartWe > bRequest(ServletWebRequest.java:500) > at > org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1651) > at > org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:850) > at > org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmi > tBehavior.java:135) > at > org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java: > 177) > at > org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDef > aultAjaxBehavior.java:299) > at > org.apache.wicket.request.target.component.listener.BehaviorRequestTarge > t.processEvents(BehaviorRequestTarget.java:119) > at > org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(Ab > stractRequestCycleProcessor.java:92) > at > org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java > :1250) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428) > > ... > > J.D. Corbin | IQNavigator, Inc. | Technology 6465 Greenwood Village > Blvd, Suite 800, Centennial, CO 80111 | Office 303.563.1503 | Mobile > 303.912.0958 | www.iqnavigator.com | jcor...@iqnavigator.com > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: open window no modal popup from javascript
I developed a new class PopupSettings because I can't extend it,
MyPopupSettings is same as PopupSetting but the method public String
getPopupJavaScript() { . } return a "window.open(' url ')".
This works.
De: Juan E Kipes
Para: users@wicket.apache.org
Enviado: lunes, 28 de diciembre, 2009 19:07:38
Asunto: open window no modal popup from javascript
hi, I'm using datagrid of inmethod,I want open a new window popup no modal,
then override this method
public class MyDataGrid extends DataGrid {
.
@Override
protected void onRowClicked(AjaxRequestTarget target, IModel
rowModel) {
Myentity myEntity= (MyEntity)rowModel.getObject();
PageParameters param = new PageParameters();
param.put("id", myEntity.getId() );
String unULR =
RequestCycle.get().urlFor(MyNewWindowPopup.class, param).toString();
String name_pagemap = "r"+ myEntity;
PopupSettings setting = new
PopupSetting(Page.forName(name_pagemap));
settings.setHeight(500);
settings.setWidth(700);
settings.setTarget(unULR);
target.appendJavascript(settings.getPopupJavaScript());
}
}
my window doesn't open, how to open it?
Yahoo! Cocina
Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/
Yahoo! Cocina
Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/
RE: MultiPartServletRequest Exception
Yep, I read about that in the jira issue wicket-2621. The parent form has a fileupload field and I verified the generated HTML defines the encoding on that form as multipart. The dialog that is popped up from that panel, also defines a form, in which wicket converts to a div (can't have nested forms in HTML). The dialog popup has does have an ajax button that submits the form, but at this point, the form that is submitted is no longer multipart which is the cause of the error. It sounds like it should be fixed in 1.4.5 (jira issue wicket-2621) which I am trying again now with clean builds. J.D. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Monday, December 28, 2009 4:00 PM To: users@wicket.apache.org Subject: Re: MultiPartServletRequest Exception in certain cases wicket will set multipart property on your forms for you. eg if it detects a file upload field in the form. -igor On Mon, Dec 28, 2009 at 2:28 PM, Corbin, James wrote: > A little more information on this issue, > > I observed this error after a dialog is popped up that contains a form > that isn't multipart. The page that launches this dialog also has a > form that IS multipart. The thing I don't understand is how the parent > form has multipart encoding because I never set it. > > J.D. > > -Original Message- > From: Corbin, James [mailto:jcor...@iqnavigator.com] > Sent: Monday, December 28, 2009 3:07 PM > To: users@wicket.apache.org > Subject: MultiPartServletRequest Exception > > As recent as the 1.4.4 release (dated December 10th, 2009), I started > getting the following stack trace. > > > > This happens when submitting the form. > > > > Note: This doesn't seem to occur with the same code base running against > Wicket 1.4.1. > > > > Did something break in 1.4.4 relating to this? > > > > java.lang.IllegalStateException: ServletRequest does not contain > multipart content > at > org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.>(MultipartServletWebRequest.java:113) > at > org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.>(MultipartServletWebRequest.java:83) > at > org.apache.wicket.protocol.http.servlet.ServletWebRequest.newMultipartWe > bRequest(ServletWebRequest.java:500) > at > org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1651) > at > org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:850) > at > org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmi > tBehavior.java:135) > at > org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java: > 177) > at > org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDef > aultAjaxBehavior.java:299) > at > org.apache.wicket.request.target.component.listener.BehaviorRequestTarge > t.processEvents(BehaviorRequestTarget.java:119) > at > org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(Ab > stractRequestCycleProcessor.java:92) > at > org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java > :1250) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428) > > ... > > J.D. Corbin | IQNavigator, Inc. | Technology 6465 Greenwood Village > Blvd, Suite 800, Centennial, CO 80111 | Office 303.563.1503 | Mobile > 303.912.0958 | www.iqnavigator.com | jcor...@iqnavigator.com > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: MultiPartServletRequest Exception
in certain cases wicket will set multipart property on your forms for you. eg if it detects a file upload field in the form. -igor On Mon, Dec 28, 2009 at 2:28 PM, Corbin, James wrote: > A little more information on this issue, > > I observed this error after a dialog is popped up that contains a form > that isn't multipart. The page that launches this dialog also has a > form that IS multipart. The thing I don't understand is how the parent > form has multipart encoding because I never set it. > > J.D. > > -Original Message- > From: Corbin, James [mailto:jcor...@iqnavigator.com] > Sent: Monday, December 28, 2009 3:07 PM > To: users@wicket.apache.org > Subject: MultiPartServletRequest Exception > > As recent as the 1.4.4 release (dated December 10th, 2009), I started > getting the following stack trace. > > > > This happens when submitting the form. > > > > Note: This doesn't seem to occur with the same code base running against > Wicket 1.4.1. > > > > Did something break in 1.4.4 relating to this? > > > > java.lang.IllegalStateException: ServletRequest does not contain > multipart content > at > org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.>(MultipartServletWebRequest.java:113) > at > org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.>(MultipartServletWebRequest.java:83) > at > org.apache.wicket.protocol.http.servlet.ServletWebRequest.newMultipartWe > bRequest(ServletWebRequest.java:500) > at > org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1651) > at > org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:850) > at > org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmi > tBehavior.java:135) > at > org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java: > 177) > at > org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDef > aultAjaxBehavior.java:299) > at > org.apache.wicket.request.target.component.listener.BehaviorRequestTarge > t.processEvents(BehaviorRequestTarget.java:119) > at > org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(Ab > stractRequestCycleProcessor.java:92) > at > org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java > :1250) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428) > > ... > > J.D. Corbin | IQNavigator, Inc. | Technology 6465 Greenwood Village > Blvd, Suite 800, Centennial, CO 80111 | Office 303.563.1503 | Mobile > 303.912.0958 | www.iqnavigator.com | jcor...@iqnavigator.com > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: strange classcastexception
tried that, didn't work.
any other ideas?
On Mon, 2009-12-28 at 16:11 +0100, Per Newgro wrote:
> Hi Sam,
>
> did you try
>
> birthDateField = new TextField("birthDate", new Model(),
> Date.class);
>
> Maybe it helps.
>
> Cheers
> Per
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
RE: MultiPartServletRequest Exception
A little more information on this issue, I observed this error after a dialog is popped up that contains a form that isn't multipart. The page that launches this dialog also has a form that IS multipart. The thing I don't understand is how the parent form has multipart encoding because I never set it. J.D. -Original Message- From: Corbin, James [mailto:jcor...@iqnavigator.com] Sent: Monday, December 28, 2009 3:07 PM To: users@wicket.apache.org Subject: MultiPartServletRequest Exception As recent as the 1.4.4 release (dated December 10th, 2009), I started getting the following stack trace. This happens when submitting the form. Note: This doesn't seem to occur with the same code base running against Wicket 1.4.1. Did something break in 1.4.4 relating to this? java.lang.IllegalStateException: ServletRequest does not contain multipart content at org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.(MultipartServletWebRequest.java:113) at org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.(MultipartServletWebRequest.java:83) at org.apache.wicket.protocol.http.servlet.ServletWebRequest.newMultipartWe bRequest(ServletWebRequest.java:500) at org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1651) at org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:850) at org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmi tBehavior.java:135) at org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java: 177) at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDef aultAjaxBehavior.java:299) at org.apache.wicket.request.target.component.listener.BehaviorRequestTarge t.processEvents(BehaviorRequestTarget.java:119) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(Ab stractRequestCycleProcessor.java:92) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java :1250) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428) ... J.D. Corbin | IQNavigator, Inc. | Technology 6465 Greenwood Village Blvd, Suite 800, Centennial, CO 80111 | Office 303.563.1503 | Mobile 303.912.0958 | www.iqnavigator.com | jcor...@iqnavigator.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
open window no modal popup from javascript
hi, I'm using datagrid of inmethod,I want open a new window popup no modal,
then override this method
public class MyDataGrid extends DataGrid {
.
@Override
protected void onRowClicked(AjaxRequestTarget target, IModel
rowModel) {
Myentity myEntity= (MyEntity)rowModel.getObject();
PageParameters param = new PageParameters();
param.put("id", myEntity.getId() );
String unULR =
RequestCycle.get().urlFor(MyNewWindowPopup.class, param).toString();
String name_pagemap = "r"+ myEntity;
PopupSettings setting = new
PopupSetting(Page.forName(name_pagemap));
settings.setHeight(500);
settings.setWidth(700);
settings.setTarget(unULR);
target.appendJavascript(settings.getPopupJavaScript());
}
}
my window doesn't open, how to open it?
Yahoo! Cocina
Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/
MultiPartServletRequest Exception
As recent as the 1.4.4 release (dated December 10th, 2009), I started getting the following stack trace. This happens when submitting the form. Note: This doesn't seem to occur with the same code base running against Wicket 1.4.1. Did something break in 1.4.4 relating to this? java.lang.IllegalStateException: ServletRequest does not contain multipart content at org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.(MultipartServletWebRequest.java:113) at org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.(MultipartServletWebRequest.java:83) at org.apache.wicket.protocol.http.servlet.ServletWebRequest.newMultipartWe bRequest(ServletWebRequest.java:500) at org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1651) at org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:850) at org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmi tBehavior.java:135) at org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java: 177) at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDef aultAjaxBehavior.java:299) at org.apache.wicket.request.target.component.listener.BehaviorRequestTarge t.processEvents(BehaviorRequestTarget.java:119) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(Ab stractRequestCycleProcessor.java:92) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java :1250) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428) ... J.D. Corbin | IQNavigator, Inc. | Technology 6465 Greenwood Village Blvd, Suite 800, Centennial, CO 80111 | Office 303.563.1503 | Mobile 303.912.0958 | www.iqnavigator.com | jcor...@iqnavigator.com
Re: Why feedback panel won't work
Hej, 2009/12/28 uud ashr : > Won't work using: > setResponsePage(MyAnotherPage.class); > > But fine when use constructor: > setResponsePage(new MyAnotherPage()); At work we had a similar case where an object in the session, that was explicitely set before calling, wasn't set in the called page when the class variant was used but was set when the constructor variant was used. Bye Hauke Ingmar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
SV: Handling Ajax session expired
> 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...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Quick question - Bad to serialize a class reference?
Martijn Dashorst wrote: > > why not use Class.getName() instead? > This is a generic component that can be used for any kind of modalwindow link. So naturally I won't know what the fallback page is for every instantiation. -- View this message in context: http://old.nabble.com/Quick-question---Bad-to-serialize-a-class-reference--tp26947639p26948292.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Quick question - Bad to serialize a class reference?
why not use Class.getName() instead? Martijn On Mon, Dec 28, 2009 at 9:41 PM, Anthony DePalma wrote: > I am making a modal window link component that will fallback to a > standard redirect if javascript is disabled. Traditionally I have been > overriding a method called onFallback() and forcing users to manually > setRedirect(true), setResponsePage(blah), but I would prefer it if I > could just pass the class reference in the constructor and handle that > logic myself in the onclick. > > That means serializing the class reference across to the onclick. Are > there performance implications at all? My gut reaction is no because I > see a lot of transient objects in the Class object, but I wanted to > confirm. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket feedback
Hi Igor, Em 23/12/2009 20:28, Igor Vaynberg escreveu: On Wed, Dec 23, 2009 at 12:51 PM, Ricardo Mayerhofer wrote: Good discussion. Em 23/12/2009 15:32, Igor Vaynberg escreveu: On Wed, Dec 23, 2009 at 7:02 AM, Ricardo Mayerhofer wrote: Hi Igor, Thanks for your response. Here goes my observations: Em 22/12/2009 14:41, Igor Vaynberg escreveu: On Tue, Dec 22, 2009 at 5:19 AM, Ricardo Mayerhofer wrote: Hi all, We've just finished with success a wicket project for a large online retailer. I think wicket is the best framework out there, but as any other project there is room for improvement. I will talk about some topics bellow, I hope it can help in some way. - Separation of corcerns I think we could get a better separation of concerns if page class were focused more in behavior and html were more focused in display (or view). What I mean is, some times we have components that the main purpose is to add behavior, and we have to add extra markup just to satisfy wicket 1:1 mapping. Take CheckGroup for exaple, it is a component focused on behavior, even though we have to add a reference to it in HTML. a redesigned CheckGroup is welcome, but that component is the exception and not the rule. Yes, but how do we deal with the requirement of all components having a HTML representation? The same happens with RadioGroup, even with wicket-1055 solved, the HTML reference is still there. CheckGroup and RadioGroup are essentially the same thing as far as the way they work. once you redesign CheckGroup the RadioGroup update will be minimal.f i dont think there is a big problem requiring every component to have an html tag. after all wicket is a component based framework where components represent ui which is in turn represented by html tags. the tags also carry with them importance on nesting, so i also dont think its a problem that wicket components carry the same importance. I think that components should not represent UI, because if you do so you will get a very strong coupling between both. I think it should be there to add behavior to UI. heh, the whole point of wicket is to build UI so there has to be coupling. Wicket being targeted to build UI, doesn't mean its layers should be coupled. Just like the VC part of the old MVC pattern. Dispite the fact they collaborate to solve UI problems, they are loosely coupled (or not even coupled at all in the original definition). It's mainly a philosofical difference that has many implications. For example, if we go with the last there won't be TextArea, TextField, HiddenField and PasswordField. Only a text field component, that represents behavior for this kind of input. ok. lets say there is no textarea component only a textfield. how do we add support for attributes that textarea supports that input tags dont, such as cols and rows. lets say i have a requirement to control those pragmatically. if we have no textarea component then i have to use attribute modifiers or some other means to add the cols and rows attributes, but by doing so any knowledge of how they work and what constraints they have is completely decoupled from the component - which is not a good thing because you have traded coupling for encapsulation. the very basic principal of OOP is that your data is coupled to the behavior that modifies the data - an Object. This architecture favors decoupling between java and HTML. Rows and cols are a purely view concern, so it shouldn't be handled in page class. If there's a situation where it necessary to change textarea size the best thing to do IMO is to append a class, so the designer is free to choose the most appropriate display information and still can choose the most appropriate form element to the current job (textarea or text input). With the current architeture one may think that it's ok to put these things in java, for example, extending TextArea and hardcoding this information. Regarding other attributes, I don't recall one that is only appliable to a specific tag and requires encapsulation. This situation might happen, but I would say YAGNI for now. The same for buttons and links. these are all simple components. what happens when we talk about components that compose others? such as the DataTable that composes Items that compose user's other Components that represent rows? You also solve checkgroup and radiogroup useless tag problem, and open doors for components that the main purpose is to add behavior to the page, even if not directly related to one specific tag. lets see a concrete way of how this will work. do we now have something in Component hierarchy that is an "non-rendered" component? how do all the current cascades and visitors work with this? In my limited knowlege I would say just like rendered components. That's the very example you gave, a webmarkupcontai
Quick question - Bad to serialize a class reference?
I am making a modal window link component that will fallback to a standard redirect if javascript is disabled. Traditionally I have been overriding a method called onFallback() and forcing users to manually setRedirect(true), setResponsePage(blah), but I would prefer it if I could just pass the class reference in the constructor and handle that logic myself in the onclick. That means serializing the class reference across to the onclick. Are there performance implications at all? My gut reaction is no because I see a lot of transient objects in the Class object, but I wanted to confirm. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Testing AjaxSubmitLink#onSubmit() with WicketTester @L
I unsuccessfully tried several different ways to invoke the AjaxSubmitLink
from my test method.
1. formTester.submit("submitButton") does not call
AjaxSubmitLink#onSubmit(AjaxRequestTarget target, Form form)
2. formTester.submitLink("submitButton", false) fails with
*org.apache.wicket.WicketRuntimeException: Link
panel:referralForm:submitButtonis an AjaxSubmitLink and will not be invoked
when AJAX (javascript) is disabled.*
3. tester.clickLink("referralForm:submitButton, true) does not call
AjaxSubmitLink#onSubmit(AjaxRequestTarget target, Form form)
4. EnhancedWicketTester.clickAjaxLink("referralForm:submitButton") fails
with
*junit.framework.AssertionFailedError: component
'ReferralPanel$ReferralForm$2' is not type:Link*
This makes sense because AjaxSubmitLink class is not a subclass of Link.
So, how do I test AjaxSubmitLink#onSubmit(AjaxRequestTarget target, Form
form) method?
Thanks,
Alec
@L
On Sun, Dec 27, 2009 at 9:44 AM, Alec Swan wrote:
> I have a page with a form and AjaxSubmitLink in the form.
>
> I call WicketTester#clickLink(pathToLink, true) to test the code in
> AjaxSubmitLink#onSubmit(). The call returns with no errors, but
> AjaxSubmitLink#onSubmit() is never called.
>
> Here is a code sample:
>
> tester.startPanel(MyPanel.class);
> final FormTester formTester = tester.newFormTester(FORM_PATH);
>
> // Test: Submit form with valid inputs
> formTester.setValue("company", "company");
> formTester.setValue("phone", "phone");
> *tester.clickLink(SUBMIT_LINK_PATH, true);*
>
> Thanks,
>
> Alec
>
>
>
>
>
SOLVED: Is AnnotApplicationContextMock() broken in Wicket 1.4.5? @l
The problem was that the test case was creating AnnotApplicationContextMock
before creating the WebApplication itself. The following code worked for me:
MyApplication webApp = new MyApplication()
{
@Override
public void init() {
addComponentInstantiationListener(new
SpringComponentInjector(this, new AnnotApplicationContextMock(), false));
}
};
Alec
On Mon, Dec 28, 2009 at 11:01 AM, Alec Swan wrote:
> I just upgraded from Wicket 1.4.2 to Wicket 1.4.5 and started receiving the
> following exceptions from my Unit test.
>
> Is this a known issue or do I need to change my test?
>
> Thanks.
>
> org.apache.wicket.WicketRuntimeException: *There is no application
> attached to current thread main*
> at org.apache.wicket.Application.get(Application.java:179)
> at
> org.apache.wicket.injection.web.InjectorHolder.setInjector(InjectorHolder.java:88)
> at
> org.apache.wicket.spring.injection.annot.test.AnnotApplicationContextMock.(AnnotApplicationContextMock.java:61)
> at
> com.galecsy.lrm.wicket.referral.ReferralFormTest.beforeTest(ReferralFormTest.java:43)
> at
> org.springframework.test.context.junit4.SpringMethodRoadie.runBefores(SpringMethodRoadie.java:273)
> at
> org.springframework.test.context.junit4.SpringMethodRoadie$RunBeforesThenTestThenAfters.run(SpringMethodRoadie.java:332)
> at
> org.springframework.test.context.junit4.SpringMethodRoadie.runWithRepetitions(SpringMethodRoadie.java:217)
> at
> org.springframework.test.context.junit4.SpringMethodRoadie.runTest(SpringMethodRoadie.java:197)
> at
> org.springframework.test.context.junit4.SpringMethodRoadie.run(SpringMethodRoadie.java:143)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.invokeTestMethod(SpringJUnit4ClassRunner.java:160)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:97)
>
>
>
Re: Handling Ajax session expired
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 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 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-mail: users-h...@wicket.apache.org >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 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 >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 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-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 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-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 >> > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 > > 2009/12/28 Martin Makundi : >> - 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 not lock you into a single way of doing multihoming. >> >> It would be nice to have a properly working default multihoming >> support, out-of-the-box. I would guess it's quite common need in any >> bit complex application. >> >> Or maybe it can be worked around using styles? Storing user style into >> application context and serving home pages accordingly? >> >> ** >> Martin >> >> 2009/12/28 Igor Vaynberg : >>> 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, Martin Makundi >>> wrote: > 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 > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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, 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 not lock you into a single way of doing multihoming. > > It would be nice to have a properly working default multihoming > support, out-of-the-box. I would guess it's quite common need in any > bit complex application. > > Or maybe it can be worked around using styles? Storing user style into > application context and serving home pages accordingly? > > ** > Martin > > 2009/12/28 Igor Vaynberg : >> 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, Martin Makundi >> wrote: 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 >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
- 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 not lock you into a single way of doing multihoming. It would be nice to have a properly working default multihoming support, out-of-the-box. I would guess it's quite common need in any bit complex application. Or maybe it can be worked around using styles? Storing user style into application context and serving home pages accordingly? ** Martin 2009/12/28 Igor Vaynberg : > 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, Martin Makundi > wrote: >>> 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 >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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, Martin Makundi wrote: >> 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 >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
session.size - pagemaps.size = http-session.size?
is this rule approx true? as far as it's described in the javadoc: [1] org.apache.wicket.Session.getSizeInBytes() Size of this session, including all the pagemaps it contains [2] org.apache.wicket.PageMap.getSizeInBytes() Size of this page map in bytes, including a sum of the sizes of all the pages it contains. [3] org.apache.wicket.Session.getPageMaps() A list of all PageMaps in this session. so iterating on pages obtained by [3] and adding each size with [2], then substracting this result to [1], does it provide the accurate size of wicket-session in http-session?
Is AnnotApplicationContextMock() broken in Wicket 1.4.5?
I just upgraded from Wicket 1.4.2 to Wicket 1.4.5 and started receiving the following exceptions from my Unit test. Is this a known issue or do I need to change my test? Thanks. org.apache.wicket.WicketRuntimeException: *There is no application attached to current thread main* at org.apache.wicket.Application.get(Application.java:179) at org.apache.wicket.injection.web.InjectorHolder.setInjector(InjectorHolder.java:88) at org.apache.wicket.spring.injection.annot.test.AnnotApplicationContextMock.(AnnotApplicationContextMock.java:61) at com.galecsy.lrm.wicket.referral.ReferralFormTest.beforeTest(ReferralFormTest.java:43) at org.springframework.test.context.junit4.SpringMethodRoadie.runBefores(SpringMethodRoadie.java:273) at org.springframework.test.context.junit4.SpringMethodRoadie$RunBeforesThenTestThenAfters.run(SpringMethodRoadie.java:332) at org.springframework.test.context.junit4.SpringMethodRoadie.runWithRepetitions(SpringMethodRoadie.java:217) at org.springframework.test.context.junit4.SpringMethodRoadie.runTest(SpringMethodRoadie.java:197) at org.springframework.test.context.junit4.SpringMethodRoadie.run(SpringMethodRoadie.java:143) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.invokeTestMethod(SpringJUnit4ClassRunner.java:160) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:97)
Re: Handling Ajax session expired
> 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 > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 a silo >> cookie. when the session expires, the cookie will still be there. >> >> -igor >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 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 be there. >> >> -igor >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 be there. > > -igor > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 >> 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> wrote: >> >>> 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/homepage which is >>> automatically rendered by the behavior." >>> >>> Is this descriptive enough? >>> >>> Maybe some junit wickettester test cases? >>> - "test 1: User has begun using Silo1Homepage.class when session is >>> invalidated. User is redirected back to Silo1Homepage." >>> - "test 2: User has begun using Silo2Homepage.class when session is >>> invalidated. User is redirected back to Silo2Homepage." >>> - similar for error pages, and after error page -> silo-home-page >>> - etc. >>> >>> ** >>> Martin >>> >>> >>> 2009/12/28 Ernesto Reinaldo Barreiro : >>> > 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 when necessary. >>> >> >>> >> ** >>> >> Martin >>> >> >>> >> 2009/12/28 Ernesto Reinaldo Barreiro : >>> >> >> >>> >> >> >>> >> >> 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 >>> >> > >>> >> >>> >> - >>> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> >> For additional commands, e-mail: users-h...@wicket.apache.org >>> >> >>> >> >>> > >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Question regarding DataTable and Checkbox/Radio Columns
On Mon, Dec 28, 2009 at 4:49 AM, Early Morning wrote:
> Hi all,
>
> I created a custom DataTable based on AjaxFallbackDefaultDataTable, as well
> as a ChecBoxColumn based on the CheckBoxColumn in wicket-phonebook. My
> questions:
>
> 1. Would it be also possible to create a RadioColumn for the DataTable? From
> what I've read, I need to add the entire DataTable to the RadioGroup, so I'm
> not sure if it's possible to implement this as a column. How would I
> implement this as a column?
it is possible without a RadioGroup/Radio components, simply write
your own component that represents the input type="radio".
> 2. Relatedly, is there a way for me to implement the CheckBoxColumn having a
> CheckGroup with a select all checkbox in the header?
you dont need a CheckGroup for this also, it is trivial to write a
simple javascript. every CheckBoxColumn should create a uuid when it
is constructed, either using UUID.randomUUID or Session.nextUuid().
then append this uuid as a class to the input type="checkbox" you are
using. once this is done you have a way to identify all related
checkboxes in the page. then it is simply a matter of creating a
checkbox that in onclick does some javascript like
$("."+myuuid).checked=this.checked; and putting it into a panel that
is used as a header of the column. phew.
-igor
>
>
> Thanks!
>
>
> Regards,
>
> Ces
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Default Focus Behavior?
Thank you MartinM. Your question caused me to question the other methods I was overriding from the super...after removing those unnecessary overridden methods, its working like a charm. Thank you! MartinM wrote: > > Hi! > > Did you implement the IHeaderContributor and mark @Override? > > 2009/12/28 duncan787 : >> >> Great tip, thanks! After implementing, I see that the behavior is added >> to >> the text field correctly, but the renderHead() method is not being >> called, >> can you help me understand why that is? >> > > ** > Martin > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > -- View this message in context: http://old.nabble.com/Default-Focus-Behavior--tp15934889p26944984.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: File Upload Issues
I'll try the quickstart and see if I can reproduce it outside of our code. We are using Wicket 1.4.4 and the issue occurs. I'm not sure if it's the looping issue or not, I've just observed, that with the upload control in a form, none of the ajax behaviors on other controls that are on the same form work. I've also tried 1.4.5 and it behaves the same. J.D. -Original Message- From: Major Péter [mailto:majorpe...@sch.bme.hu] Sent: Monday, December 28, 2009 9:28 AM To: users@wicket.apache.org Subject: Re: File Upload Issues Hi, I had some issue with multipart forms and ajax recently, but in 1.4.4 it works for me, see https://issues.apache.org/jira/browse/WICKET-2432 for more details. Is this the same issue for you? Maybe try the quickstart, see if there the ajax is working for you. Regards, Peter 2009-12-28 16:46 keltezéssel, Corbin, James írta: > Any feedback on why placing a file upload component on a form in Wicket > would cause the ajax behavior to stop working > > Known issue within the wicket community? > > J.D. > > -Original Message- > From: Corbin, James [mailto:jcor...@iqnavigator.com] > Sent: Friday, December 18, 2009 12:47 PM > To: users@wicket.apache.org > Subject: RE: File Upload Issues > > Ajax has stopped working. If I remove the file upload component, the > ajax begins working as expected. > > Is there a workaround or a pending fix? > > Thanks, > J.D. > > -Original Message- > From: Douglas Ferguson [mailto:doug...@douglasferguson.us] > Sent: Friday, December 18, 2009 12:03 PM > To: users@wicket.apache.org > Subject: Re: File Upload Issues > > There is a bug in 1.4.4. related to resource loading. > > Are you sure AJAX has stopped or is it just taking A REALLY LONG TIME? > > This is the reason they are trying to get 1.4.5 out quickly. > > D/ > > > On Dec 18, 2009, at 10:15 AM, Corbin, James wrote: > >> Hello, >> >> >> >> I'm having issues in IE6 relating to the the File Upload Control after >> upgrading to Wicket 1.4.4. >> >> >> >> If I attempt to put a file upload component onto a form that contains >> other components that do ajax, everything stops working in regards to >> ajax. >> >> >> >> Now I understand that the file upload component does NOT support ajax. >> Does it follow that putting a file upload component on a form that > does >> ajax is not supported? >> >> >> >> J.D. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: File Upload Issues
Hi, I had some issue with multipart forms and ajax recently, but in 1.4.4 it works for me, see https://issues.apache.org/jira/browse/WICKET-2432 for more details. Is this the same issue for you? Maybe try the quickstart, see if there the ajax is working for you. Regards, Peter 2009-12-28 16:46 keltezéssel, Corbin, James írta: > Any feedback on why placing a file upload component on a form in Wicket > would cause the ajax behavior to stop working > > Known issue within the wicket community? > > J.D. > > -Original Message- > From: Corbin, James [mailto:jcor...@iqnavigator.com] > Sent: Friday, December 18, 2009 12:47 PM > To: users@wicket.apache.org > Subject: RE: File Upload Issues > > Ajax has stopped working. If I remove the file upload component, the > ajax begins working as expected. > > Is there a workaround or a pending fix? > > Thanks, > J.D. > > -Original Message- > From: Douglas Ferguson [mailto:doug...@douglasferguson.us] > Sent: Friday, December 18, 2009 12:03 PM > To: users@wicket.apache.org > Subject: Re: File Upload Issues > > There is a bug in 1.4.4. related to resource loading. > > Are you sure AJAX has stopped or is it just taking A REALLY LONG TIME? > > This is the reason they are trying to get 1.4.5 out quickly. > > D/ > > > On Dec 18, 2009, at 10:15 AM, Corbin, James wrote: > >> Hello, >> >> >> >> I'm having issues in IE6 relating to the the File Upload Control after >> upgrading to Wicket 1.4.4. >> >> >> >> If I attempt to put a file upload component onto a form that contains >> other components that do ajax, everything stops working in regards to >> ajax. >> >> >> >> Now I understand that the file upload component does NOT support ajax. >> Does it follow that putting a file upload component on a form that > does >> ajax is not supported? >> >> >> >> J.D. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Java Wicket Job Opportunity, Finland
Well done, Uwe! -- View this message in context: http://old.nabble.com/Java-Wicket-Job-Opportunity%2C-Finland-tp26853946p26944833.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Default Focus Behavior?
Hi! Did you implement the IHeaderContributor and mark @Override? 2009/12/28 duncan787 : > > Great tip, thanks! After implementing, I see that the behavior is added to > the text field correctly, but the renderHead() method is not being called, > can you help me understand why that is? > ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Default Focus Behavior?
Great tip, thanks! After implementing, I see that the behavior is added to
the text field correctly, but the renderHead() method is not being called,
can you help me understand why that is?
jwcarman wrote:
>
> On 3/9/08, James Carman wrote:
>> On 3/9/08, Warren wrote:
>> > WebMarkupContainer bodyTag = new WebMarkupContainer("bodyTag");
>> > bodyTag.add(new SimpleAttributeModifier("onload",
>> > "form.username.focus();"));
>>
>>
>> Ok, but wouldn't it be cooler/easier/more java-oriented to do:
>>
>> TextField userName = new TextField("userName");
>> userName.addBehavior(new DefaultFocusBehavior());
>>
>> or
>>
>> Behaviors.defaultFocus(userName); // Assuming Behaviors existed.
>>
>>
>
> How about something like:
>
> public class DefaultFocusBehavior extends AbstractBehavior
> {
> private Component component;
>
> public void bind( Component component )
> {
> this.component = component;
> component.setOutputMarkupId(true);
> }
>
> public void renderHead( IHeaderResponse iHeaderResponse )
> {
> super.renderHead(iHeaderResponse);
> iHeaderResponse.renderOnLoadJavascript("document.getElementById('"
> + component.getMarkupId() + "').focus();");
> }
> }
>
>> >
>> >
>> > > -Original Message-
>> > > From: jcar...@carmanconsulting.com
>> > > [mailto:jcar...@carmanconsulting.com]on Behalf Of James Carman
>> > > Sent: Sunday, March 09, 2008 7:58 AM
>> > > To: users@wicket.apache.org
>> > > Subject: Default Focus Behavior?
>> > >
>> > >
>> > > Is there a behavior (or some other way) for having a field receive
>> the
>> > > focus when the page loads? For instance, in a login form, you'd
>> want
>> > > the focus to go to the username field or perhaps the password field
>> if
>> > > you've got "remember me" turned on.
>> > >
>> >
>> > >
>> -
>> > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> > > For additional commands, e-mail: users-h...@wicket.apache.org
>> > >
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >
>> >
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>
--
View this message in context:
http://old.nabble.com/Default-Focus-Behavior--tp15934889p26944784.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
RE: File Upload Issues
Any feedback on why placing a file upload component on a form in Wicket would cause the ajax behavior to stop working Known issue within the wicket community? J.D. -Original Message- From: Corbin, James [mailto:jcor...@iqnavigator.com] Sent: Friday, December 18, 2009 12:47 PM To: users@wicket.apache.org Subject: RE: File Upload Issues Ajax has stopped working. If I remove the file upload component, the ajax begins working as expected. Is there a workaround or a pending fix? Thanks, J.D. -Original Message- From: Douglas Ferguson [mailto:doug...@douglasferguson.us] Sent: Friday, December 18, 2009 12:03 PM To: users@wicket.apache.org Subject: Re: File Upload Issues There is a bug in 1.4.4. related to resource loading. Are you sure AJAX has stopped or is it just taking A REALLY LONG TIME? This is the reason they are trying to get 1.4.5 out quickly. D/ On Dec 18, 2009, at 10:15 AM, Corbin, James wrote: > Hello, > > > > I'm having issues in IE6 relating to the the File Upload Control after > upgrading to Wicket 1.4.4. > > > > If I attempt to put a file upload component onto a form that contains > other components that do ajax, everything stops working in regards to > ajax. > > > > Now I understand that the file upload component does NOT support ajax. > Does it follow that putting a file upload component on a form that does > ajax is not supported? > > > > J.D. > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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. 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 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. Seems worth exploring whether your Silos might divide well >> in >>> this manner, maybe with a bit of work, but probably more likely to happen >>> than what it seems like you are looking for, which doesn't sound (just >> one >>> casual observer's option) broadly applicable enough to warrant framework >>> inclusion. >> >> this wouldn't work easily, because for example when you have EJBs in >> your project, you can't deploy the same app to different contextroots, >> because the EJBs JNDI name is already bounded, so this way you would >> have to run your slightly different apps on different appservers too, >> and that's just ugly. I think Martin has a point there, maybe Wicket >> should support this use-case. >> >> Regards, >> Peter >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 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. Seems worth exploring whether your Silos might divide well > in > > this manner, maybe with a bit of work, but probably more likely to happen > > than what it seems like you are looking for, which doesn't sound (just > one > > casual observer's option) broadly applicable enough to warrant framework > > inclusion. > > this wouldn't work easily, because for example when you have EJBs in > your project, you can't deploy the same app to different contextroots, > because the EJBs JNDI name is already bounded, so this way you would > have to run your slightly different apps on different appservers too, > and that's just ugly. I think Martin has a point there, maybe Wicket > should support this use-case. > > Regards, > Peter > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Pieter Degraeuwe Systemworks bvba Belgiëlaan 61 9070 Destelbergen GSM: +32 (0)485/68.60.85 Email: pieter.degrae...@systemworks.be visit us at http://www.systemworks.be
Re: Handling Ajax session expired
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 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 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. Seems worth exploring whether your Silos might divide well >> in >> > this manner, maybe with a bit of work, but probably more likely to happen >> > than what it seems like you are looking for, which doesn't sound (just >> one >> > casual observer's option) broadly applicable enough to warrant framework >> > inclusion. >> >> this wouldn't work easily, because for example when you have EJBs in >> your project, you can't deploy the same app to different contextroots, >> because the EJBs JNDI name is already bounded, so this way you would >> have to run your slightly different apps on different appservers too, >> and that's just ugly. I think Martin has a point there, maybe Wicket >> should support this use-case. >> >> Regards, >> Peter >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > -- > Pieter Degraeuwe > Systemworks bvba > Belgiëlaan 61 > 9070 Destelbergen > GSM: +32 (0)485/68.60.85 > Email: pieter.degrae...@systemworks.be > visit us at http://www.systemworks.be > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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. Seems worth exploring whether your Silos might divide well in > this manner, maybe with a bit of work, but probably more likely to happen > than what it seems like you are looking for, which doesn't sound (just one > casual observer's option) broadly applicable enough to warrant framework > inclusion. this wouldn't work easily, because for example when you have EJBs in your project, you can't deploy the same app to different contextroots, because the EJBs JNDI name is already bounded, so this way you would have to run your slightly different apps on different appservers too, and that's just ugly. I think Martin has a point there, maybe Wicket should support this use-case. Regards, Peter - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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, 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 "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 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. Seems worth exploring whether your Silos might divide well > in > > this manner, maybe with a bit of work, but probably more likely to happen > > than what it seems like you are looking for, which doesn't sound (just > one > > casual observer's option) broadly applicable enough to warrant framework > > inclusion. > > > > Good luck > > Jim P > > On Mon, Dec 28, 2009 at 8:04 AM, Martin Makundi < > > martin.maku...@koodaripalvelut.com> wrote: > > > >> 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> wrote: > >> > > >> >> 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/homepage which is > >> >> automatically rendered by the behavior." > >> >> > >> >> Is this descriptive enough? > >> >> > >> >> Maybe some junit wickettester test cases? > >> >> - "test 1: User has begun using Silo1Homepage.class when session is > >> >> invalidated. User is redirected back to Silo1Homepage." > >> >> - "test 2: User has begun using Silo2Homepage.class when session is > >> >> invalidated. User is redirected back to Silo2Homepage." > >> >> - similar for error pages, and after error page -> silo-home-page > >> >> - etc. > >> >> > >> >> ** > >> >> Martin > >> >> > >> >> > >> >> 2009/12/28 Ernesto Reinaldo Barreiro : > >> >> > 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 when necessary. > >> >> >> > >> >> >> ** > >> >> >> Martin > >> >> >> > >> >> >> 2009/12/28 Ernesto Reinaldo Barreiro : > >> >> >> >> > >> >> >> >> > >> >> >> >> 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 > >> >> >> > > >> >> >> > >> >> >> > - > >> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> >> >> For additional commands, e-mail: users-h...@wicket.apache.org > >> >> >> > >> >> >> > >> >> > > >> >> > >> >> - > >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> >> For additional commands, e-mail: users-h...@wicket.apache.org > >> >> > >> >> > >> > > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Handling Ajax session expired
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 hacked at by the developed (as the one hi has in place now). Best, Ernesto On Mon, Dec 28, 2009 at 3:57 PM, Jim Pinkham wrote: > 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 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. Seems worth exploring whether your Silos might divide well in > this manner, maybe with a bit of work, but probably more likely to happen > than what it seems like you are looking for, which doesn't sound (just one > casual observer's option) broadly applicable enough to warrant framework > inclusion. > > Good luck > Jim P > On Mon, Dec 28, 2009 at 8:04 AM, Martin Makundi < > martin.maku...@koodaripalvelut.com> wrote: > > > 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> wrote: > > > > > >> 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/homepage which is > > >> automatically rendered by the behavior." > > >> > > >> Is this descriptive enough? > > >> > > >> Maybe some junit wickettester test cases? > > >> - "test 1: User has begun using Silo1Homepage.class when session is > > >> invalidated. User is redirected back to Silo1Homepage." > > >> - "test 2: User has begun using Silo2Homepage.class when session is > > >> invalidated. User is redirected back to Silo2Homepage." > > >> - similar for error pages, and after error page -> silo-home-page > > >> - etc. > > >> > > >> ** > > >> Martin > > >> > > >> > > >> 2009/12/28 Ernesto Reinaldo Barreiro : > > >> > 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 when necessary. > > >> >> > > >> >> ** > > >> >> Martin > > >> >> > > >> >> 2009/12/28 Ernesto Reinaldo Barreiro : > > >> >> >> > > >> >> >> > > >> >> >> 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 > > >> >> > > > >> >> > > >> >> > - > > >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > >> >> For additional commands, e-mail: users-h...@wicket.apache.org > > >> >> > > >> >> > > >> > > > >> > > >> - > > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > >> For additional commands, e-mail: users-h...@wicket.apache.org > > >> > > >> > > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > >
Re: strange classcastexception
Hi Sam,
did you try
birthDateField = new TextField("birthDate", new Model(),
Date.class);
Maybe it helps.
Cheers
Per
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 "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 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. Seems worth exploring whether your Silos might divide well in > this manner, maybe with a bit of work, but probably more likely to happen > than what it seems like you are looking for, which doesn't sound (just one > casual observer's option) broadly applicable enough to warrant framework > inclusion. > > Good luck > Jim P > On Mon, Dec 28, 2009 at 8:04 AM, Martin Makundi < > martin.maku...@koodaripalvelut.com> wrote: > >> 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> wrote: >> > >> >> 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/homepage which is >> >> automatically rendered by the behavior." >> >> >> >> Is this descriptive enough? >> >> >> >> Maybe some junit wickettester test cases? >> >> - "test 1: User has begun using Silo1Homepage.class when session is >> >> invalidated. User is redirected back to Silo1Homepage." >> >> - "test 2: User has begun using Silo2Homepage.class when session is >> >> invalidated. User is redirected back to Silo2Homepage." >> >> - similar for error pages, and after error page -> silo-home-page >> >> - etc. >> >> >> >> ** >> >> Martin >> >> >> >> >> >> 2009/12/28 Ernesto Reinaldo Barreiro : >> >> > 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 when necessary. >> >> >> >> >> >> ** >> >> >> Martin >> >> >> >> >> >> 2009/12/28 Ernesto Reinaldo Barreiro : >> >> >> >> >> >> >> >> >> >> >> >> 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 >> >> >> > >> >> >> >> >> >> - >> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> >> >> >> > >> >> >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> > >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 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. Seems worth exploring whether your Silos might divide well in this manner, maybe with a bit of work, but probably more likely to happen than what it seems like you are looking for, which doesn't sound (just one casual observer's option) broadly applicable enough to warrant framework inclusion. Good luck Jim P On Mon, Dec 28, 2009 at 8:04 AM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > 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> wrote: > > > >> 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/homepage which is > >> automatically rendered by the behavior." > >> > >> Is this descriptive enough? > >> > >> Maybe some junit wickettester test cases? > >> - "test 1: User has begun using Silo1Homepage.class when session is > >> invalidated. User is redirected back to Silo1Homepage." > >> - "test 2: User has begun using Silo2Homepage.class when session is > >> invalidated. User is redirected back to Silo2Homepage." > >> - similar for error pages, and after error page -> silo-home-page > >> - etc. > >> > >> ** > >> Martin > >> > >> > >> 2009/12/28 Ernesto Reinaldo Barreiro : > >> > 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 when necessary. > >> >> > >> >> ** > >> >> Martin > >> >> > >> >> 2009/12/28 Ernesto Reinaldo Barreiro : > >> >> >> > >> >> >> > >> >> >> 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 > >> >> > > >> >> > >> >> - > >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> >> For additional commands, e-mail: users-h...@wicket.apache.org > >> >> > >> >> > >> > > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: strange classcastexception
did you try debugger and breakpoint?
2009/12/28 Sam Barrow :
> I tried that too, still same error.
>
> On Mon, 2009-12-28 at 16:02 +0200, Martin Makundi wrote:
>> You forgot to set Type of the textfield... you know, generics are only
>> compile-deep.
>>
>> public TextField(final String id, final Class type)
>>
>> type -> Date.class
>>
>> **
>> Martin
>>
>> 2009/12/28 Sam Barrow :
>> > I'm getting this exception when calling getConvertedInput() on
>> > birthDateField.
>> >
>> > java.lang.ClassCastException: java.lang.String cannot be cast to
>> > java.util.Date
>> >
>> > I'm using wicket 1.4.1
>> >
>> >
>> > birthDateField = new TextField("birthDate", new
>> > Model());
>> > birthDateField.setLabel(new Model("Birth Date"));
>> > birthDateField.add(new DatePicker());
>> > FormUtils.addField(this, birthDateField);
>> >
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: strange classcastexception
I tried that too, still same error.
On Mon, 2009-12-28 at 16:02 +0200, Martin Makundi wrote:
> You forgot to set Type of the textfield... you know, generics are only
> compile-deep.
>
> public TextField(final String id, final Class type)
>
> type -> Date.class
>
> **
> Martin
>
> 2009/12/28 Sam Barrow :
> > I'm getting this exception when calling getConvertedInput() on
> > birthDateField.
> >
> > java.lang.ClassCastException: java.lang.String cannot be cast to
> > java.util.Date
> >
> > I'm using wicket 1.4.1
> >
> >
> >birthDateField = new TextField("birthDate", new
> > Model());
> >birthDateField.setLabel(new Model("Birth Date"));
> >birthDateField.add(new DatePicker());
> >FormUtils.addField(this, birthDateField);
> >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: strange classcastexception
You forgot to set Type of the textfield... you know, generics are only
compile-deep.
public TextField(final String id, final Class type)
type -> Date.class
**
Martin
2009/12/28 Sam Barrow :
> I'm getting this exception when calling getConvertedInput() on
> birthDateField.
>
> java.lang.ClassCastException: java.lang.String cannot be cast to
> java.util.Date
>
> I'm using wicket 1.4.1
>
>
> birthDateField = new TextField("birthDate", new
> Model());
> birthDateField.setLabel(new Model("Birth Date"));
> birthDateField.add(new DatePicker());
> FormUtils.addField(this, birthDateField);
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
strange classcastexception
I'm getting this exception when calling getConvertedInput() on
birthDateField.
java.lang.ClassCastException: java.lang.String cannot be cast to
java.util.Date
I'm using wicket 1.4.1
birthDateField = new TextField("birthDate", new
Model());
birthDateField.setLabel(new Model("Birth Date"));
birthDateField.add(new DatePicker());
FormUtils.addField(this, birthDateField);
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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> wrote: > >> 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/homepage which is >> automatically rendered by the behavior." >> >> Is this descriptive enough? >> >> Maybe some junit wickettester test cases? >> - "test 1: User has begun using Silo1Homepage.class when session is >> invalidated. User is redirected back to Silo1Homepage." >> - "test 2: User has begun using Silo2Homepage.class when session is >> invalidated. User is redirected back to Silo2Homepage." >> - similar for error pages, and after error page -> silo-home-page >> - etc. >> >> ** >> Martin >> >> >> 2009/12/28 Ernesto Reinaldo Barreiro : >> > 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 when necessary. >> >> >> >> ** >> >> Martin >> >> >> >> 2009/12/28 Ernesto Reinaldo Barreiro : >> >> >> >> >> >> >> >> >> 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 >> >> > >> >> >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> > >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 comment on this issue? Best, Ernesto On Mon, Dec 28, 2009 at 1:44 PM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > 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/homepage which is > automatically rendered by the behavior." > > Is this descriptive enough? > > Maybe some junit wickettester test cases? > - "test 1: User has begun using Silo1Homepage.class when session is > invalidated. User is redirected back to Silo1Homepage." > - "test 2: User has begun using Silo2Homepage.class when session is > invalidated. User is redirected back to Silo2Homepage." > - similar for error pages, and after error page -> silo-home-page > - etc. > > ** > Martin > > > 2009/12/28 Ernesto Reinaldo Barreiro : > > 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 when necessary. > >> > >> ** > >> Martin > >> > >> 2009/12/28 Ernesto Reinaldo Barreiro : > >> >> > >> >> > >> >> 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 > >> > > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Question regarding DataTable and Checkbox/Radio Columns
Hi all, I created a custom DataTable based on AjaxFallbackDefaultDataTable, as well as a ChecBoxColumn based on the CheckBoxColumn in wicket-phonebook. My questions: 1. Would it be also possible to create a RadioColumn for the DataTable? From what I've read, I need to add the entire DataTable to the RadioGroup, so I'm not sure if it's possible to implement this as a column. How would I implement this as a column? 2. Relatedly, is there a way for me to implement the CheckBoxColumn having a CheckGroup with a select all checkbox in the header? Thanks! Regards, Ces
Re: Handling Ajax session expired
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/homepage which is automatically rendered by the behavior." Is this descriptive enough? Maybe some junit wickettester test cases? - "test 1: User has begun using Silo1Homepage.class when session is invalidated. User is redirected back to Silo1Homepage." - "test 2: User has begun using Silo2Homepage.class when session is invalidated. User is redirected back to Silo2Homepage." - similar for error pages, and after error page -> silo-home-page - etc. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro : > 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 when necessary. >> >> ** >> Martin >> >> 2009/12/28 Ernesto Reinaldo Barreiro : >> >> >> >> >> >> 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 >> > >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 when necessary. > > ** > Martin > > 2009/12/28 Ernesto Reinaldo Barreiro : > >> > >> > >> 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 > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Handling Ajax session expired
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? >> >> > 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 > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
> > > 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
Re: Handling Ajax session expired
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) 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 (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 not know how it can be done, but some information needs to be
>> stored in the URL (all ajax and non-ajax link, button and submit urls)
>> because that's the only information left in Wicket when session dies.
>>
>> **
>> Martin
>>
>> >
>> > Ernesto
>> >
>> > On Mon, Dec 28, 2009 at 12:01 PM, Martin Makundi <
>> > martin.maku...@koodaripalvelut.com> wrote:
>> >
>> >> 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 a certain "user"...
>> >>
>> >> We are not interested in recovering user, only recovering session
>> >> silo. We do not need to identify user. Only silo.
>> >>
>> >> > -Use a listener to record "position", and possibly state, for certain
>> >> pages.
>> >> > Store this into a DB?
>> >>
>> >> Too complicated.
>> >>
>> >> **
>> >> Martin
>> >>
>> >> >
>> >> >
>> >> > On Mon, Dec 28, 2009 at 11:03 AM, Martin Makundi <
>> >> > martin.maku...@koodaripalvelut.com> wrote:
>> >> >
>> >> >> > 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 silos {siloA, siloB, siloC}
>> >> >> - wicket, please track which silo the user is in and serve
>> appropriate
>> >> >> homepage and errorpage when necessary
>> >> >> - each silo with its own homepage
>> >> >> - each silo with its own error page
>> >> >>
>> >> >> This could probably be implemented using something as simple as an
>> url
>> >> >> parameter/relative url or url encoding scheme. Something similar to
>> >> >> the pagemap notation :::0:xxx you would have by default
>> >> >> :::siloA:0:
>> >> >>
>> >> >> The more transparent for the coder the better.
>> >> >>
>> >> >> **
>> >> >> Martin
>> >> >>
>> >> >> >
>> >> >> > Ernesto
>> >> >> >
>> >> >> > On Mon, Dec 28, 2009 at 10:16 AM, Martin Makundi <
>> >> >> > martin.maku...@koodaripalvelut.com> wrote:
>> >> >> >
>> >> >> >> > 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,
>> >> >> >> >
>> >> >> >> > Ernesto
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Mon, Dec 28, 2009 at 9:48 AM, Arie Fishler <
>> arie@gmail.com>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> >> 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 a
>> >> >> >> >> single "home page" i can transfer the user. This means that the
>> >> >> session
>> >> >> >> >> itself had some information on the specific environment the
>> user
>> >> was
>> >> >> in.
>> >> >> >> >>
>> >> >> >> >> I can think of adding some information on the ajax link that
>> will
>> >> >> >> indicate
>> >> >> >> >> that but again the exception happens at the wicket level and if
>> I
>> >> am
>> >> >> >> >> handling the exception not sure how I can retrieve such data.
>> >> >> >> >>
>> >> >> >> >> Any good methodology here?
>> >> >> >> >>
>> >> >> >> >> Thanks,
>> >> >> >> >> Arie
>> >> >> >> >>
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> ---
Re: Handling Ajax session expired
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 (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 not know how it can be done, but some information needs to be
> stored in the URL (all ajax and non-ajax link, button and submit urls)
> because that's the only information left in Wicket when session dies.
>
> **
> Martin
>
> >
> > Ernesto
> >
> > On Mon, Dec 28, 2009 at 12:01 PM, Martin Makundi <
> > martin.maku...@koodaripalvelut.com> wrote:
> >
> >> 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 a certain "user"...
> >>
> >> We are not interested in recovering user, only recovering session
> >> silo. We do not need to identify user. Only silo.
> >>
> >> > -Use a listener to record "position", and possibly state, for certain
> >> pages.
> >> > Store this into a DB?
> >>
> >> Too complicated.
> >>
> >> **
> >> Martin
> >>
> >> >
> >> >
> >> > On Mon, Dec 28, 2009 at 11:03 AM, Martin Makundi <
> >> > martin.maku...@koodaripalvelut.com> wrote:
> >> >
> >> >> > 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 silos {siloA, siloB, siloC}
> >> >> - wicket, please track which silo the user is in and serve
> appropriate
> >> >> homepage and errorpage when necessary
> >> >> - each silo with its own homepage
> >> >> - each silo with its own error page
> >> >>
> >> >> This could probably be implemented using something as simple as an
> url
> >> >> parameter/relative url or url encoding scheme. Something similar to
> >> >> the pagemap notation :::0:xxx you would have by default
> >> >> :::siloA:0:
> >> >>
> >> >> The more transparent for the coder the better.
> >> >>
> >> >> **
> >> >> Martin
> >> >>
> >> >> >
> >> >> > Ernesto
> >> >> >
> >> >> > On Mon, Dec 28, 2009 at 10:16 AM, Martin Makundi <
> >> >> > martin.maku...@koodaripalvelut.com> wrote:
> >> >> >
> >> >> >> > 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,
> >> >> >> >
> >> >> >> > Ernesto
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > On Mon, Dec 28, 2009 at 9:48 AM, Arie Fishler <
> arie@gmail.com>
> >> >> >> wrote:
> >> >> >> >
> >> >> >> >> 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 a
> >> >> >> >> single "home page" i can transfer the user. This means that the
> >> >> session
> >> >> >> >> itself had some information on the specific environment the
> user
> >> was
> >> >> in.
> >> >> >> >>
> >> >> >> >> I can think of adding some information on the ajax link that
> will
> >> >> >> indicate
> >> >> >> >> that but again the exception happens at the wicket level and if
> I
> >> am
> >> >> >> >> handling the exception not sure how I can retrieve such data.
> >> >> >> >>
> >> >> >> >> Any good methodology here?
> >> >> >> >>
> >> >> >> >> Thanks,
> >> >> >> >> Arie
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >>
> -
> >> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >> -
> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.o
Re: Why feedback panel won't work
Should be the same.
Sven
Pieter Degraeuwe wrote:
I was thinking this as well, but the message should in that case also NOT
appear when you do setResponsePage(new MyAnotherPage()), no ?
On Mon, Dec 28, 2009 at 9:39 AM, Sven Meier wrote:
Hi,
feedback messages are tied to components they are reported for (the link in
your case).
Since this component isn't located on your response page, the message will
not be rendered.
Use Session#info() instead.
Regards
Sven
uud ashr wrote:
Hi all,
Why does wicket panel don't work if I do this:
class MyPage extends WebPage {
public MyPage() {
add(new Link("myLink") {
public void onClick() {
* info("You just click me");*
*setResponsePage(MyAnotherPage.class); // feedback panel
won't work*
}
});
}
}
class MyAnotherPage extends WebPage {
public MyAnotherPage() {
add(new FeedbackPanel("feedback"));
}
}
Won't work using:
setResponsePage(MyAnotherPage.class);
But fine when use constructor:
setResponsePage(new MyAnotherPage());
Is this a bug or not a bug?
Regards,
uudashr
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
> 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 not know how it can be done, but some information needs to be
stored in the URL (all ajax and non-ajax link, button and submit urls)
because that's the only information left in Wicket when session dies.
**
Martin
>
> Ernesto
>
> On Mon, Dec 28, 2009 at 12:01 PM, Martin Makundi <
> martin.maku...@koodaripalvelut.com> wrote:
>
>> 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 a certain "user"...
>>
>> We are not interested in recovering user, only recovering session
>> silo. We do not need to identify user. Only silo.
>>
>> > -Use a listener to record "position", and possibly state, for certain
>> pages.
>> > Store this into a DB?
>>
>> Too complicated.
>>
>> **
>> Martin
>>
>> >
>> >
>> > On Mon, Dec 28, 2009 at 11:03 AM, Martin Makundi <
>> > martin.maku...@koodaripalvelut.com> wrote:
>> >
>> >> > 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 silos {siloA, siloB, siloC}
>> >> - wicket, please track which silo the user is in and serve appropriate
>> >> homepage and errorpage when necessary
>> >> - each silo with its own homepage
>> >> - each silo with its own error page
>> >>
>> >> This could probably be implemented using something as simple as an url
>> >> parameter/relative url or url encoding scheme. Something similar to
>> >> the pagemap notation :::0:xxx you would have by default
>> >> :::siloA:0:
>> >>
>> >> The more transparent for the coder the better.
>> >>
>> >> **
>> >> Martin
>> >>
>> >> >
>> >> > Ernesto
>> >> >
>> >> > On Mon, Dec 28, 2009 at 10:16 AM, Martin Makundi <
>> >> > martin.maku...@koodaripalvelut.com> wrote:
>> >> >
>> >> >> > 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,
>> >> >> >
>> >> >> > Ernesto
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Mon, Dec 28, 2009 at 9:48 AM, Arie Fishler
>> >> >> wrote:
>> >> >> >
>> >> >> >> 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 a
>> >> >> >> single "home page" i can transfer the user. This means that the
>> >> session
>> >> >> >> itself had some information on the specific environment the user
>> was
>> >> in.
>> >> >> >>
>> >> >> >> I can think of adding some information on the ajax link that will
>> >> >> indicate
>> >> >> >> that but again the exception happens at the wicket level and if I
>> am
>> >> >> >> handling the exception not sure how I can retrieve such data.
>> >> >> >>
>> >> >> >> Any good methodology here?
>> >> >> >>
>> >> >> >> Thanks,
>> >> >> >> Arie
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >> -
>> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >> >> For additional commands, e-mail: users-h...@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> -
>> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >> For additional commands, e-mail: users-h...@wicket.apache.org
>> >>
>> >>
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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
On Mon, Dec 28, 2009 at 12:01 PM, Martin Makundi <
martin.maku...@koodaripalvelut.com> wrote:
> 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 a certain "user"...
>
> We are not interested in recovering user, only recovering session
> silo. We do not need to identify user. Only silo.
>
> > -Use a listener to record "position", and possibly state, for certain
> pages.
> > Store this into a DB?
>
> Too complicated.
>
> **
> Martin
>
> >
> >
> > On Mon, Dec 28, 2009 at 11:03 AM, Martin Makundi <
> > martin.maku...@koodaripalvelut.com> wrote:
> >
> >> > 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 silos {siloA, siloB, siloC}
> >> - wicket, please track which silo the user is in and serve appropriate
> >> homepage and errorpage when necessary
> >> - each silo with its own homepage
> >> - each silo with its own error page
> >>
> >> This could probably be implemented using something as simple as an url
> >> parameter/relative url or url encoding scheme. Something similar to
> >> the pagemap notation :::0:xxx you would have by default
> >> :::siloA:0:
> >>
> >> The more transparent for the coder the better.
> >>
> >> **
> >> Martin
> >>
> >> >
> >> > Ernesto
> >> >
> >> > On Mon, Dec 28, 2009 at 10:16 AM, Martin Makundi <
> >> > martin.maku...@koodaripalvelut.com> wrote:
> >> >
> >> >> > 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,
> >> >> >
> >> >> > Ernesto
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Mon, Dec 28, 2009 at 9:48 AM, Arie Fishler
> >> >> wrote:
> >> >> >
> >> >> >> 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 a
> >> >> >> single "home page" i can transfer the user. This means that the
> >> session
> >> >> >> itself had some information on the specific environment the user
> was
> >> in.
> >> >> >>
> >> >> >> I can think of adding some information on the ajax link that will
> >> >> indicate
> >> >> >> that but again the exception happens at the wicket level and if I
> am
> >> >> >> handling the exception not sure how I can retrieve such data.
> >> >> >>
> >> >> >> Any good methodology here?
> >> >> >>
> >> >> >> Thanks,
> >> >> >> Arie
> >> >> >>
> >> >> >
> >> >>
> >> >> -
> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >> >>
> >> >>
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Handling Ajax session expired
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 a certain "user"...
We are not interested in recovering user, only recovering session
silo. We do not need to identify user. Only silo.
> -Use a listener to record "position", and possibly state, for certain pages.
> Store this into a DB?
Too complicated.
**
Martin
>
>
> On Mon, Dec 28, 2009 at 11:03 AM, Martin Makundi <
> martin.maku...@koodaripalvelut.com> wrote:
>
>> > 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 silos {siloA, siloB, siloC}
>> - wicket, please track which silo the user is in and serve appropriate
>> homepage and errorpage when necessary
>> - each silo with its own homepage
>> - each silo with its own error page
>>
>> This could probably be implemented using something as simple as an url
>> parameter/relative url or url encoding scheme. Something similar to
>> the pagemap notation :::0:xxx you would have by default
>> :::siloA:0:
>>
>> The more transparent for the coder the better.
>>
>> **
>> Martin
>>
>> >
>> > Ernesto
>> >
>> > On Mon, Dec 28, 2009 at 10:16 AM, Martin Makundi <
>> > martin.maku...@koodaripalvelut.com> wrote:
>> >
>> >> > 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,
>> >> >
>> >> > Ernesto
>> >> >
>> >> >
>> >> >
>> >> > On Mon, Dec 28, 2009 at 9:48 AM, Arie Fishler
>> >> wrote:
>> >> >
>> >> >> 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 a
>> >> >> single "home page" i can transfer the user. This means that the
>> session
>> >> >> itself had some information on the specific environment the user was
>> in.
>> >> >>
>> >> >> I can think of adding some information on the ajax link that will
>> >> indicate
>> >> >> that but again the exception happens at the wicket level and if I am
>> >> >> handling the exception not sure how I can retrieve such data.
>> >> >>
>> >> >> Any good methodology here?
>> >> >>
>> >> >> Thanks,
>> >> >> Arie
>> >> >>
>> >> >
>> >>
>> >> -
>> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >> For additional commands, e-mail: users-h...@wicket.apache.org
>> >>
>> >>
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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", otherwise i get also a pageexpired exception. On click on a ajax link i implement a logic, to rebuild the page for the ajaxlink. And then the event would processed as before. My issues: * if i replace components with ajax-requests before, the beheaviour could also fire a pageexpired exception. But then i redirect to the last known ( rebuilded) Wicketpage. What issues you see in this solution ? We have made some other workarounds for AJAX: * Using JQuery ajax-calls to wicket-resources * Caching a lot of content and switching visibily only on client side with jquery Martin Arie Fishler schrieb: > 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 a > single "home page" i can transfer the user. This means that the session > itself had some information on the specific environment the user was in. > > I can think of adding some information on the ajax link that will indicate > that but again the exception happens at the wicket level and if I am > handling the exception not sure how I can retrieve such data. > > Any good methodology here? > > Thanks, > Arie > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 concept that is application dependent?
I think what you describe can be easilly achieved with the listener approach
I mentioned.
-Use a listener to record "position", and possibly state, for certain pages.
Store this into a DB?
-If session expires have some logic that redirects you to the pages you want
(error, home, etc) based on stored positioning and state.
Ernesto
On Mon, Dec 28, 2009 at 11:03 AM, Martin Makundi <
martin.maku...@koodaripalvelut.com> wrote:
> > 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 silos {siloA, siloB, siloC}
> - wicket, please track which silo the user is in and serve appropriate
> homepage and errorpage when necessary
> - each silo with its own homepage
> - each silo with its own error page
>
> This could probably be implemented using something as simple as an url
> parameter/relative url or url encoding scheme. Something similar to
> the pagemap notation :::0:xxx you would have by default
> :::siloA:0:
>
> The more transparent for the coder the better.
>
> **
> Martin
>
> >
> > Ernesto
> >
> > On Mon, Dec 28, 2009 at 10:16 AM, Martin Makundi <
> > martin.maku...@koodaripalvelut.com> wrote:
> >
> >> > 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,
> >> >
> >> > Ernesto
> >> >
> >> >
> >> >
> >> > On Mon, Dec 28, 2009 at 9:48 AM, Arie Fishler
> >> wrote:
> >> >
> >> >> 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 a
> >> >> single "home page" i can transfer the user. This means that the
> session
> >> >> itself had some information on the specific environment the user was
> in.
> >> >>
> >> >> I can think of adding some information on the ajax link that will
> >> indicate
> >> >> that but again the exception happens at the wicket level and if I am
> >> >> handling the exception not sure how I can retrieve such data.
> >> >>
> >> >> Any good methodology here?
> >> >>
> >> >> Thanks,
> >> >> Arie
> >> >>
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Handling Ajax session expired
> 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 silos {siloA, siloB, siloC}
- wicket, please track which silo the user is in and serve appropriate
homepage and errorpage when necessary
- each silo with its own homepage
- each silo with its own error page
This could probably be implemented using something as simple as an url
parameter/relative url or url encoding scheme. Something similar to
the pagemap notation :::0:xxx you would have by default
:::siloA:0:
The more transparent for the coder the better.
**
Martin
>
> Ernesto
>
> On Mon, Dec 28, 2009 at 10:16 AM, Martin Makundi <
> martin.maku...@koodaripalvelut.com> wrote:
>
>> > 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,
>> >
>> > Ernesto
>> >
>> >
>> >
>> > On Mon, Dec 28, 2009 at 9:48 AM, Arie Fishler
>> wrote:
>> >
>> >> 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 a
>> >> single "home page" i can transfer the user. This means that the session
>> >> itself had some information on the specific environment the user was in.
>> >>
>> >> I can think of adding some information on the ajax link that will
>> indicate
>> >> that but again the exception happens at the wicket level and if I am
>> >> handling the exception not sure how I can retrieve such data.
>> >>
>> >> Any good methodology here?
>> >>
>> >> Thanks,
>> >> Arie
>> >>
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 listener, mark the pages you need with some interface and start a kind of "recorder" whenever the user hits one of those pages... I see no much difficulty on implementing this last approach... Ernesto On Mon, Dec 28, 2009 at 10:16 AM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > > 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, > > > > Ernesto > > > > > > > > On Mon, Dec 28, 2009 at 9:48 AM, Arie Fishler > wrote: > > > >> 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 a > >> single "home page" i can transfer the user. This means that the session > >> itself had some information on the specific environment the user was in. > >> > >> I can think of adding some information on the ajax link that will > indicate > >> that but again the exception happens at the wicket level and if I am > >> handling the exception not sure how I can retrieve such data. > >> > >> Any good methodology here? > >> > >> Thanks, > >> Arie > >> > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Handling Ajax session expired
> 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, > > Ernesto > > > > On Mon, Dec 28, 2009 at 9:48 AM, Arie Fishler wrote: > >> 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 a >> single "home page" i can transfer the user. This means that the session >> itself had some information on the specific environment the user was in. >> >> I can think of adding some information on the ajax link that will indicate >> that but again the exception happens at the wicket level and if I am >> handling the exception not sure how I can retrieve such data. >> >> Any good methodology here? >> >> Thanks, >> Arie >> > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 he signs out) and ask him to resume what the was doing. Of course, you will have to re-create the state of the page they were at which might not be easy if that page changed a lot via AJAX interaction e.g. if page contained a table they navigated or filtered via AJAX you will have to take that into account... or just put them in a sort of initial state. Another possibility is to add an "AJAX hart bit" to such pages to make sure session does not expire while the user is using them... Best, Ernesto On Mon, Dec 28, 2009 at 9:48 AM, Arie Fishler wrote: > 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 a > single "home page" i can transfer the user. This means that the session > itself had some information on the specific environment the user was in. > > I can think of adding some information on the ajax link that will indicate > that but again the exception happens at the wicket level and if I am > handling the exception not sure how I can retrieve such data. > > Any good methodology here? > > Thanks, > Arie >
Re: Handling Ajax session expired
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 wonder if there is something built-in-wicket for this purpose or do we need an rfe? ** Martin 2009/12/28 Arie Fishler : > 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 a > single "home page" i can transfer the user. This means that the session > itself had some information on the specific environment the user was in. > > I can think of adding some information on the ajax link that will indicate > that but again the exception happens at the wicket level and if I am > handling the exception not sure how I can retrieve such data. > > Any good methodology here? > > Thanks, > Arie > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Why feedback panel won't work
I was thinking this as well, but the message should in that case also NOT
appear when you do setResponsePage(new MyAnotherPage()), no ?
On Mon, Dec 28, 2009 at 9:39 AM, Sven Meier wrote:
> Hi,
>
> feedback messages are tied to components they are reported for (the link in
> your case).
> Since this component isn't located on your response page, the message will
> not be rendered.
>
> Use Session#info() instead.
>
> Regards
>
> Sven
>
> uud ashr wrote:
>
>> Hi all,
>>
>> Why does wicket panel don't work if I do this:
>>
>> class MyPage extends WebPage {
>>public MyPage() {
>>add(new Link("myLink") {
>>public void onClick() {
>> * info("You just click me");*
>>*setResponsePage(MyAnotherPage.class); // feedback panel
>> won't work*
>>}
>>});
>>}
>> }
>>
>> class MyAnotherPage extends WebPage {
>>public MyAnotherPage() {
>>add(new FeedbackPanel("feedback"));
>>}
>> }
>>
>>
>>
>> Won't work using:
>> setResponsePage(MyAnotherPage.class);
>>
>> But fine when use constructor:
>> setResponsePage(new MyAnotherPage());
>>
>> Is this a bug or not a bug?
>>
>> Regards,
>> uudashr
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
--
Pieter Degraeuwe
Systemworks bvba
Belgiëlaan 61
9070 Destelbergen
GSM: +32 (0)485/68.60.85
Email: pieter.degrae...@systemworks.be
visit us at http://www.systemworks.be
Handling Ajax session expired
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 a single "home page" i can transfer the user. This means that the session itself had some information on the specific environment the user was in. I can think of adding some information on the ajax link that will indicate that but again the exception happens at the wicket level and if I am handling the exception not sure how I can retrieve such data. Any good methodology here? Thanks, Arie
Re: Why feedback panel won't work
Hi,
feedback messages are tied to components they are reported for (the link
in your case).
Since this component isn't located on your response page, the message
will not be rendered.
Use Session#info() instead.
Regards
Sven
uud ashr wrote:
Hi all,
Why does wicket panel don't work if I do this:
class MyPage extends WebPage {
public MyPage() {
add(new Link("myLink") {
public void onClick() {
* info("You just click me");*
*setResponsePage(MyAnotherPage.class); // feedback panel
won't work*
}
});
}
}
class MyAnotherPage extends WebPage {
public MyAnotherPage() {
add(new FeedbackPanel("feedback"));
}
}
Won't work using:
setResponsePage(MyAnotherPage.class);
But fine when use constructor:
setResponsePage(new MyAnotherPage());
Is this a bug or not a bug?
Regards,
uudashr
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Java Wicket Job Opportunity, Finland
Sam Stainsby schrieb: Finland, Finland, Finland The country where I quite want to be! ^^^ Not the best job application I've seen :-) but a nice reference to monty python´s flying circus ;) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
