Re: Nested modal windows

2010-10-03 Thread Martin Grigorov
See http://wicketstuff.org/wicket14/ajax/modal-window , the 'page' example

On Sat, Oct 2, 2010 at 11:55 AM, Chris Colman
chr...@stepaheadsoftware.comwrote:

 I use nested modal windows but I was wondering about how I should set
 those up in markup.

 Eg., say I have ModalWindow 0 and Modal Window 1. Modal Window 1 can
 open up on top of Modal Window 0 (nested modal)

 Should the markup refelect this nesting or doesn't it matter?

 Eg., should the markup be like:

 div wicket:id=modalWindow_0
div wicket:id=modalWindow_1
/div
 /div

 Or is it ok to be:

 div wicket:id=modalWindow_0 /
 div wicket:id=modalWindow_1 /




Re: Wicket 1.4.12 Ajax problems

2010-10-03 Thread Mathias Nilsson

I also tried 1.4.12 and got the same problem in chrome.


-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Wicket-1-4-12-Ajax-problems-tp2930684p2953070.html
Sent from the Users forum 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: Wicket 1.4.12 Ajax problems

2010-10-03 Thread Martin Grigorov
Did you try with 1.4.11 before trying 1.4.12 ?
Someone in IRC had the same problem - try 1.4.11, the browser caches the
broken wicket-ajax.js (see WICKET-3040) and then upgrade to 1.4.12 but the
browser still used the cached version from 1.4.11.

You said that you tried several browsers so maybe it is not the same case.
Many people use 1.4.12 and they don't experience this problem...

On Sun, Oct 3, 2010 at 12:32 PM, Mathias Nilsson 
wicket.program...@gmail.com wrote:


 I also tried 1.4.12 and got the same problem in chrome.


 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Wicket-1-4-12-Ajax-problems-tp2930684p2953070.html
 Sent from the Users forum 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: Wicket 1.5 and OSGi

2010-10-03 Thread Eike Kettner
Hi there,

Just a few updates from my side :

I recompiled wicket-trunk with changed a package structure and then my
application starts happily with wicket 1.5-M21. (by the way, I'm using
Apache Felix 3.0.2)

I now use the workaround of wrapping the wicket jars I need into one
jar. So it's no big deal to use wicket in OSGi as a wrapped jar, but
surely not as convienient as before.

Is anybody having these issues with wicket 1.5+OSGi, too? Or even
better, is anybody not having issues with this combination?

Regards,
Eike

On [Fri, 01.10.2010 22:12], Eike Kettner wrote:
 
 Hello again,
 
 I just had a look at the wicket packages of 1.4.12 and 1.5-M2.1 and I
 found some differences. For example, wicket 1.5 has a new artifact
 wicket-request and comparing the package structure there are some
 changes, which are probably related to my problem:
 
 wicket-1.4.12.jar:
 org.apache
 `-- wicket
 |-- authorization
 |   |-- Action.java
 |   |-- AuthorizationException.java
 |   |-- strategies
 |   |   |-- action
 |   |   |   |-- ActionAuthorizationStrategy.java
 |   |   |   `-- IActionAuthorizer.java
 |   |   |-- CompoundAuthorizationStrategy.java
 |   |   `-- page
 |   |   |-- AbstractPageAuthorizationStrategy.java
 |   |   `-- SimplePageAuthorizationStrategy.java
 |   |-- UnauthorizedActionException.java
 |   `-- UnauthorizedInstantiationException.java
 
 
 wicket-auth-roles-1.4.12.jar:
 org.apache
 `-- wicket
|-- authentication
|   |-- AuthenticatedWebApplication.java
|   |-- AuthenticatedWebSession.java
|   |-- pages
|   |   |-- SignInPage_fr.html
`-- authorization
`-- strategies
`-- role
|-- AbstractRoleAuthorizationStrategy.java
|   |-- ActionPermissions.java
`-- Roles.java
 
 This looks good to OSGi as the classes are in disjoint packages in the
 two bundles.
 
 
 This changed in 1.5. There the structure looks like this:
 
 wicket-1.5-M2.1.jar
 org.apache
 `-- wicket
 |-- authentication
 |   |-- IAuthenticationStrategy.java
 |   `-- strategy
 |   |-- DefaultAuthenticationStrategy.java
 |   `-- NoOpAuthenticationStrategy.java
 
 wicket-auth-roles-1.5-M2.1.jar
 org.apache
 `-- wicket
 |-- authentication
 |   |-- AuthenticatedWebApplication.java
 |   |-- AuthenticatedWebSession.java
 |   |-- pages
 |   |   |-- SignInPage.html
 |   |   |-- SignInPage.java
 
 
 The problem is the package org.apache.wicket.authentication now, because
 the bundle wicket-1.5-M2.1 and wicket-auth-roles-1.5-M2.1 provide
 classes from this package. The same refers to org.apache.wicket.request,
 which is exported by wicket-request and wicket in 1.5. This leads to
 problems in an OSGi environment. OSGi discourages those scenarios, but
 still offers an solution for this. A (rather old) blog post on osgi.org
 gives some hints on this:
 
 http://www.osgi.org/blog/2006/04/misconceptions-about-osgi-headers.html
 
 It probably gets to weird loading errors if two classes from the same
 package want to access each others fields or methods with package access,
 but come from a different classloader... 
 
 I'm no OSGi expert, so I don't know the right OSGi header that solves
 this. Of course, a real solution would be to only have disjoint packages
 :) I usually put the artifact name in my package name, to avoid any
 clashes (in fact it makes sense in my module structure).
 
 
 Kind regards,
 Eike
 
 
 On [Fri, 01.10.2010 10:05], Martin Grigorov wrote:
  Hi Elke,
  
  On Fri, Oct 1, 2010 at 8:34 AM, Eike Kettner n...@eknet.org wrote:
  
   Hello!
  
   I developed a wicket app using OSGi (felix) where different bundles may
   contribute content to the wicket bundle. It works really nice using
   wicket 1.4.9+. Now I want to upgrade to wicket 1.5 and I run in problems
   starting the osgi container.
  
   It complains with the good-known classnotfound-exception for classes
   like IClusterable and AuthenticatedWebapplication which all are classes
   in packages exported by more than one bundle (for example
   org.apache.wicket or org.apache.wicket.authentication). Earlier I found
   this was a problem or at least a not-good for OSGi bundles. But as am
   using OSGi 4.2 this may work with some special treatment (I'v never
   tried this though). Do you think I'm doing something wrong or is this
   something on the road for 1.5?
  
  I don't have much experience with OSGi so can you give more details what
  exactly is the problem  ?
  I think there is no difference in these two classes between 1.4.x and 1.5.x.
  They are packed the same way.
  There is no difference in the bnd-maven-plugin configuration as well.
  If you can find where the problem comes from then we can improve it.
  
  
   Also, since I have implemented ..UrlCodingStrategy and a custom
   RequestTarget I'm studying the new request handling in 1.5 sources to
   find out where to plugin my 

Re: Wicket 1.5 and OSGi

2010-10-03 Thread Martin Grigorov
Hi Elke,

As I said I don't use OSGi so I can say something that is against OSGi
rules, but here is what I'd do in your case:
create a Maven project (named for example 'wicket-bundle'), packaging type
'jar' and empty src/ folder. Then use maven-shade-plugin just to produce one
bigger .jar out of all required ones (wicket-util, wicket-request, wicket,
wicket-xyz, ...) and maven-bnd-plugin to add the OSGi stuff in
META-INF/MANIFEST.MF.

Since Wicket's artefacts are not splitted in -api and -impl .jars I don't
see a reason not to mix them all in one bigger jar for OSGi environments.

On Sun, Oct 3, 2010 at 1:48 PM, Eike Kettner n...@eknet.org wrote:

 Hi there,

 Just a few updates from my side :

 I recompiled wicket-trunk with changed a package structure and then my
 application starts happily with wicket 1.5-M21. (by the way, I'm using
 Apache Felix 3.0.2)

 I now use the workaround of wrapping the wicket jars I need into one
 jar. So it's no big deal to use wicket in OSGi as a wrapped jar, but
 surely not as convienient as before.

 Is anybody having these issues with wicket 1.5+OSGi, too? Or even
 better, is anybody not having issues with this combination?

 Regards,
 Eike

 On [Fri, 01.10.2010 22:12], Eike Kettner wrote:
 
  Hello again,
 
  I just had a look at the wicket packages of 1.4.12 and 1.5-M2.1 and I
  found some differences. For example, wicket 1.5 has a new artifact
  wicket-request and comparing the package structure there are some
  changes, which are probably related to my problem:
 
  wicket-1.4.12.jar:
  org.apache
  `-- wicket
  |-- authorization
  |   |-- Action.java
  |   |-- AuthorizationException.java
  |   |-- strategies
  |   |   |-- action
  |   |   |   |-- ActionAuthorizationStrategy.java
  |   |   |   `-- IActionAuthorizer.java
  |   |   |-- CompoundAuthorizationStrategy.java
  |   |   `-- page
  |   |   |-- AbstractPageAuthorizationStrategy.java
  |   |   `-- SimplePageAuthorizationStrategy.java
  |   |-- UnauthorizedActionException.java
  |   `-- UnauthorizedInstantiationException.java
 
 
  wicket-auth-roles-1.4.12.jar:
  org.apache
  `-- wicket
 |-- authentication
 |   |-- AuthenticatedWebApplication.java
 |   |-- AuthenticatedWebSession.java
 |   |-- pages
 |   |   |-- SignInPage_fr.html
 `-- authorization
 `-- strategies
 `-- role
 |-- AbstractRoleAuthorizationStrategy.java
 |   |-- ActionPermissions.java
 `-- Roles.java
 
  This looks good to OSGi as the classes are in disjoint packages in the
  two bundles.
 
 
  This changed in 1.5. There the structure looks like this:
 
  wicket-1.5-M2.1.jar
  org.apache
  `-- wicket
  |-- authentication
  |   |-- IAuthenticationStrategy.java
  |   `-- strategy
  |   |-- DefaultAuthenticationStrategy.java
  |   `-- NoOpAuthenticationStrategy.java
 
  wicket-auth-roles-1.5-M2.1.jar
  org.apache
  `-- wicket
  |-- authentication
  |   |-- AuthenticatedWebApplication.java
  |   |-- AuthenticatedWebSession.java
  |   |-- pages
  |   |   |-- SignInPage.html
  |   |   |-- SignInPage.java
 
 
  The problem is the package org.apache.wicket.authentication now, because
  the bundle wicket-1.5-M2.1 and wicket-auth-roles-1.5-M2.1 provide
  classes from this package. The same refers to org.apache.wicket.request,
  which is exported by wicket-request and wicket in 1.5. This leads to
  problems in an OSGi environment. OSGi discourages those scenarios, but
  still offers an solution for this. A (rather old) blog post on osgi.org
  gives some hints on this:
 
  http://www.osgi.org/blog/2006/04/misconceptions-about-osgi-headers.html
 
  It probably gets to weird loading errors if two classes from the same
  package want to access each others fields or methods with package access,
  but come from a different classloader...
 
  I'm no OSGi expert, so I don't know the right OSGi header that solves
  this. Of course, a real solution would be to only have disjoint packages
  :) I usually put the artifact name in my package name, to avoid any
  clashes (in fact it makes sense in my module structure).
 
 
  Kind regards,
  Eike
 
 
  On [Fri, 01.10.2010 10:05], Martin Grigorov wrote:
   Hi Elke,
  
   On Fri, Oct 1, 2010 at 8:34 AM, Eike Kettner n...@eknet.org wrote:
  
Hello!
   
I developed a wicket app using OSGi (felix) where different bundles
 may
contribute content to the wicket bundle. It works really nice using
wicket 1.4.9+. Now I want to upgrade to wicket 1.5 and I run in
 problems
starting the osgi container.
   
It complains with the good-known classnotfound-exception for classes
like IClusterable and AuthenticatedWebapplication which all are
 classes
in packages exported by more than one bundle (for example
org.apache.wicket or org.apache.wicket.authentication). Earlier I
 found
this was a problem or at 

Re: Wicket 1.5 and OSGi

2010-10-03 Thread Eike Kettner
Hi Martin

thanks for your advice. I didn't know the maven-shade-plugin, but I
create on big wicket jar containing all wicket jars like wicket-request,
wicket-xyz with pax:wrap-jar. This also works fine.

Just want to mention that with this change in wicket 1.5, wicket cannot
be used in OSGi environments as easiliy as wicket 1.4. One usually has
to create a wrapped jar somehow. Maybe this is worth to mention on the
migration guide wiki page?


On [Sun, 03.10.2010 13:59], Martin Grigorov wrote:
 Hi Elke,
 
 As I said I don't use OSGi so I can say something that is against OSGi
 rules, but here is what I'd do in your case:
 create a Maven project (named for example 'wicket-bundle'), packaging type
 'jar' and empty src/ folder. Then use maven-shade-plugin just to produce one
 bigger .jar out of all required ones (wicket-util, wicket-request, wicket,
 wicket-xyz, ...) and maven-bnd-plugin to add the OSGi stuff in
 META-INF/MANIFEST.MF.
 
 Since Wicket's artefacts are not splitted in -api and -impl .jars I don't
 see a reason not to mix them all in one bigger jar for OSGi environments.
 
 On Sun, Oct 3, 2010 at 1:48 PM, Eike Kettner n...@eknet.org wrote:
 
  Hi there,
 
  Just a few updates from my side :
 
  I recompiled wicket-trunk with changed a package structure and then my
  application starts happily with wicket 1.5-M21. (by the way, I'm using
  Apache Felix 3.0.2)
 
  I now use the workaround of wrapping the wicket jars I need into one
  jar. So it's no big deal to use wicket in OSGi as a wrapped jar, but
  surely not as convienient as before.
 
  Is anybody having these issues with wicket 1.5+OSGi, too? Or even
  better, is anybody not having issues with this combination?
 
  Regards,
  Eike
 
  On [Fri, 01.10.2010 22:12], Eike Kettner wrote:
  
   Hello again,
  
   I just had a look at the wicket packages of 1.4.12 and 1.5-M2.1 and I
   found some differences. For example, wicket 1.5 has a new artifact
   wicket-request and comparing the package structure there are some
   changes, which are probably related to my problem:
  
   wicket-1.4.12.jar:
   org.apache
   `-- wicket
   |-- authorization
   |   |-- Action.java
   |   |-- AuthorizationException.java
   |   |-- strategies
   |   |   |-- action
   |   |   |   |-- ActionAuthorizationStrategy.java
   |   |   |   `-- IActionAuthorizer.java
   |   |   |-- CompoundAuthorizationStrategy.java
   |   |   `-- page
   |   |   |-- AbstractPageAuthorizationStrategy.java
   |   |   `-- SimplePageAuthorizationStrategy.java
   |   |-- UnauthorizedActionException.java
   |   `-- UnauthorizedInstantiationException.java
  
  
   wicket-auth-roles-1.4.12.jar:
   org.apache
   `-- wicket
  |-- authentication
  |   |-- AuthenticatedWebApplication.java
  |   |-- AuthenticatedWebSession.java
  |   |-- pages
  |   |   |-- SignInPage_fr.html
  `-- authorization
  `-- strategies
  `-- role
  |-- AbstractRoleAuthorizationStrategy.java
  |   |-- ActionPermissions.java
  `-- Roles.java
  
   This looks good to OSGi as the classes are in disjoint packages in the
   two bundles.
  
  
   This changed in 1.5. There the structure looks like this:
  
   wicket-1.5-M2.1.jar
   org.apache
   `-- wicket
   |-- authentication
   |   |-- IAuthenticationStrategy.java
   |   `-- strategy
   |   |-- DefaultAuthenticationStrategy.java
   |   `-- NoOpAuthenticationStrategy.java
  
   wicket-auth-roles-1.5-M2.1.jar
   org.apache
   `-- wicket
   |-- authentication
   |   |-- AuthenticatedWebApplication.java
   |   |-- AuthenticatedWebSession.java
   |   |-- pages
   |   |   |-- SignInPage.html
   |   |   |-- SignInPage.java
  
  
   The problem is the package org.apache.wicket.authentication now, because
   the bundle wicket-1.5-M2.1 and wicket-auth-roles-1.5-M2.1 provide
   classes from this package. The same refers to org.apache.wicket.request,
   which is exported by wicket-request and wicket in 1.5. This leads to
   problems in an OSGi environment. OSGi discourages those scenarios, but
   still offers an solution for this. A (rather old) blog post on osgi.org
   gives some hints on this:
  
   http://www.osgi.org/blog/2006/04/misconceptions-about-osgi-headers.html
  
   It probably gets to weird loading errors if two classes from the same
   package want to access each others fields or methods with package access,
   but come from a different classloader...
  
   I'm no OSGi expert, so I don't know the right OSGi header that solves
   this. Of course, a real solution would be to only have disjoint packages
   :) I usually put the artifact name in my package name, to avoid any
   clashes (in fact it makes sense in my module structure).
  
  
   Kind regards,
   Eike
  
  
   On [Fri, 01.10.2010 10:05], Martin Grigorov wrote:
Hi Elke,
   
On Fri, Oct 1, 2010 at 8:34 AM, Eike 

Re: Wicket 1.5 and OSGi

2010-10-03 Thread Eike Kettner
Hi Martin

thanks for your advice. I didn't know the maven-shade-plugin, but I
create on big wicket jar containing all wicket jars like wicket-request,
wicket-xyz with pax:wrap-jar. This also works fine.

Just want to mention that with this change in wicket 1.5, wicket cannot
be used in OSGi environments as easiliy as wicket 1.4. One usually has
to create a wrapped jar somehow. Maybe this is worth to mention on the
migration guide wiki page?


On [Sun, 03.10.2010 13:59], Martin Grigorov wrote:
 Hi Elke,
 
 As I said I don't use OSGi so I can say something that is against OSGi
 rules, but here is what I'd do in your case:
 create a Maven project (named for example 'wicket-bundle'), packaging type
 'jar' and empty src/ folder. Then use maven-shade-plugin just to produce one
 bigger .jar out of all required ones (wicket-util, wicket-request, wicket,
 wicket-xyz, ...) and maven-bnd-plugin to add the OSGi stuff in
 META-INF/MANIFEST.MF.
 
 Since Wicket's artefacts are not splitted in -api and -impl .jars I don't
 see a reason not to mix them all in one bigger jar for OSGi environments.
 
 On Sun, Oct 3, 2010 at 1:48 PM, Eike Kettner n...@eknet.org wrote:
 
  Hi there,
 
  Just a few updates from my side :
 
  I recompiled wicket-trunk with changed a package structure and then my
  application starts happily with wicket 1.5-M21. (by the way, I'm using
  Apache Felix 3.0.2)
 
  I now use the workaround of wrapping the wicket jars I need into one
  jar. So it's no big deal to use wicket in OSGi as a wrapped jar, but
  surely not as convienient as before.
 
  Is anybody having these issues with wicket 1.5+OSGi, too? Or even
  better, is anybody not having issues with this combination?
 
  Regards,
  Eike
 
  On [Fri, 01.10.2010 22:12], Eike Kettner wrote:
  
   Hello again,
  
   I just had a look at the wicket packages of 1.4.12 and 1.5-M2.1 and I
   found some differences. For example, wicket 1.5 has a new artifact
   wicket-request and comparing the package structure there are some
   changes, which are probably related to my problem:
  
   wicket-1.4.12.jar:
   org.apache
   `-- wicket
   |-- authorization
   |   |-- Action.java
   |   |-- AuthorizationException.java
   |   |-- strategies
   |   |   |-- action
   |   |   |   |-- ActionAuthorizationStrategy.java
   |   |   |   `-- IActionAuthorizer.java
   |   |   |-- CompoundAuthorizationStrategy.java
   |   |   `-- page
   |   |   |-- AbstractPageAuthorizationStrategy.java
   |   |   `-- SimplePageAuthorizationStrategy.java
   |   |-- UnauthorizedActionException.java
   |   `-- UnauthorizedInstantiationException.java
  
  
   wicket-auth-roles-1.4.12.jar:
   org.apache
   `-- wicket
  |-- authentication
  |   |-- AuthenticatedWebApplication.java
  |   |-- AuthenticatedWebSession.java
  |   |-- pages
  |   |   |-- SignInPage_fr.html
  `-- authorization
  `-- strategies
  `-- role
  |-- AbstractRoleAuthorizationStrategy.java
  |   |-- ActionPermissions.java
  `-- Roles.java
  
   This looks good to OSGi as the classes are in disjoint packages in the
   two bundles.
  
  
   This changed in 1.5. There the structure looks like this:
  
   wicket-1.5-M2.1.jar
   org.apache
   `-- wicket
   |-- authentication
   |   |-- IAuthenticationStrategy.java
   |   `-- strategy
   |   |-- DefaultAuthenticationStrategy.java
   |   `-- NoOpAuthenticationStrategy.java
  
   wicket-auth-roles-1.5-M2.1.jar
   org.apache
   `-- wicket
   |-- authentication
   |   |-- AuthenticatedWebApplication.java
   |   |-- AuthenticatedWebSession.java
   |   |-- pages
   |   |   |-- SignInPage.html
   |   |   |-- SignInPage.java
  
  
   The problem is the package org.apache.wicket.authentication now, because
   the bundle wicket-1.5-M2.1 and wicket-auth-roles-1.5-M2.1 provide
   classes from this package. The same refers to org.apache.wicket.request,
   which is exported by wicket-request and wicket in 1.5. This leads to
   problems in an OSGi environment. OSGi discourages those scenarios, but
   still offers an solution for this. A (rather old) blog post on osgi.org
   gives some hints on this:
  
   http://www.osgi.org/blog/2006/04/misconceptions-about-osgi-headers.html
  
   It probably gets to weird loading errors if two classes from the same
   package want to access each others fields or methods with package access,
   but come from a different classloader...
  
   I'm no OSGi expert, so I don't know the right OSGi header that solves
   this. Of course, a real solution would be to only have disjoint packages
   :) I usually put the artifact name in my package name, to avoid any
   clashes (in fact it makes sense in my module structure).
  
  
   Kind regards,
   Eike
  
  
   On [Fri, 01.10.2010 10:05], Martin Grigorov wrote:
Hi Elke,
   
On Fri, Oct 1, 2010 at 8:34 AM, Eike 

Re: Wicket 1.5 and OSGi

2010-10-03 Thread Martin Grigorov
Hi Eike,

Please file a bug in Jira with link to this mail thread.

On Sun, Oct 3, 2010 at 2:33 PM, Eike Kettner e...@eknet.org wrote:

 Hi Martin

 thanks for your advice. I didn't know the maven-shade-plugin, but I
 create on big wicket jar containing all wicket jars like wicket-request,
 wicket-xyz with pax:wrap-jar. This also works fine.

 Just want to mention that with this change in wicket 1.5, wicket cannot
 be used in OSGi environments as easiliy as wicket 1.4. One usually has
 to create a wrapped jar somehow. Maybe this is worth to mention on the
 migration guide wiki page?


 On [Sun, 03.10.2010 13:59], Martin Grigorov wrote:
  Hi Elke,
 
  As I said I don't use OSGi so I can say something that is against OSGi
  rules, but here is what I'd do in your case:
  create a Maven project (named for example 'wicket-bundle'), packaging
 type
  'jar' and empty src/ folder. Then use maven-shade-plugin just to produce
 one
  bigger .jar out of all required ones (wicket-util, wicket-request,
 wicket,
  wicket-xyz, ...) and maven-bnd-plugin to add the OSGi stuff in
  META-INF/MANIFEST.MF.
 
  Since Wicket's artefacts are not splitted in -api and -impl .jars I don't
  see a reason not to mix them all in one bigger jar for OSGi environments.
 
  On Sun, Oct 3, 2010 at 1:48 PM, Eike Kettner n...@eknet.org wrote:
 
   Hi there,
  
   Just a few updates from my side :
  
   I recompiled wicket-trunk with changed a package structure and then my
   application starts happily with wicket 1.5-M21. (by the way, I'm using
   Apache Felix 3.0.2)
  
   I now use the workaround of wrapping the wicket jars I need into one
   jar. So it's no big deal to use wicket in OSGi as a wrapped jar, but
   surely not as convienient as before.
  
   Is anybody having these issues with wicket 1.5+OSGi, too? Or even
   better, is anybody not having issues with this combination?
  
   Regards,
   Eike
  
   On [Fri, 01.10.2010 22:12], Eike Kettner wrote:
   
Hello again,
   
I just had a look at the wicket packages of 1.4.12 and 1.5-M2.1 and I
found some differences. For example, wicket 1.5 has a new artifact
wicket-request and comparing the package structure there are some
changes, which are probably related to my problem:
   
wicket-1.4.12.jar:
org.apache
`-- wicket
|-- authorization
|   |-- Action.java
|   |-- AuthorizationException.java
|   |-- strategies
|   |   |-- action
|   |   |   |-- ActionAuthorizationStrategy.java
|   |   |   `-- IActionAuthorizer.java
|   |   |-- CompoundAuthorizationStrategy.java
|   |   `-- page
|   |   |-- AbstractPageAuthorizationStrategy.java
|   |   `-- SimplePageAuthorizationStrategy.java
|   |-- UnauthorizedActionException.java
|   `-- UnauthorizedInstantiationException.java
   
   
wicket-auth-roles-1.4.12.jar:
org.apache
`-- wicket
   |-- authentication
   |   |-- AuthenticatedWebApplication.java
   |   |-- AuthenticatedWebSession.java
   |   |-- pages
   |   |   |-- SignInPage_fr.html
   `-- authorization
   `-- strategies
   `-- role
   |-- AbstractRoleAuthorizationStrategy.java
   |   |-- ActionPermissions.java
   `-- Roles.java
   
This looks good to OSGi as the classes are in disjoint packages in
 the
two bundles.
   
   
This changed in 1.5. There the structure looks like this:
   
wicket-1.5-M2.1.jar
org.apache
`-- wicket
|-- authentication
|   |-- IAuthenticationStrategy.java
|   `-- strategy
|   |-- DefaultAuthenticationStrategy.java
|   `-- NoOpAuthenticationStrategy.java
   
wicket-auth-roles-1.5-M2.1.jar
org.apache
`-- wicket
|-- authentication
|   |-- AuthenticatedWebApplication.java
|   |-- AuthenticatedWebSession.java
|   |-- pages
|   |   |-- SignInPage.html
|   |   |-- SignInPage.java
   
   
The problem is the package org.apache.wicket.authentication now,
 because
the bundle wicket-1.5-M2.1 and wicket-auth-roles-1.5-M2.1 provide
classes from this package. The same refers to
 org.apache.wicket.request,
which is exported by wicket-request and wicket in 1.5. This leads to
problems in an OSGi environment. OSGi discourages those scenarios,
 but
still offers an solution for this. A (rather old) blog post on
 osgi.org
gives some hints on this:
   
   
 http://www.osgi.org/blog/2006/04/misconceptions-about-osgi-headers.html
   
It probably gets to weird loading errors if two classes from the same
package want to access each others fields or methods with package
 access,
but come from a different classloader...
   
I'm no OSGi expert, so I don't know the right OSGi header that solves
this. Of course, a real solution would be to only have disjoint
 packages
:) I 

Re: instantiate panels in a spring bean

2010-10-03 Thread Ben Tilford
What are you using to build the project? If your doing stub generation
(mixed java  groovy project) see if the stubs look right. There are a
few bugs in the stub generator when dealing with inner classes but it
shouldn't have compiled in that case.

On 10/2/10, fachhoch fachh...@gmail.com wrote:

 I added super for subclasses it still did not work , as I said it worked
 with
 java the same code when comming from .groovy should work right ?  if it is
 not do I have to give some special treatment for wicket groovy compoments ?
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/instantiate-panels-in-a-spring-bean-tp2946859p2952942.html
 Sent from the Users forum 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



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



Re: StatelessLink

2010-10-03 Thread Altuğ Bilgin Altıntaş
I found the problem (not solution yet)

Spring's AOP config  :

aop:config proxy-target-class=true
aop:aspect ref=loggingAspect
aop:pointcut id=daoPointcut
expression=execution(boolean org.jtpd.data..*(..)) /
aop:around pointcut-ref=daoPointcut method=logDaoMethod /
/aop:aspect
/aop:config

For logging and when i search logs i see :

org.apache.wicket.util.io.SerializableChecker$*
WicketNotSerializableException*: Unable to serialize class:
org.springframework.aop.aspectj.AspectJPointcutAdvisor

AspectJPointcutAdvisor can not serializable so StatelessLink doesn't work
and i always get Page Expired Error when exporting CSV file via using
WebResponse.

Any comment on that ?



2010/9/28 Igor Vaynberg igor.vaynb...@gmail.com

 even if the page is stateful, the url the stateless link generates
 should be stateless...got a quickstart?

 -igor

 On Tue, Sep 28, 2010 at 2:09 AM, Martin Grigorov mgrigo...@apache.org
 wrote:
  You may use wicket-devutils. There is a stateless checker. It will tell
 you
  which component makes the page stateful.
 
  2010/9/28 Altuğ Bilgin Altıntaş alt...@gmail.com
 
  Hi ;
 
  I used StatelessLink but i still get Page Expired , is it normal ?
 
  Also this StatelessLink is in StatelessForm and Page is Bookmarkable but
  wicket - 1.4.9 still generates :
 
 
 
 http://localhost:8080/ac/customer?wicket:interface=:1:frmSearch:linkExcel::ILinkListener
  ::
 
  why ?
 
  Thanks.
 
 

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




Re: StatelessLink

2010-10-03 Thread Jeremy Thomerson
Show your link code. You're obviously holding a reference to the aspect,
which can't be serialized.

Jeremy Thomerson
http://wickettraining.com
-- sent from my smart phone, so please excuse spelling, formatting, or
compiler errors

On Oct 3, 2010 2:16 PM, Altuğ Bilgin Altıntaş alt...@gmail.com wrote:

I found the problem (not solution yet)

Spring's AOP config  :

   aop:config proxy-target-class=true
   aop:aspect ref=loggingAspect
   aop:pointcut id=daoPointcut
   expression=execution(boolean org.jtpd.data..*(..)) /
   aop:around pointcut-ref=daoPointcut method=logDaoMethod /
   /aop:aspect
   /aop:config

For logging and when i search logs i see :

org.apache.wicket.util.io.SerializableChecker$*
WicketNotSerializableException*: Unable to serialize class:
org.springframework.aop.aspectj.AspectJPointcutAdvisor

AspectJPointcutAdvisor can not serializable so StatelessLink doesn't work
and i always get Page Expired Error when exporting CSV file via using
WebResponse.

Any comment on that ?



2010/9/28 Igor Vaynberg igor.vaynb...@gmail.com


 even if the page is stateful, the url the stateless link generates
 should be stateless...got a ...


Re: StatelessLink

2010-10-03 Thread Altuğ Bilgin Altıntaş
Problem occurs because of Spring integration; I called Service like that

final SupplierService supplierService = (SupplierService)
LazyInitProxyFactory.createProxy(SupplierService.class, new
IProxyTargetLocator() {
public Object locateProxyTarget() {
return ((WicketApplication) Application.get()).

getSpringContextLocator().getSpringContext().getBean(supplierService);

}
} );

Now It works.

I know i can use @SpringBean...

Thanks.

AOP trigerred when get

2010/10/3 Jeremy Thomerson jer...@wickettraining.com

 Show your link code. You're obviously holding a reference to the aspect,
 which can't be serialized.

 Jeremy Thomerson
 http://wickettraining.com
 -- sent from my smart phone, so please excuse spelling, formatting, or
 compiler errors

 On Oct 3, 2010 2:16 PM, Altuğ Bilgin Altıntaş alt...@gmail.com wrote:

 I found the problem (not solution yet)

 Spring's AOP config  :

   aop:config proxy-target-class=true
   aop:aspect ref=loggingAspect
   aop:pointcut id=daoPointcut
   expression=execution(boolean org.jtpd.data..*(..)) /
   aop:around pointcut-ref=daoPointcut method=logDaoMethod /
   /aop:aspect
   /aop:config

 For logging and when i search logs i see :

 org.apache.wicket.util.io.SerializableChecker$*
 WicketNotSerializableException*: Unable to serialize class:
 org.springframework.aop.aspectj.AspectJPointcutAdvisor

 AspectJPointcutAdvisor can not serializable so StatelessLink doesn't work
 and i always get Page Expired Error when exporting CSV file via using
 WebResponse.

 Any comment on that ?



 2010/9/28 Igor Vaynberg igor.vaynb...@gmail.com


  even if the page is stateful, the url the stateless link generates
  should be stateless...got a ...



Re: chrome + wicket ajax + back button = problem?

2010-10-03 Thread Ryan Crumley
What is interesting is this is not a wicket specific issue however it is
more serious when using wicket than other frameworks due to the expired
links causing errors when they reappear.

I created a very simple version of the problem. Chrome and IE8 exhibits the
problem but Firefox and Safari do not:

http://www.cupofcrumley.com/chrome-test/Page1.html

http://www.cupofcrumley.com/chrome-test/Page1.htmlRyan

On Fri, Sep 24, 2010 at 1:48 AM, Peter Karich peat...@yahoo.de wrote:

 I had the same problem ...
  Take a look at
 
 http://www.richardnichols.net/2010/03/apache-wicket-force-page-reload-to-fix-ajax-back/
 

 isn't there a better fix? E.g. it seems to me that this 'hack' avoids
 client-side js caching (or is this a wrong observation)?

 Regards,
 Peter.




 --
 http://jetwick.com twitter search prototype


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




Re: chrome + wicket ajax + back button = problem?

2010-10-03 Thread Zilvinas Vilutis
Yes, it is not repeatable on FF because FF does page caching which IE
does not for Back history.

Your page must be stateless on the server side.

Žilvinas Vilutis

Mobile:   (+370) 652 38353
E-mail:   cika...@gmail.com



On Sun, Oct 3, 2010 at 3:47 PM, Ryan Crumley crum...@gmail.com wrote:
 What is interesting is this is not a wicket specific issue however it is
 more serious when using wicket than other frameworks due to the expired
 links causing errors when they reappear.

 I created a very simple version of the problem. Chrome and IE8 exhibits the
 problem but Firefox and Safari do not:

 http://www.cupofcrumley.com/chrome-test/Page1.html

 http://www.cupofcrumley.com/chrome-test/Page1.htmlRyan

 On Fri, Sep 24, 2010 at 1:48 AM, Peter Karich peat...@yahoo.de wrote:

 I had the same problem ...
  Take a look at
 
 http://www.richardnichols.net/2010/03/apache-wicket-force-page-reload-to-fix-ajax-back/
 

 isn't there a better fix? E.g. it seems to me that this 'hack' avoids
 client-side js caching (or is this a wrong observation)?

 Regards,
 Peter.




 --
 http://jetwick.com twitter search prototype


 -
 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: instantiate panels in a spring bean

2010-10-03 Thread fachhoch

Actually this is groovy script, I load this using   spring lang tags


lang:groovy id=menuItems 
script-source=classpath:mypackage/UserMenuItems.groovy
/lang:groovy
 


please  help me.

-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/instantiate-panels-in-a-spring-bean-tp2946859p2953634.html
Sent from the Users forum 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: chrome + wicket ajax + back button = problem?

2010-10-03 Thread Ryan Crumley
Just to clarify:

The page in the example link I sent is stateless (it's static html). The
other point is that Chrome and IE do not fetch the original page on back
button click. They are serving the original html straight from the cache
(without the DOM modifications).

It sounds like the only fix is to update the page headers so that no
browser will ever cache the page. That seems like an overkill but so far I
haven't found any other solution that works across browsers. This seems like
a very common scenario... is it also very common to set all the no-cache
headers?

Ryan

On Sun, Oct 3, 2010 at 5:56 PM, Zilvinas Vilutis cika...@gmail.com wrote:

 Yes, it is not repeatable on FF because FF does page caching which IE
 does not for Back history.

 Your page must be stateless on the server side.

 Žilvinas Vilutis

 Mobile:   (+370) 652 38353
 E-mail:   cika...@gmail.com



 On Sun, Oct 3, 2010 at 3:47 PM, Ryan Crumley crum...@gmail.com wrote:
  What is interesting is this is not a wicket specific issue however it is
  more serious when using wicket than other frameworks due to the expired
  links causing errors when they reappear.
 
  I created a very simple version of the problem. Chrome and IE8 exhibits
 the
  problem but Firefox and Safari do not:
 
  http://www.cupofcrumley.com/chrome-test/Page1.html
 
  http://www.cupofcrumley.com/chrome-test/Page1.htmlRyan
 
  On Fri, Sep 24, 2010 at 1:48 AM, Peter Karich peat...@yahoo.de wrote:
 
  I had the same problem ...
   Take a look at
  
 
 http://www.richardnichols.net/2010/03/apache-wicket-force-page-reload-to-fix-ajax-back/
  
 
  isn't there a better fix? E.g. it seems to me that this 'hack' avoids
  client-side js caching (or is this a wrong observation)?
 
  Regards,
  Peter.
 
 
 
 
  --
  http://jetwick.com twitter search prototype
 
 
  -
  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




New App - Best Practices

2010-10-03 Thread Francisco Diaz Trepat - gmail
Hi I've tested wicket before it was in the apache incubator and found
it to be awesome, since then we have adopted it and I have been
migrating all legacy applications for my company for the last 3 years
aprox.

Now I have to build a small app to manage small accounting and
logistics for my wife's Business

She is opening a small printing shop for small business labels, such
as wine bottle labels, clothing labels, bags, etc.

At work I use wicket with an ingenious CORBA server, courtesy of the
legacy applications.

Now I am free to do whatever I want. This is the worst part. :-)

I would like to help out and test maybe wicket 1.5 and some good
database solution.

Can you share some comments or recommendations on what to do?
For Instance, I once read about Active Objects, I pretty much liked
the idea and built some prototypes, but now the site is exactly the
same and found their latest released is from 2008. So that is no so
edgy...

I don't wish to use hibernate, but could be some other object
relational mapping, even hibernate if you insist... :-)

So, ideas on what to use?

UI = Wicket.
+ 1.4?
+ 1.5?
middle layer?
Persistence?

Thanks in advance,
f(t)

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



Re: New App - Best Practices

2010-10-03 Thread Jeremy Thomerson

 So, ideas on what to use?

 UI = Wicket.
+ 1.4?
+ 1.5?
 middle layer?
 Persistence?


Wicket / Spring / Hibernate is a very common setup, so you will have an easy
time finding examples, help, etc.

-- 
Jeremy Thomerson
http://www.wickettraining.com


Re: New App - Best Practices

2010-10-03 Thread Sam Stainsby
On Sun, 03 Oct 2010 20:40:04 -0300, Francisco Diaz Trepat - gmail wrote:

 Now I am free to do whatever I want. This is the worst part. :-)

I understand that feeling! When I started designing our web app 
framework, I picked the technologies from an enormous set of options that 
I thought would make app development as rapid and robust as possible. The 
title of your message best practices suggests though that you want to 
stick to the mainstream solutions.

 So, ideas on what to use?

If you want to avoid ORMs completely, you could consider an object 
database like DB4O as we have in Granite. Granite is currently is not 
quite complete and poorly documented, and written Scala not Java, but 
there is surely something you can use there if you want to go down a that 
path - even if its just ideas and sample code.


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



RE: New App - Best Practices

2010-10-03 Thread Chris Colman
We use Wicket with DataNucleus (JDO) www.datanucleus.org as the
persistence layer. The persistence side is truly transparent and it
performs really well - your model objects don't need any extra methods
and you are free to model and code just as if you were dealing with an
'in memory' only set of objects.

We also use the 'Exposed Domain Model' pattern/strategy which is another
productivity boost over many of the other more traditional approaches to
persistence.

Regards,
Chris

-Original Message-
From: Francisco Diaz Trepat - gmail
[mailto:francisco.diaztre...@gmail.com]
Sent: Monday, 4 October 2010 10:40 AM
To: Wicket-Users
Subject: New App - Best Practices

Hi I've tested wicket before it was in the apache incubator and found
it to be awesome, since then we have adopted it and I have been
migrating all legacy applications for my company for the last 3 years
aprox.

Now I have to build a small app to manage small accounting and
logistics for my wife's Business

She is opening a small printing shop for small business labels, such
as wine bottle labels, clothing labels, bags, etc.

At work I use wicket with an ingenious CORBA server, courtesy of the
legacy applications.

Now I am free to do whatever I want. This is the worst part. :-)

I would like to help out and test maybe wicket 1.5 and some good
database solution.

Can you share some comments or recommendations on what to do?
For Instance, I once read about Active Objects, I pretty much liked
the idea and built some prototypes, but now the site is exactly the
same and found their latest released is from 2008. So that is no so
edgy...

I don't wish to use hibernate, but could be some other object
relational mapping, even hibernate if you insist... :-)

So, ideas on what to use?

UI = Wicket.
+ 1.4?
+ 1.5?
middle layer?
Persistence?

Thanks in advance,
f(t)

-
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: New App - Best Practices

2010-10-03 Thread Chris Colman

 So, ideas on what to use?

If you want to avoid ORMs completely, you could consider an object
database like DB4O as we have in Granite. Granite is currently is not
quite complete and poorly documented, and written Scala not Java, but
there is surely something you can use there if you want to go down a
that
path - even if its just ideas and sample code.

Forgot to mention: DataNucleus allows you to use a wide range of
datastores and switch between them without any code changes: eg., all
the usual RDBMSes (MySQL, Oracle etc.,), Object Databases (DB4O and some
others), Google Application Engine (GAE), LDAP, Excel plus loads more.
If you don't want to commit to an ORM/RDBMS then DN would provide that
level of protection against datastore 'lock in'.

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



Re: New App - Best Practices

2010-10-03 Thread 7zark7

There's no best practices any more :-)

Wicket/Spring/Hibernate is simple and lots of examples.
Hibernate with JPA is super-easy to work with.

If you want something different, NoSQL such as CouchDB is nice, 
especially if you need to store binary attachments, etc.


My current stack is Wicket/Spring/CouchDB using Scala - but the only 
100%, mathematically-proven to be superior technology in this is Wicket ;-)



On 10/3/10 4:40 PM, Francisco Diaz Trepat - gmail wrote:

Hi I've tested wicket before it was in the apache incubator and found
it to be awesome, since then we have adopted it and I have been
migrating all legacy applications for my company for the last 3 years
aprox.

Now I have to build a small app to manage small accounting and
logistics for my wife's Business

She is opening a small printing shop for small business labels, such
as wine bottle labels, clothing labels, bags, etc.

At work I use wicket with an ingenious CORBA server, courtesy of the
legacy applications.

Now I am free to do whatever I want. This is the worst part. :-)

I would like to help out and test maybe wicket 1.5 and some good
database solution.

Can you share some comments or recommendations on what to do?
For Instance, I once read about Active Objects, I pretty much liked
the idea and built some prototypes, but now the site is exactly the
same and found their latest released is from 2008. So that is no so
edgy...

I don't wish to use hibernate, but could be some other object
relational mapping, even hibernate if you insist... :-)

So, ideas on what to use?

UI = Wicket.
 + 1.4?
 + 1.5?
middle layer?
Persistence?

Thanks in advance,
f(t)

-
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: New App - Best Practices

2010-10-03 Thread Sam Stainsby
On Mon, 04 Oct 2010 11:36:48 +1000, Chris Colman wrote:


 Forgot to mention: DataNucleus allows you to use a wide range of
 datastores and switch between them without any code changes: eg., all
 the usual RDBMSes (MySQL, Oracle etc.,), Object Databases (DB4O and some
 others), Google Application Engine (GAE), LDAP, Excel plus loads more.
 If you don't want to commit to an ORM/RDBMS then DN would provide that
 level of protection against datastore 'lock in'.

Keep in mind though that adding a layer like this over DB4O will mostly 
remove the advantages that would make you want to choose DB4O in the 
first place.


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



Re: New App - Best Practices

2010-10-03 Thread Brian Topping
I personally use Wicket / Spring / JPA Hibernate / PostgreSQL.  Hibernate 
because I know how to tune it and I'm too busy learning other new technologies 
to focus on replacing one that is working for my needs now.  Spring because it 
helps immensely with unit testing and marginally by promoting good patterns 
(note these are two nice to have but not critical requirements for a small 
project).  I'd have to agree with the previous poster that Wicket is the one 
tried and true, money back guaranteed must have technology in the entire stack.

If you are just learning ORM for the first time, DataNucleus does look like a 
better way to go.

I would focus more on patterns and interfaces than on technologies.  Liberal 
use of patterns will keep your code honest and help you to refactor out or in 
technologies as necessary in the future.  Interfaces can always be extracted 
later, but having replaceable implementations are a huge benefit for migration 
between technologies.  You'll never get the perfect mix of technologies because 
they change all the time, but your application's domain focus will change very 
little.  The name of the game is to keep these realms as separate as possible.

One thing about Spring for a beginner is that you don't absolutely need it to 
get started with.  It's a big framework and it's core competency is dependency 
injection.  OTOH, the biggest thing it provides for small projects is a stable 
and well-maintained framework for database transactions.  If you want to use 
Spring, read the first chapter of the reference, skip to the database chapter, 
THEN skip back as necessary to fill in the gaps on how to set up the database.  
That's the fastest way to learn it.  Once you get started with it, the learning 
comes naturally.  If you use Spring, immediately learn the @SpringBean 
annotation in Wicket.

Good luck!

Brian

On Oct 3, 2010, at 7:40 PM, Francisco Diaz Trepat - gmail wrote:

 Hi I've tested wicket before it was in the apache incubator and found
 it to be awesome, since then we have adopted it and I have been
 migrating all legacy applications for my company for the last 3 years
 aprox.
 
 Now I have to build a small app to manage small accounting and
 logistics for my wife's Business
 
 She is opening a small printing shop for small business labels, such
 as wine bottle labels, clothing labels, bags, etc.
 
 At work I use wicket with an ingenious CORBA server, courtesy of the
 legacy applications.
 
 Now I am free to do whatever I want. This is the worst part. :-)
 
 I would like to help out and test maybe wicket 1.5 and some good
 database solution.
 
 Can you share some comments or recommendations on what to do?
 For Instance, I once read about Active Objects, I pretty much liked
 the idea and built some prototypes, but now the site is exactly the
 same and found their latest released is from 2008. So that is no so
 edgy...
 
 I don't wish to use hibernate, but could be some other object
 relational mapping, even hibernate if you insist... :-)
 
 So, ideas on what to use?
 
 UI = Wicket.
+ 1.4?
+ 1.5?
 middle layer?
 Persistence?
 
 Thanks in advance,
 f(t)
 
 -
 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



Rendering Html on Ajax Request

2010-10-03 Thread Gurpreet.Singh
Hi All,


I have some property define in property file like below

Myproperty.name = This is bbold/b

And on some Ajax request I am adding  this property to some label like this

add(new Label(somelable, getLocalizer().getString(Myproperty.name.))


My problem is , html  tags are rendered as text and  I am not getting bold 
effect or any Html formatting.


Hope someone know how to fix this.

Thanks





Re: Rendering Html on Ajax Request

2010-10-03 Thread Mauro Ciancio
Hello,
This could help you,
org.apache.wicket.Component#setEscapeModelStrings

That would disable the escape of strings.

Regards.

On Sun, Oct 3, 2010 at 11:21 PM,  gurpreet.si...@wellsfargo.com wrote:
 Hi All,


 I have some property define in property file like below

 Myproperty.name = This is bbold/b

 And on some Ajax request I am adding  this property to some label like this

 add(new Label(somelable, getLocalizer().getString(Myproperty.name.))


 My problem is , html  tags are rendered as text and  I am not getting bold 
 effect or any Html formatting.


 Hope someone know how to fix this.

 Thanks







-- 
Mauro Ciancio

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



RE: New App - Best Practices

2010-10-03 Thread Chris Colman
 Forgot to mention: DataNucleus allows you to use a wide range of
 datastores and switch between them without any code changes: eg., all
 the usual RDBMSes (MySQL, Oracle etc.,), Object Databases (DB4O and
some
 others), Google Application Engine (GAE), LDAP, Excel plus loads
more.
 If you don't want to commit to an ORM/RDBMS then DN would provide
that
 level of protection against datastore 'lock in'.

Keep in mind though that adding a layer like this over DB4O will mostly
remove the advantages that would make you want to choose DB4O in the
first place.

Not really AFAIK: The ability to not have to manage fetch depths that
JDO/DB40 gives you over raw DB40 gives you is a massive productivity
boost (not sure if the latest DB40 supports lazy loading or not yet). In
any case coding to a standard persistence interface (JDO) over a
proprietary API is IMHO an insurance policy I am prepared to invest in
given the performance overheads are so miniscule.

... but this is probably a discussion best held elsewhere... I think we
all agree in terms of UI frameworks Wicket is definitely the best there
is!

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



Re: JFreeChart with clickable imagemap

2010-10-03 Thread James
Dear all,

I've added a new wiki page JFreeChart with tooltip
examplehttps://cwiki.apache.org/confluence/display/WICKET/JFreeChart+with+tooltip+example,
which outlines the steps to follow to create JFreeChart based charts that
can display tooltips.

On Fri, Oct 1, 2010 at 3:05 PM, James james.eliye...@gmail.com wrote:

 Thanks Ernesto.
 I'll do the same.


 On Fri, Oct 1, 2010 at 2:24 PM, Ernesto Reinaldo Barreiro 
 reier...@gmail.com wrote:

 James,

 why not add this bit to the wiki page you mentioned? So that others
 can avoid loosing the hours you lost;-)

 Cheers,

 Ernesto

 On Fri, Oct 1, 2010 at 8:18 AM, James james.eliye...@gmail.com wrote:
  Guys,
 
  Finally managed to display the tooltip generated by JFreeChart in the
 wicket
  page by following these
  instructions
 http://markmail.org/message/r36cvdt2o3c4pki6#query:wicket%20jfreechart%20tooltips+page:1+mid:xqpnjdsj2lnkoinq+state:results
 
  .
  Had only an example markup been given in that post, it would have saved
 lots
  of frustrating hours I spent. :-(
 
  For anyone looking forward for showing the tooltips in a chart generated
 by
  JFreeChart, here is the markup you might need.
 
  code
 img wicket:id=chart usemap=#tooltip/img
  /code
 
  For the java part, use this
  code
 http://markmail.org/message/r36cvdt2o3c4pki6#query:wicket%20jfreechart%20tooltips+page:1+mid:xqpnjdsj2lnkoinq+state:results
 
  .
 
  Your output should look something like this..
 
  code
img wicket:id=chart usemap=#tooltip src=blah blah/img
map id=tooltip name=tooltip
 area/
/map
  /code
 
 
  NOTE:
 
   - You must use code img wicket:id=chart usemap=#tooltip/img
  /code and not code img wicket:id=chart usemap=#tooltip/
 /code
   - You must use the # symbol before the usemap id.
   - The image map related html markup is generated by the api provided by
  JFreeChart.
 
 
 
  On Fri, Oct 1, 2010 at 10:34 AM, James james.eliye...@gmail.com
 wrote:
 
  Hi Peter,
 
  Thanks for your prompt reply.
  I don't know how I missed this wonderful mailing list for this long..
 ;-(
 
  I have tried passing models to constructImageMap (wrapping the chart
 image
  object as a model) but somehow the map was not updated.
 
  I checked jetwick and it looks cool. ;-)
  Do you use JFreeChart to create those charts?
  I'm willing to try that option as well. Kindly blog about it!
 
  Thanks once again for taking your time to reply.
 
 
  On Thu, Sep 30, 2010 at 7:27 PM, Peter Karich peat...@yahoo.de
 wrote:
 
  Hi James,
 
  In the constructImageMap you whill have to pass a model as well, but
 I'm
  not sure how :-(
 
  Another way would be to adapt constructImageMap to updateImageMap
  so that you can call it in ChartImage.createBufferedImage (or every
 time
  the model updates)
 
  BTW: For jetwick I used an html solution with div's to display bar
 charts.
  which is customizable by the designer (if any ;-)), readable by
 spiders
  etc
  and didn't need those imagemaps. Are you interested in this solution?
 I
  could blog about it.
 
  Regards,
  Peter (aka timetabling on twitter ;-)).
 
   Hi Guys,
  
   I followed the instructions in the wiki JFreeChart with clickable
   imagemap
 
 https://cwiki.apache.org/WICKET/jfreechart-with-clickable-imagemap.html
   to create a chart.
   I have a requirement whereby the chart has to be generated
 dynamically
  based
   on certain inputs.
   I managed to create the chart image by using LoadableDetachableModel
 but
   struggling to get the imagemap updated as the chart image changes.
   Kindly give your valuable suggestions.
  
  
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
  --
  Thanks  Regards,
  James
 
 
 
 
  --
  Thanks  Regards,
  James
 

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




 --
 Thanks  Regards,
 James




-- 
Thanks  Regards,
James


Re: New App - Best Practices

2010-10-03 Thread Jeremy Thomerson
On Sun, Oct 3, 2010 at 9:17 PM, Brian Topping topp...@codehaus.org wrote:

 If you want to use Spring, read the first chapter of the reference, skip to
 the database chapter, THEN skip back as necessary to fill in the gaps on how
 to set up the database.  That's the fastest way to learn it.


I've worked with Brian on other projects, and he is very good with
architecture.  His advice here is sound. I would be curious just to be sure
- which reference in particular do you mean?

-- 
Jeremy Thomerson
http://www.wickettraining.com


Re: Rendering Html on Ajax Request

2010-10-03 Thread Jeremy Thomerson
Also, you should do this instead:

add(new Label(somelable, new StringResourceModel(your-string-key)))


On Sun, Oct 3, 2010 at 9:48 PM, Mauro Ciancio maurocian...@gmail.comwrote:

 Hello,
 This could help you,
 org.apache.wicket.Component#setEscapeModelStrings

 That would disable the escape of strings.

 Regards.

 On Sun, Oct 3, 2010 at 11:21 PM,  gurpreet.si...@wellsfargo.com wrote:
  Hi All,
 
 
  I have some property define in property file like below
 
  Myproperty.name = This is bbold/b
 
  And on some Ajax request I am adding  this property to some label like
 this
 
  add(new Label(somelable, getLocalizer().getString(Myproperty.name.))
 
 
  My problem is , html  tags are rendered as text and  I am not getting
 bold effect or any Html formatting.
 
 
  Hope someone know how to fix this.
 
  Thanks
 
 
 
 



 --
 Mauro Ciancio

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




-- 
Jeremy Thomerson
http://www.wickettraining.com


Re: New App - Best Practices

2010-10-03 Thread Brian Topping

On Oct 3, 2010, at 11:19 PM, Jeremy Thomerson wrote:

 On Sun, Oct 3, 2010 at 9:17 PM, Brian Topping topp...@codehaus.org wrote:
 
 If you want to use Spring, read the first chapter of the reference, skip to
 the database chapter, THEN skip back as necessary to fill in the gaps on how
 to set up the database.  That's the fastest way to learn it.
 
 
 I've worked with Brian on other projects, and he is very good with
 architecture.  His advice here is sound. I would be curious just to be sure
 - which reference in particular do you mean?

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/
 is what I use.  I'm not ashamed to say that I still use this page frequently, 
as I'm less about memorizing everything and more about knowing where to look 
something up fast.  

As I started to think about documentation, Wicket In Action is a must have.  
Spring In Action is probably just as good, the folks at Manning would rather 
throw away a manuscript than release a bad one, but I haven't read it.  The 
paper versions are great to take to a cafe, but definitely spend a few extra 
bucks on the PDF too.  It's more than worth the price of a couple of lattes!
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New App - Best Practices

2010-10-03 Thread James Carman
Make sure your Manning books don't already come with the free PDF version
before you spring (couldn't resist) for it.  When I get them from Amazon,
they sometimes come with an insert that allows you to download the PDF.
On Oct 3, 2010 11:35 PM, Brian Topping topp...@codehaus.org wrote:

 On Oct 3, 2010, at 11:19 PM, Jeremy Thomerson wrote:

 On Sun, Oct 3, 2010 at 9:17 PM, Brian Topping topp...@codehaus.org
wrote:

 If you want to use Spring, read the first chapter of the reference, skip
to
 the database chapter, THEN skip back as necessary to fill in the gaps on
how
 to set up the database. That's the fastest way to learn it.


 I've worked with Brian on other projects, and he is very good with
 architecture. His advice here is sound. I would be curious just to be
sure
 - which reference in particular do you mean?


http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/is
what I use. I'm not ashamed to say that I still use this page
frequently,
as I'm less about memorizing everything and more about knowing where to look
something up fast.

 As I started to think about documentation, Wicket In Action is a must
have. Spring In Action is probably just as good, the folks at Manning
would rather throw away a manuscript than release a bad one, but I haven't
read it. The paper versions are great to take to a cafe, but definitely
spend a few extra bucks on the PDF too. It's more than worth the price of a
couple of lattes!
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



Re: New App - Best Practices

2010-10-03 Thread Sam Stainsby
On Mon, 04 Oct 2010 12:59:43 +1000, Chris Colman wrote:

Keep in mind though that adding a layer like this over DB4O will mostly
remove the advantages that would make you want to choose DB4O in the
first place.
 
 Not really AFAIK: The ability to not have to manage fetch depths that
 JDO/DB40 gives you over raw DB40 gives you is a massive productivity
 boost (not sure if the latest DB40 supports lazy loading or not yet).

This is OT, but I feel it needs some correction.

DB4O has had transparent activation (automatic loading of references if/
when needed) and transparent persistence (automatic update depth) for a 
while now. You byte code can even be automatically instrumented with TA/TP
(but note code injection doesn't work with Scala, so we hand-code a few 
base relationship classes with TA instead).

You are missing out on the main goal of DB4O: simplicity - the ability to 
store and query POJOs with zero configuration, even POJOs from other 
database-unaware APIs.

You are also missing out on advantages like automatic schema updates, 
DB4O's own unique ID system, and other very useful parts of the DB4O API.

 In any case coding to a standard persistence interface (JDO) 
 over a proprietary API is IMHO an insurance policy

I can understand that, and I think that way too in some situations, but I 
reject the notion that there is no price to pay.


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



Re: New App - Best Practices

2010-10-03 Thread Brian Topping

On Oct 3, 2010, at 11:58 PM, Sam Stainsby wrote:

 In any case coding to a standard persistence interface (JDO) 
 over a proprietary API is IMHO an insurance policy
 
 I can understand that, and I think that way too in some situations, but I 
 reject the notion that there is no price to pay.

This is where the old Total Cost of Ownership comes in to play.  The right 
technology for a particular developer or team is going to be the one that 
allows the problem domain to be solved with the least cost.  

For some developers, a lack of documentation or online examples is might cost 
more in lost time than the additional cost of laboriously setting up JPA and 
all the requisite annotations.  For others, unlearning their old habits might 
be a huge cost.  In a team environment, change can lead to politics, another 
cost.  As a project grows to include a team, potential difficulty in hiring new 
staff that is receptive to the chosen technologies also needs to be considered 
briefly (Wicket itself had this issue until recently).

There's *always* a cost, but which one is cheapest (most efficient, easiest to 
use, yada yada) in the end depends on a lot of localized factors.  If it did 
not, there would be a website that every developer visited before starting a 
new project, and the anointed best technologies for that moment would be 
listed there.  Heck, you would be able check boxes on the list and generate a 
POM from it...

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



Re: instantiate panels in a spring bean

2010-10-03 Thread Arjun Dhar

May or may not be consequential, why is myInit not public? 
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/instantiate-panels-in-a-spring-bean-tp2946859p2953812.html
Sent from the Users forum 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