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

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 
thispage
- 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:10&wicket:ignoreIfNotActive=true&random=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.wic

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
> >  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
> > >>  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 
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:10&wicket:ignoreIfNotActive=true&random=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:10&random=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 wrote:

> 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
>  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:10&random=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.*StateProg

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 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
 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:10&random=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: (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  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.Standard

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
2-
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  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
>
>

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: 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:10&random=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)
>
>

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

2010-03-20 Thread Nikita Tovstoles 
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)

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 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 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.inv

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  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

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!

(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 
org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModel

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  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

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: 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

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: 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 
> 
>> Thank you for feedback. I used CSS positioning instead of tables, but it is
>> real pain :)
>> 
>> 
>> 
>> 
>> 
>> 
>> From: Daniel Toffetti 
>> To: users@wicket.apache.org
>> Sent: Thu, March 18, 2010 1:46:37 AM
>> Subject: Re: A web site developed with Wicket
>> 
>> voltron  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