two LDM DropDownChoice behave differently ?

2010-03-20 Thread David Chang
Hello, 

I am playing Wicket now and came across this strange behavior.

I have a page with two LDM-based DropDownChoice (Country and State). The 
Country DDC ajax-controls the State DDC. The Ajax works well.

Here is something I dont understand. 

When the page is diplayed first time, both LDM#load get called. If dont play 
with the DDCs, and simply refresh the page, both LDM#load get called.

If I just select values in the Contry DDC without touch the State DDC (I can 
see State DDC values changes when Country DDC value change) and I referesh the 
page, only the Country LDM#load gets called.

What happened to State DDC? Shouldn't it's LDM#load gets called each time when 
page refereshes?

It is really puzzle to me. Googled, but no clue. I am pulling my hairs now...

Thanks for any help!!!

If I refresh page, I notice that Country State




  

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: A web site developed with Wicket

2010-03-20 Thread Peter Ertl
After using CSS for layout things for two years my summary is:

  Use tables for layout, CSS for the rest

It it simple, it works, and it doesn't break in each new version of IE

Am 18.03.2010 um 08:39 schrieb nino martinez wael:

 CSS are the way to do stuff, but usually IE smashes it somehow. My rule are
 to develop for firefox, patch for IE. And so far it's worked very well.
 
 However there are somethings that are really painfull todo with css. Like
 round corners, this is where I came up with wicketstuff artwork two
 integrations for js libs that helps making graphics like round corners.
 
 regards
 
 2010/3/18 voltron kocam...@yahoo.com
 
 Thank you for feedback. I used CSS positioning instead of tables, but it is
 real pain :)
 
 
 
 
 
 
 From: Daniel Toffetti dto...@yahoo.com.ar
 To: users@wicket.apache.org
 Sent: Thu, March 18, 2010 1:46:37 AM
 Subject: Re: A web site developed with Wicket
 
 voltron kocamane at yahoo.com writes:
 Hello,
 
 http://www.nofailtime.com/appmonitor is a web application
 developed with wicket framework.
 
 .
 
 I would be happy if you try the site and give feedback. You
 can login the site with account;
 username = demo
 password = demo
 
 Thanks,
 
   It looks great, I like specially the menu. Some panels (Login,
 Subscription
 Update) seem to be somewhat to the right of the screen, it would be better
 if
 they were centered.
   And I get a 1 centimeter wide vertical padding both to the left and to
 the
 right, don't know if this is intentional, it doesn't look good but perhaps
 it's
 just me.
   Could not crash it yet, tested with Firefox 3.6 / Windows XP on a 17
 CRT
 (non-wide format).
 
 Cheers,
 
 Daniel
 
 
 
 -
 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



jWicket 0.5.2

2010-03-20 Thread Stefan Lindner
I checked in jwicket 0.5.2 into wicketstuff/trunk. This fiexes an Ajax
update problem for input fields with DatePicker with button as trigger.
Looks like Ajax redraws of wicket components with jQuery behavior is
always a problem.

Stefan

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: jWicket 0.5.2

2010-03-20 Thread David Leangen


Hi,

What's the difference between jwicket and wiQuery?

Is it necessary to have 2 separate projects?

Just curious, because I'll soon be looking into better jQuery  
integration.



Thanks!
=David


On Mar 20, 2010, at 8:50 PM, Stefan Lindner wrote:


I checked in jwicket 0.5.2 into wicketstuff/trunk. This fiexes an Ajax
update problem for input fields with DatePicker with button as  
trigger.

Looks like Ajax redraws of wicket components with jQuery behavior is
always a problem.

Stefan

-
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



AW: jWicket 0.5.2

2010-03-20 Thread Stefan Lindner
Hi David,

take a look at both amd make your own decision. I can only speek for jWicket.
- At the moment it's main focus is drag/drop/resize. That's why I started this 
project.
- It trys to implement mostly all callback functions
- It trys to implement mostly all options
- It's part of wicketstuff
- It's easy to extend
- It's easy pluggable and unobtrusive.
- It's used as a core component in a commercial application
- jWicket trys to make the jQuery functionality fully accessible on the java 
side e.g. add Resizable to any wicket component and override onResized to 
re-act to a resize operation.

I suggest that you identify the jQuery components/functions that you need and 
then take a look at both libraries.
jWicket supports
- Drag/Drop
- Resize
- Effects
- Tooltips
- Datepicker

The next step will be a dropdown menu implementation.

But: take a look at wiQuery. Maybe it satisfys your needs much better.

Stefan

-Ursprüngliche Nachricht-
Von: David Leangen [mailto:wic...@leangen.net] 
Gesendet: Samstag, 20. März 2010 13:09
An: users@wicket.apache.org
Betreff: Re: jWicket 0.5.2


Hi,

What's the difference between jwicket and wiQuery?

Is it necessary to have 2 separate projects?

Just curious, because I'll soon be looking into better jQuery  
integration.


Thanks!
=David


On Mar 20, 2010, at 8:50 PM, Stefan Lindner wrote:

 I checked in jwicket 0.5.2 into wicketstuff/trunk. This fiexes an Ajax
 update problem for input fields with DatePicker with button as  
 trigger.
 Looks like Ajax redraws of wicket components with jQuery behavior is
 always a problem.

 Stefan

 -
 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: Help with integrating NTLM in wicket application

2010-03-20 Thread Josh Chappelle

Bryan,

I'm out of town right now but when I get back to my computer I will  
send you our ntlm page code. We have an AuthorizationStrategy that  
redirects the user to NTLMPage and it handles all the header stuff  
like you are talking about.  If I don't send it to you Sunday then  
email me to remind me.


Thanks,

Josh

Sent from my iPhone

On Mar 19, 2010, at 3:36 PM, Bryan Montgomery mo...@english.net wrote:


Hello,
I have two applications, one a stand alone web app and one wicket  
based.
Currently they both use form authentication however I am trying to  
add NTLM

authentication for SSO from our windows intranet.

Leveraging jcifs, I've been able to do this pretty easily with the  
stand
alone web app. However I've been struggling over the last couple of  
days

with the wicket app.

I'll preface this with the caveat that I have only done some very  
simple

stuff with wicket to date.

The flow is that the user makes a request and the program flow is  
redirected
to LoginPage, and in turn to LoginPanel. In LoginPanel the first  
thing it
does is check if there is an authentication header, if not which is  
the

case, it sets the status to SC_UNAUTHORIZED and adds a header of
WWW-Authenticate: NTLM. I then started with flushing the response  
and not

adding anything else.

In theory this response should tell the browser to resubmit the same  
request
with the authentication information. However, from our log files I  
can see
that the request second time around only has the Login in the  
request cycle,

compared to the startup page being in the request cycle initally.

After looking on the web I've tried various combinations including  
trying

continueToOriginalDestination in the onBeforeRender method.

One thing I've noticed is that it seems that setting the status and  
header

on the
((WebResponse)response).getHttpServletResponse() only takes effect  
when I do
not call flushBuffer() on it. This subseqently throws an exception  
in the

wicket processing because the response has already been closed.

I feel that I am so close - but can't quite get it right!

I was hoping to integrate this with minimal changes to the code but am
thinking that maybe I should start from scratch? I've found a few  
posts
online of similar situations but I haven't been able to put all the  
pieces

together yet.

Appreciate the help in getting this sorted out.

Thanks,
Bryan.

http://markmail.org/message/cjy4o4ndtigius55#query:+page:1+mid:t3foamferfh2twwj+state:results
http://old.nabble.com/Wicket-NTLM-Single-sign-on-integration-Question-td17868669.html


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



(Un-)deployment woes on Tomcat (and JBoss)

2010-03-20 Thread Alexandros Karypidis

Hi,

I'm having problems with deployment/undeployment of Wicket apps on 
Tomcat (and also JBoss, though I think it's related to the fact that it 
embeds Tomcat). Basically, in both cases undeployment comes back with an 
Exception, leaving the server in a dirty state and I have to restart 
the server every time. This has been mentioned in both the user and 
developer lists, but with no reply:


http://old.nabble.com/java.lang.NoClassDefFoundError:-org-apache-wicket-util-lang-PropertyResolver-tc26191924.html
http://old.nabble.com/Weird-error-on-shutdown...-td18907685.html

The problem manifests only when deploying EXPLODED wars (with a single 
packaged WAR file, the problem goes away). It can be easily reproduced 
as follows:


1) Create an instance of the quickstart archetype 
(http://wicket.apache.org/quickstart.html). Let's say you used the 
default values so the artifact id is myproject from here on. Use the 
latest 1.4.7 version of Wicket (though I've tried with all previous 
versions up to 1.4.4 and the result is the same; the reference above 
uses version 1.4-m2, so it must be surprisingly old).

2) Create an EXPLODED web archive (war) with mvn war:exploded
3) Move the exploded war folder (myproject-1.0-SNAPSHOT) to the 
deployment folder (server/xxx/deploy for JBoss or webapps)
4) Undeploy by moving the exploded war folder (myproject-1.0-SNAPSHOT), 
OUT of the deployment folder


You will get a stack trace that basically ends up in a ClassNotFound 
exception when the Wicket filter is cleaning up:


java.lang.NoClassDefFoundError: org/apache/wicket/util/lang/PropertyResolver
at org.apache.wicket.Application.internalDestroy(Application.java:952)
at 
org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:527)
at 
org.apache.wicket.protocol.http.WicketFilter.destroy(WicketFilter.java:179)
at 
org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:267)



This is a huge annoyance, because re-deployment of the application does 
not work; if you try to deploy it again, JBoss fails with:


org.jboss.deployers.spi.DeploymentException: Web mapping already exists 
for deployment URL 
file:/F:/ade_ws/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_(default)/deploy/myproject-1.0-SNAPSHOT/
at 
org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:187)


Basically, you must restart the entire JBoss server. In a production 
environment it means you can't upgrade your wicket applications without 
affecting other applications (though you can get away if you don't use 
an exploded WAR folder). In a developer environment it's totally 
counter-productive: you need the exploded format and restaring JBoss 
every time is quite irritating. The Eclipse WTP adapter runs in 
exploded mode which basically makes working with Eclipse a nightmare.


I am using JDK1.6 (I use 1.6.0_18) and either JBoss5.1 or Tomcat 6.0.26 
(or 6.0.18 or 5.5.28 which I also tried). My system is running Windows 7 
and NTFS (it may be relevant to the way the file-system handles moving 
folders).


Last notes:

1) I had a look at the code. It seems that Wicket tries to use weak 
references to facilitate a thorough clean-up of the JVM by garbage 
collection after the application is undeployed. This may be related, as 
it appears to me as if the class loader used by the application is no 
longer available during clean-up. I think there's some class-loading 
magic going on, probably the thread's context class loader is being 
switched, which ends up in the destroy() method not having access to wicket.


2) Jetty does not seem to have any problems, so it must be something in 
the way Tomcat works.


3) The complete stack trace in my case (Win7, JDK1.6.0_18-win32, 
JBoss5.1, Wicket1.4.7) is:

java.lang.NoClassDefFoundError: org/apache/wicket/util/lang/PropertyResolver
at org.apache.wicket.Application.internalDestroy(Application.java:952)
at 
org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:527)
at 
org.apache.wicket.protocol.http.WicketFilter.destroy(WicketFilter.java:179)
at 
org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:267)
at 
org.apache.catalina.core.StandardContext.filterStop(StandardContext.java:3818)
at 
org.apache.catalina.core.StandardContext.stop(StandardContext.java:4605)
at 
org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1175)
at 
org.apache.catalina.core.StandardContext.destroy(StandardContext.java:4705)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)
at 

Handling Composite Data Table Efficiently

2010-03-20 Thread rock stone
Hi,

I have implemented a data table with cells having components as TextFields,
Buttons etc.

Currently,I have been able to achieve this by enclosing them inside panels.

But with large data set to be displayed I think it might consume lot of UI
resources or rendering time.

Is there any other efficient way in which these components can be directly
embedded inside the Data Table.

Thanks!


Re: two LDM DropDownChoice behave differently ?

2010-03-20 Thread Igor Vaynberg
state's model is only loaded if the dropdown is rerendered (thats when
the model is needed)

see here http://wicketstuff.org/wicket14/ajax/choice

-igor

On Fri, Mar 19, 2010 at 11:21 PM, David Chang david_q_zh...@yahoo.com wrote:
 Hello,

 I am playing Wicket now and came across this strange behavior.

 I have a page with two LDM-based DropDownChoice (Country and State). The 
 Country DDC ajax-controls the State DDC. The Ajax works well.

 Here is something I dont understand.

 When the page is diplayed first time, both LDM#load get called. If dont play 
 with the DDCs, and simply refresh the page, both LDM#load get called.

 If I just select values in the Contry DDC without touch the State DDC (I can 
 see State DDC values changes when Country DDC value change) and I referesh 
 the page, only the Country LDM#load gets called.

 What happened to State DDC? Shouldn't it's LDM#load gets called each time 
 when page refereshes?

 It is really puzzle to me. Googled, but no clue. I am pulling my hairs now...

 Thanks for any help!!!

 If I refresh page, I notice that Country State






 -
 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: (Un-)deployment woes on Tomcat (and JBoss)

2010-03-20 Thread Pierre Goupil
I often have the same problem and symptom in my dev Tomcat, forcing me te
restart it.



On Sat, Mar 20, 2010 at 5:06 PM, Alexandros Karypidis akary...@yahoo.grwrote:

 Hi,

 I'm having problems with deployment/undeployment of Wicket apps on Tomcat
 (and also JBoss, though I think it's related to the fact that it embeds
 Tomcat). Basically, in both cases undeployment comes back with an Exception,
 leaving the server in a dirty state and I have to restart the server every
 time. This has been mentioned in both the user and developer lists, but with
 no reply:


 http://old.nabble.com/java.lang.NoClassDefFoundError:-org-apache-wicket-util-lang-PropertyResolver-tc26191924.html
 http://old.nabble.com/Weird-error-on-shutdown...-td18907685.html

 The problem manifests only when deploying EXPLODED wars (with a single
 packaged WAR file, the problem goes away). It can be easily reproduced as
 follows:

 1) Create an instance of the quickstart archetype (
 http://wicket.apache.org/quickstart.html). Let's say you used the default
 values so the artifact id is myproject from here on. Use the latest 1.4.7
 version of Wicket (though I've tried with all previous versions up to 1.4.4
 and the result is the same; the reference above uses version 1.4-m2, so it
 must be surprisingly old).
 2) Create an EXPLODED web archive (war) with mvn war:exploded
 3) Move the exploded war folder (myproject-1.0-SNAPSHOT) to the deployment
 folder (server/xxx/deploy for JBoss or webapps)
 4) Undeploy by moving the exploded war folder (myproject-1.0-SNAPSHOT), OUT
 of the deployment folder

 You will get a stack trace that basically ends up in a ClassNotFound
 exception when the Wicket filter is cleaning up:

 java.lang.NoClassDefFoundError:
 org/apache/wicket/util/lang/PropertyResolver
at org.apache.wicket.Application.internalDestroy(Application.java:952)
at
 org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:527)
at
 org.apache.wicket.protocol.http.WicketFilter.destroy(WicketFilter.java:179)
at
 org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:267)
 

 This is a huge annoyance, because re-deployment of the application does not
 work; if you try to deploy it again, JBoss fails with:

 org.jboss.deployers.spi.DeploymentException: Web mapping already exists for
 deployment URL
 file:/F:/ade_ws/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_(default)/deploy/myproject-1.0-SNAPSHOT/
at
 org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:187)

 Basically, you must restart the entire JBoss server. In a production
 environment it means you can't upgrade your wicket applications without
 affecting other applications (though you can get away if you don't use an
 exploded WAR folder). In a developer environment it's totally
 counter-productive: you need the exploded format and restaring JBoss every
 time is quite irritating. The Eclipse WTP adapter runs in exploded mode
 which basically makes working with Eclipse a nightmare.

 I am using JDK1.6 (I use 1.6.0_18) and either JBoss5.1 or Tomcat 6.0.26 (or
 6.0.18 or 5.5.28 which I also tried). My system is running Windows 7 and
 NTFS (it may be relevant to the way the file-system handles moving folders).

 Last notes:

 1) I had a look at the code. It seems that Wicket tries to use weak
 references to facilitate a thorough clean-up of the JVM by garbage
 collection after the application is undeployed. This may be related, as it
 appears to me as if the class loader used by the application is no longer
 available during clean-up. I think there's some class-loading magic going
 on, probably the thread's context class loader is being switched, which ends
 up in the destroy() method not having access to wicket.

 2) Jetty does not seem to have any problems, so it must be something in the
 way Tomcat works.

 3) The complete stack trace in my case (Win7, JDK1.6.0_18-win32, JBoss5.1,
 Wicket1.4.7) is:
 java.lang.NoClassDefFoundError:
 org/apache/wicket/util/lang/PropertyResolver
at org.apache.wicket.Application.internalDestroy(Application.java:952)
at
 org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:527)
at
 org.apache.wicket.protocol.http.WicketFilter.destroy(WicketFilter.java:179)
at
 org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:267)
at
 org.apache.catalina.core.StandardContext.filterStop(StandardContext.java:3818)
at
 org.apache.catalina.core.StandardContext.stop(StandardContext.java:4605)
at
 org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1175)
at
 org.apache.catalina.core.StandardContext.destroy(StandardContext.java:4705)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
 

Re: can intermittent 'illegal relative path' be cause by something besides broken session affinity?

2010-03-20 Thread Nikita Tovstoles
I wonder if this is a serialization problem:

the following request:

10.242.46.21 - - [20/Mar/2010:13:04:19 -0400] POST
/?wicket:interface=:0:EmbeddedCategoryCriteriaPanel:inputPanel:categorySearchForm:zipCodeComponent:zipCode::IBehaviorListener:1:10random=0.014624584217842351
HTTP/1.1 200 161


results in this exception:

Caused by: org.apache.wicket.WicketRuntimeException: component
EmbeddedCategoryCriteriaPanel:inputPanel:categorySearchForm:zipCodeComponent:zipCode
not found on page
com.castanealabs.gui.interactivemap.*StateProgramDetailsPage*[id = 0],
listener interface = [RequestListenerInterface name=IBehaviorListener,
method=public abstract void
org.apache.wicket.behavior.IBehaviorListener.onRequest()]
at 
org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:426)


The problem is, *StateProgramDetailsPage indeed does not contain a
EmbeddedCategoryCriteriaPanel in its' hierarchy. So why did wicket decide
that it does? The is another page class that does contain a
EmbeddedCategoryCriteriaPanel.
That class shares a concrete superclass with StateProgramDetailsPage class.
That superclass defines a serialVersionUID. *
*
*
*It appears that DiskPageStore is loading instance of the wrong page class.
Not sure why... could the fact that the classes share a common superclass
with a serialVersionUID  be the reason? Doubt it but have no other ideas at
the moment.*
*
*
*
*
Aside: Is there such a thing as an in-memory IPageStore impl (as a band-aid
at least...)

On Sat, Mar 20, 2010 at 10:11 AM, Nikita Tovstoles 
nikita.tovsto...@gmail.com wrote:

 We're suddenly seeing a fair number of exceptions like one below. Thought
 the root cause is failing session affinity in our clusters, but the
 exceptions persist even after we shut down all but one host behind HAProxy.
 I realize the question is somewhat ambiguous, but what - besides lack of
 session affinity - can be some other causes of these exceptions?

 thanks
 -nikita

 12:56:37,612 ERROR RequestCycle:1521 - submitted http post value [check3] for 
 CheckGroup component 
 [0:EmbeddedCategoryCriteriaPanel:inputPanel:categorySearchForm:brandsComponent:brands]
  contains an illegal relative path element [check3] which does not point to a 
 Check component. Due to this the CheckGroup component cannot resolve the 
 selected Check component pointed to by the illegal value. A possible reason 
 is that componment hierarchy changed between rendering and form submission.
 org.apache.wicket.WicketRuntimeException: submitted http post value [check3] 
 for CheckGroup component 
 [0:EmbeddedCategoryCriteriaPanel:inputPanel:categorySearchForm:brandsComponent:brands]
  contains an illegal relative path element [check3] which does not point to a 
 Check component. Due to this the CheckGroup component cannot resolve the 
 selected Check component pointed to by the illegal value. A possible reason 
 is that componment hierarchy changed between rendering and form submission.
   at 
 org.apache.wicket.markup.html.form.CheckGroup.convertValue(CheckGroup.java:136)
   at 
 org.apache.wicket.markup.html.form.CheckGroup.convertValue(CheckGroup.java:58)
   at 
 org.apache.wicket.markup.html.form.FormComponent.convertInput(FormComponent.java:1301)
   at 
 org.apache.wicket.markup.html.form.FormComponent.validate(FormComponent.java:1192)
   at org.apache.wicket.markup.html.form.Form$22.validate(Form.java:2132)
   at 
 org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent(Form.java:171)
   at 
 org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper(FormComponent.java:441)




jWicket 0.5.4

2010-03-20 Thread Stefan Lindner
jWicket 0.5.4 is released in wicketstuff/trunk and
wicketstuff/releases/1.4

I recomend to upgrade to this versioin as it fixes a serious bug in
drag/drop/resize. If someone needs pre-built jar files please let me
know.

Stefan

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: jWicket 0.5.4

2010-03-20 Thread Ernesto Reinaldo Barreiro
Hi Stefan,

Thanks for sharing!

Regarding the issue with drag-drop I just added [1] and [2]. I locally
patched my jquery to get it working but  this is something I do not like.
I'll keep you informed if someone provides an official fix.

Best,

Ernesto

References.

1-http://dev.jqueryui.com/ticket/5374
http://dev.jqueryui.com/ticket/53742-
http://forum.jquery.com/topic/drag-and-drop-problems-after-ajax-refresh-on-ie

http://forum.jquery.com/topic/drag-and-drop-problems-after-ajax-refresh-on-ie

On Sat, Mar 20, 2010 at 9:11 PM, Stefan Lindner lind...@visionet.de wrote:

 jWicket 0.5.4 is released in wicketstuff/trunk and
 wicketstuff/releases/1.4

 I recomend to upgrade to this versioin as it fixes a serious bug in
 drag/drop/resize. If someone needs pre-built jar files please let me
 know.

 Stefan

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: (Un-)deployment woes on Tomcat (and JBoss)

2010-03-20 Thread Igor Vaynberg
interesting, wonder why the class would be unloaded *before* the
application classloader.

try this, add a field private PropertyClassResolver resolver=null; to
your application subclass, see if the field is enough to stop the
class from unloading.

-igor

On Sat, Mar 20, 2010 at 9:06 AM, Alexandros Karypidis akary...@yahoo.gr wrote:
 Hi,

 I'm having problems with deployment/undeployment of Wicket apps on Tomcat
 (and also JBoss, though I think it's related to the fact that it embeds
 Tomcat). Basically, in both cases undeployment comes back with an Exception,
 leaving the server in a dirty state and I have to restart the server every
 time. This has been mentioned in both the user and developer lists, but with
 no reply:

 http://old.nabble.com/java.lang.NoClassDefFoundError:-org-apache-wicket-util-lang-PropertyResolver-tc26191924.html
 http://old.nabble.com/Weird-error-on-shutdown...-td18907685.html

 The problem manifests only when deploying EXPLODED wars (with a single
 packaged WAR file, the problem goes away). It can be easily reproduced as
 follows:

 1) Create an instance of the quickstart archetype
 (http://wicket.apache.org/quickstart.html). Let's say you used the default
 values so the artifact id is myproject from here on. Use the latest 1.4.7
 version of Wicket (though I've tried with all previous versions up to 1.4.4
 and the result is the same; the reference above uses version 1.4-m2, so it
 must be surprisingly old).
 2) Create an EXPLODED web archive (war) with mvn war:exploded
 3) Move the exploded war folder (myproject-1.0-SNAPSHOT) to the deployment
 folder (server/xxx/deploy for JBoss or webapps)
 4) Undeploy by moving the exploded war folder (myproject-1.0-SNAPSHOT), OUT
 of the deployment folder

 You will get a stack trace that basically ends up in a ClassNotFound
 exception when the Wicket filter is cleaning up:

 java.lang.NoClassDefFoundError: org/apache/wicket/util/lang/PropertyResolver
    at org.apache.wicket.Application.internalDestroy(Application.java:952)
    at
 org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:527)
    at
 org.apache.wicket.protocol.http.WicketFilter.destroy(WicketFilter.java:179)
    at
 org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:267)
 

 This is a huge annoyance, because re-deployment of the application does not
 work; if you try to deploy it again, JBoss fails with:

 org.jboss.deployers.spi.DeploymentException: Web mapping already exists for
 deployment URL
 file:/F:/ade_ws/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_(default)/deploy/myproject-1.0-SNAPSHOT/
    at
 org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:187)

 Basically, you must restart the entire JBoss server. In a production
 environment it means you can't upgrade your wicket applications without
 affecting other applications (though you can get away if you don't use an
 exploded WAR folder). In a developer environment it's totally
 counter-productive: you need the exploded format and restaring JBoss every
 time is quite irritating. The Eclipse WTP adapter runs in exploded mode
 which basically makes working with Eclipse a nightmare.

 I am using JDK1.6 (I use 1.6.0_18) and either JBoss5.1 or Tomcat 6.0.26 (or
 6.0.18 or 5.5.28 which I also tried). My system is running Windows 7 and
 NTFS (it may be relevant to the way the file-system handles moving folders).

 Last notes:

 1) I had a look at the code. It seems that Wicket tries to use weak
 references to facilitate a thorough clean-up of the JVM by garbage
 collection after the application is undeployed. This may be related, as it
 appears to me as if the class loader used by the application is no longer
 available during clean-up. I think there's some class-loading magic going
 on, probably the thread's context class loader is being switched, which ends
 up in the destroy() method not having access to wicket.

 2) Jetty does not seem to have any problems, so it must be something in the
 way Tomcat works.

 3) The complete stack trace in my case (Win7, JDK1.6.0_18-win32, JBoss5.1,
 Wicket1.4.7) is:
 java.lang.NoClassDefFoundError: org/apache/wicket/util/lang/PropertyResolver
    at org.apache.wicket.Application.internalDestroy(Application.java:952)
    at
 org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:527)
    at
 org.apache.wicket.protocol.http.WicketFilter.destroy(WicketFilter.java:179)
    at
 org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:267)
    at
 org.apache.catalina.core.StandardContext.filterStop(StandardContext.java:3818)
    at
 org.apache.catalina.core.StandardContext.stop(StandardContext.java:4605)
    at
 org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1175)
    at
 org.apache.catalina.core.StandardContext.destroy(StandardContext.java:4705)
    at 

Re: can intermittent 'illegal relative path' be cause by something besides broken session affinity?

2010-03-20 Thread Igor Vaynberg
i doubt its the diskstore since you are the only one seeing this problem.

is this happening on multiple pages or just a particular one?

-igor

On Sat, Mar 20, 2010 at 10:34 AM, Nikita Tovstoles
nikita.tovsto...@gmail.com wrote:
 I wonder if this is a serialization problem:

 the following request:

 10.242.46.21 - - [20/Mar/2010:13:04:19 -0400] POST
 /?wicket:interface=:0:EmbeddedCategoryCriteriaPanel:inputPanel:categorySearchForm:zipCodeComponent:zipCode::IBehaviorListener:1:10random=0.014624584217842351
 HTTP/1.1 200 161


 results in this exception:

 Caused by: org.apache.wicket.WicketRuntimeException: component
 EmbeddedCategoryCriteriaPanel:inputPanel:categorySearchForm:zipCodeComponent:zipCode
 not found on page
 com.castanealabs.gui.interactivemap.*StateProgramDetailsPage*[id = 0],
 listener interface = [RequestListenerInterface name=IBehaviorListener,
 method=public abstract void
 org.apache.wicket.behavior.IBehaviorListener.onRequest()]
        at 
 org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:426)


 The problem is, *StateProgramDetailsPage indeed does not contain a
 EmbeddedCategoryCriteriaPanel in its' hierarchy. So why did wicket decide
 that it does? The is another page class that does contain a
 EmbeddedCategoryCriteriaPanel.
 That class shares a concrete superclass with StateProgramDetailsPage class.
 That superclass defines a serialVersionUID. *
 *
 *
 *It appears that DiskPageStore is loading instance of the wrong page class.
 Not sure why... could the fact that the classes share a common superclass
 with a serialVersionUID  be the reason? Doubt it but have no other ideas at
 the moment.*
 *
 *
 *
 *
 Aside: Is there such a thing as an in-memory IPageStore impl (as a band-aid
 at least...)

 On Sat, Mar 20, 2010 at 10:11 AM, Nikita Tovstoles 
 nikita.tovsto...@gmail.com wrote:

 We're suddenly seeing a fair number of exceptions like one below. Thought
 the root cause is failing session affinity in our clusters, but the
 exceptions persist even after we shut down all but one host behind HAProxy.
 I realize the question is somewhat ambiguous, but what - besides lack of
 session affinity - can be some other causes of these exceptions?

 thanks
 -nikita

 12:56:37,612 ERROR RequestCycle:1521 - submitted http post value [check3] 
 for CheckGroup component 
 [0:EmbeddedCategoryCriteriaPanel:inputPanel:categorySearchForm:brandsComponent:brands]
  contains an illegal relative path element [check3] which does not point to 
 a Check component. Due to this the CheckGroup component cannot resolve the 
 selected Check component pointed to by the illegal value. A possible reason 
 is that componment hierarchy changed between rendering and form submission.
 org.apache.wicket.WicketRuntimeException: submitted http post value [check3] 
 for CheckGroup component 
 [0:EmbeddedCategoryCriteriaPanel:inputPanel:categorySearchForm:brandsComponent:brands]
  contains an illegal relative path element [check3] which does not point to 
 a Check component. Due to this the CheckGroup component cannot resolve the 
 selected Check component pointed to by the illegal value. A possible reason 
 is that componment hierarchy changed between rendering and form submission.
       at 
 org.apache.wicket.markup.html.form.CheckGroup.convertValue(CheckGroup.java:136)
       at 
 org.apache.wicket.markup.html.form.CheckGroup.convertValue(CheckGroup.java:58)
       at 
 org.apache.wicket.markup.html.form.FormComponent.convertInput(FormComponent.java:1301)
       at 
 org.apache.wicket.markup.html.form.FormComponent.validate(FormComponent.java:1192)
       at org.apache.wicket.markup.html.form.Form$22.validate(Form.java:2132)
       at 
 org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent(Form.java:171)
       at 
 org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper(FormComponent.java:441)




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Dynamic Image (aka Barcode) based on user input not refreshed via Ajax

2010-03-20 Thread Doug Leeper

Perfect!  Thanks!
-- 
View this message in context: 
http://old.nabble.com/Dynamic-Image-%28aka-Barcode%29-based-on-user-input-not-refreshed-via-Ajax-tp27961609p27972311.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: can intermittent 'illegal relative path' be cause by something besides broken session affinity?

2010-03-20 Thread Nikita Tovstoles
OK, here's what I can surmise thus far:

   - Only 'wicket:interface' JS requests - from 'onchange' Ajax validator or
   from a SubmitLink-initiated form submission trigger the exception
   - the form being submitted or validated is in a couple of pages but *never
   *in *StateProgramDetailsPage*
   - the exceptions thrown only cites *StateProgramDetailsPage*
   - pages are mounted using HybridURLCodingStrategy and have a common
   (concrete) super class
   - in all wicket:interface requests resulting in the exception: pageId =
   0; 'version' is always empty (thus wicket defaults to 0)

So, in summary, *sometimes* form component Ajax validation or non-Ajax form
submission wicket:interface POST requests results in retrieval of the
incorrect page - StateProgramDetailsPage - from PageMap. Consequently, the
exceptions are thrown. I would appreciate any general thoughts, but also
answers to these questions (to help us understand what goes on under the
hood):

   - What logs should we enable to see why an ajax wicket:interface from one
   page resolves to another page?
   - Does Wicket Ever manually write out JSESSIONID? In 'wicket:interface'
   requests specifically? or is that left up to the servlet container?
   - What is PageMap's scope - one per HttpSession?
   - What's 'urlDepth'?
   - What's the lifecycle of a IRequestCycleProcessor
   and IRequestCodingStrategy? Is newXXX called only once per app?
   - If we wanted to rule out DiskPageStore by installing an in-memory page
   store instead how can we do so? Implement own IPageStore?

*


*

*Request 1*
*

10.242.46.21 - - [20/Mar/2010:17:41:09 -0400] POST
/?wicket:interface=:0:EmbeddedCategoryCriteriaPanel:inputPanel:categorySearchForm:submitLink::IActivePageBehaviorListener:0:10wicket:ignoreIfNotActive=truerandom=0.04114457813227995
HTTP/1.1 200 161
http://rebatefinder.ecorebates.com/embedded/form/category/style/vertical/siteId/sears/adCell/W4/layout/vertical.0;jsessionid=9F0B9124A90DB552A38D2F8E6476F814;
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0;
GTB6.4; .NET CLR 1.1.4322)

Exception 1

Caused by: org.apache.wicket.WicketRuntimeException: component
EmbeddedCategoryCriteriaPanel:inputPanel:categorySearchForm:submitLink
not found on page
com.castanealabs.gui.interactivemap.StateProgramDetailsPage[id = 0],
listener interface = [RequestListenerInterface
name=IActivePageBehaviorListener, method=public abstract void
org.apache.wicket.behavior.IBehaviorListener.onRequest()]
at 
org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:426)
at 
org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:471)

Request 2

10.242.46.21 - - [20/Mar/2010:17:39:07 -0400] POST
/?wicket:interface=:0:EmbeddedCategoryCriteriaPanel:inputPanel:categorySearchForm:zipCodeComponent:zipCode::IBehaviorListener:1:10random=0.46530282930252486
HTTP/1.1 200 161
http://rebatefinder.ecorebates.com/embedded/form/category/style/vertical/siteId/sears/adCell/W4/layout/vertical.0;jsessionid=C767AD19F2AD165C8F4F7F00C337D385;
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0;
SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; msn
OptimizedIE8;ENUS)

Exception 2

*

Caused by: org.apache.wicket.WicketRuntimeException: component
EmbeddedCategoryCriteriaPanel:inputPanel:categorySearchForm:zipCodeComponent:zipCode
not found on page
com.castanealabs.gui.interactivemap.StateProgramDetailsPage[id = 0],
listener interface = [RequestListenerInterface name=IBehaviorListener,
method=public abstract void
org.apache.wicket.behavior.IBehaviorListener.onRequest()]
at 
org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:426)
at 
org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:471)
at 
org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:144)
... 21 more

On Sat, Mar 20, 2010 at 1:30 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 i doubt its the diskstore since you are the only one seeing this problem.

 is this happening on multiple pages or just a particular one?

 -igor

 On Sat, Mar 20, 2010 at 10:34 AM, Nikita Tovstoles
 nikita.tovsto...@gmail.com wrote:
  I wonder if this is a serialization problem:
 
  the following request:
 
  10.242.46.21 - - [20/Mar/2010:13:04:19 -0400] POST
 
 /?wicket:interface=:0:EmbeddedCategoryCriteriaPanel:inputPanel:categorySearchForm:zipCodeComponent:zipCode::IBehaviorListener:1:10random=0.014624584217842351
  HTTP/1.1 200 161
 
 
  results in this exception:
 
  Caused by: org.apache.wicket.WicketRuntimeException: component
 
 EmbeddedCategoryCriteriaPanel:inputPanel:categorySearchForm:zipCodeComponent:zipCode
  not found on page
  

Re: Don't increment the Session.pageIdCounter for stateless pages?

2010-03-20 Thread Martin Grotzke
What about using the @StatelessComponent (moving it from devutils into
wicket) as an indicator, that pages are intended to be stateless (_must_
be stateless)? Or introduce a new annotation @StatelessPage?

When a page that is intented to be stateless turns to be stateful, it's
always an issue (small or big one). Probably there are cases where pages
*should* be stateless and it doesn't really matter if they get stateful,
but there are also other cases, where pages *must* be stateless, e.g.
due to high load.

The @Stateless annotation would target the latter cases, where pages
*must* be stateless. And in this case, the pageIdCounter should also not
be modified.

What do you think?

Cheers,
Martin


On Sun, 2010-03-14 at 00:18 +0100, Martin Grotzke wrote:
 There are cases where pages are intended to be stateless (and might get
 annotated with @StatelessComponent). At least for these pages the page
 id should not be incremented, even if the session already has been
 bound.
 
 Cheers,
 Martin
 
 
 On Sat, 2010-03-13 at 22:58 +0100, Matej Knopp wrote:
  I'm not sure about all this.
  
  If the session has not been bound the page id will always be 0. If the
  session has been bound, I don't think we shouldn't increment page Id.
  Stateless page can became stateful any time, not incrementing the id
  can have sideeffects.
  
  -Matej
  
  On Sat, Mar 13, 2010 at 10:55 PM, Martin Grotzke
  martin.grot...@javakaffee.de wrote:
   Hi,
  
   just submitted this as
   https://issues.apache.org/jira/browse/WICKET-2782
  
   I tried incrementing the pageId when the page's numericId is first
   accessed, but soon realized, that this does happen rather often (also
   e.g. to construct bookmarkable page links) ;-) Seems to be not as easy
   as I thought. Still, it would be really cool if this could be
   implemented!
  
   Cheers,
   Martin
  
  
   On Wed, 2010-03-10 at 08:49 -0800, Igor Vaynberg wrote:
   i think we can do this in 1.5
  
   i would rather not mess with 1.4 because i think there is a lot of
   code there that depends on the fact that the id is available right
   away.
  
   please create a jira issue for this
  
   -igor
  
   On Mon, Mar 8, 2010 at 4:30 PM, Martin Grotzke
   martin.grot...@javakaffee.de wrote:
Hi,
   
the Page.init(PageMap) invokes setNextAvailableId(), which invokes
getSession().nextPageId() if isPageIdUniquePerSession is set.
   
getSession().nextPageId() modifies the Session.pageIdCounter.
   
When I have a session and afterwards access a stateless page, the
Session.pageIdCounter is the only data that is changed in the session
AFAICS, everything else is the same as in the request before.
   
Is it possible _not_ to modify the Session.pageIdCounter if the page is
really stateless (or just don't invoke Page.setNextAvailableId())?
   
I'm interested in this, as I'm just implementing a feature for the
memcached-session-manager ([1], memcached based session replication),
which checks if session data has changed and replicates sessions only 
if
this is provided. If session data did not change, the replication is
omitted. Therefore, if the Session.pageIdCounter would be left 
unchanged
for stateless pages, this would allow to make use of this feature in
wicket apps.
   
Thanx  cheers,
Martin
   
   
[1] http://code.google.com/p/memcached-session-manager/
   
   
   
  
   -
   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
  
 



signature.asc
Description: This is a digitally signed message part


Re: can intermittent 'illegal relative path' be cause by something besides broken session affinity?

2010-03-20 Thread Nikita Tovstoles
I may have found something - but first another question: under which
conditions would an ajax wicket:interface request omit a 'version'? (I see
request processor then assumes that the version is 0).

I may have found a race condition:

   - check out 
thishttp://www.sears.com/shc/s/nb_10153_12605_NB_EnergyStar+Program+Information?adCell=W4page
- observe that it has 2 iframes: a map on the left and a rebate search
   form on the right. both are served up from our servers (likely the same box)
   - tabbing out of the zipCode field issues a validation Ajax request; the
   submit button is actually a SubmitLink (i.e. also uses JS wicket:interface).
   - The StateProgramDetailsPage page mentioned in the exceptions is what
   you see when you click on a particular US state on the map - say NY


   - It's possible that the form on the right is the source of
   wicket:interface requests causing the exceptions

When a version-less wicket:interface request arrives (say, on tab-out from
zip code field) eventually SecondLevelCacheSessionStore.get(id, version)
gets called wherein we can fall through to a if-branch that picks *the last
page rendered*. I realize that id is generated atomically, so in theory the
following code should be safe, but it is curious that getLastPage() is
called 3 times (instead of being called once to init a local variable). So
I'd imagine it's possible that the map of the left sometimes gets rendered
later (say *after if (getLastPage() != null  getLastPage().getNumericId()
== id) is evaluated) and thus subsequent pages.put(id, page); then stores
the 'map' page with the 'form' page's id. No?*

String sessionId = getSession().getId();
if (sessionId != null)
{
if (getLastPage() != null  getLastPage().getNumericId() == id)
{
page = versionNumber != -1 ? getLastPage().getVersion(versionNumber)
: getLastPage();
if (page != null)
{
// ask the page store if it is ready saving the page.
getStore().pageAccessed(sessionId, page);
pages.put(id, page);
return page;
}
}

setLastPage(null);
page = getStore().getPage(sessionId, getName(), id, versionNumber, -1);
pages.put(id, page);
return page;

}

On Sat, Mar 20, 2010 at 3:53 PM, Nikita Tovstoles 
nikita.tovsto...@gmail.com wrote:

 OK, here's what I can surmise thus far:

- Only 'wicket:interface' JS requests - from 'onchange' Ajax validator
or from a SubmitLink-initiated form submission trigger the exception
- the form being submitted or validated is in a couple of pages but *never
*in *StateProgramDetailsPage*
- the exceptions thrown only cites *StateProgramDetailsPage*
- pages are mounted using HybridURLCodingStrategy and have a common
(concrete) super class
- in all wicket:interface requests resulting in the exception: pageId =
0; 'version' is always empty (thus wicket defaults to 0)

 So, in summary, *sometimes* form component Ajax validation or non-Ajax
 form submission wicket:interface POST requests results in retrieval of the
 incorrect page - StateProgramDetailsPage - from PageMap. Consequently, the
 exceptions are thrown. I would appreciate any general thoughts, but also
 answers to these questions (to help us understand what goes on under the
 hood):

- What logs should we enable to see why an ajax wicket:interface from
one page resolves to another page?
- Does Wicket Ever manually write out JSESSIONID? In 'wicket:interface'
requests specifically? or is that left up to the servlet container?
- What is PageMap's scope - one per HttpSession?
- What's 'urlDepth'?
- What's the lifecycle of a IRequestCycleProcessor
and IRequestCodingStrategy? Is newXXX called only once per app?
- If we wanted to rule out DiskPageStore by installing an in-memory
page store instead how can we do so? Implement own IPageStore?

 *


 *

 *Request 1*
 *

 10.242.46.21 - - [20/Mar/2010:17:41:09 -0400] POST 
 /?wicket:interface=:0:EmbeddedCategoryCriteriaPanel:inputPanel:categorySearchForm:submitLink::IActivePageBehaviorListener:0:10wicket:ignoreIfNotActive=truerandom=0.04114457813227995
  HTTP/1.1 200 161 
 http://rebatefinder.ecorebates.com/embedded/form/category/style/vertical/siteId/sears/adCell/W4/layout/vertical.0;jsessionid=9F0B9124A90DB552A38D2F8E6476F814;
  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; GTB6.4; 
 .NET CLR 1.1.4322)

 Exception 1

 Caused by: org.apache.wicket.WicketRuntimeException: component 
 EmbeddedCategoryCriteriaPanel:inputPanel:categorySearchForm:submitLink not 
 found on page com.castanealabs.gui.interactivemap.StateProgramDetailsPage[id 
 = 0], listener interface = [RequestListenerInterface 
 name=IActivePageBehaviorListener, method=public abstract void 
 org.apache.wicket.behavior.IBehaviorListener.onRequest()]
   at 
 org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:426)
   at 
 

Ajax has too much control?

2010-03-20 Thread David Chang

Forgive me about this meaningless subject, but I cannot think of a better one.

I have been learning Wicket through the WIA book. I just found out something 
interesting to me. Not sure it is a bug, design, or something I did wrong.

I have a page with three Wicket elements:

1. Locale selector through a DropDownChoice list. WIA has complete code about 
how this works and I copied the solution into this page

2. Country DropDownChoice, whose values change between English and Chinese 
depending on Locale DDC. 

3. State DropDownChoice, whose values change between English and Chinese 
depending on Locale DDC. The values in this DDC depends on the chosen value in 
Country DDC.

Here are the experiments

Experiment#1.

Country DDC does not control values in State DDC via Ajax and it has 

protected boolean wantOnSelectionChangedNotifications() {
  return true;
}

Everything works like a charm, which means 

(1) when Country DDC value changes, State DDC changes accodingly.
(2) when Locale changes, both Country DDC and State DDC lists change display 
values accordingly (which means both DDCs show a list of values in the same 
language).

Experiment#2.

Country DDC controls values in State DDC via Ajax. In this case, when page is 
first loaded, I do not touch the Country DDC or State DDC. I simply change 
locale value any number of times, both Country DDC and State DDC lists change 
correctly depending on the session locale. Here is the strange thing. Then I 
change Country DDC value, State DDC changes correctly. Since then, HOWEVER, if 
I change locale values, ONLY Country DDC list changes correctly; State DDC list 
is not updated. It seems Wicket decides that State DDC is forever 
Aja-controlled by Country DDC only.

Not qure sure if this a bug, design, or I did something wrong.

Please let me if you have difficulty understanding the experiments.

Thanks for any info or help.

Cheers!



  

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org