Re: Wicket libraries

2007-09-06 Thread David Bernard

Hi,

May be, a solution for your case would be to use ivy ant tasks to manage/list 
the dependencies of wicket. I don't use Ivy, but it could use maven's 
repositories and pom.xml.

I'm not sur it help you, because I don't use it, like lot of, I like maven 2 (dependencies and conventions), and more when I switch to a ant project where I need to read it to understand where are 
things, what are there scope (test, compile,...) finding the right jars when I try Seam one year ago was a headhache... but it's off topic.


/david

Robo wrote:

Hello,

Ok, seems removing \wicket-velocity-1.3.0-beta3.jar\ from build path solved 
problem with velocity problem. But please explain me why removing package from build path 
solves the problem if nowhere in my Hello World code i call for any of the velocity 
packages. Is there some duplicities in packages or what?

As to Maven2. It seems that like you in some way force developers to Maven2. :-) In wicket inAction EA there is just mentioned that when using Ant you need to do some work about libraries ant Maven manages it for you. This is too little for serious docs. Please do look into Icefaces free docs. There is steb by step mentioned what libs one need to enable which feature and the libs are added as demo app more feature ritch. Developer needs to understand core functionalities and dependencies. Just After understandig this developer is able to set up Ant project, make project, Eclipse or Netbeans based project and if you want also Maven. :-) But many of the advices about libs was \Use Maven2\ like. If you use it, so use it but do not force me to use it. Explain in some part od book or docs what do I need to run which part of wicket to save my time to go into jars and solve dependencies troubles. Yes Maven solves you some problems with dependecies and also si suitable for small 

pr

 oject but at big projects it definitely fails. :-/

So please. I know you have lot of work with wicket, and as users can see you 
have a good aproach. But please do spend some time to at least write one 
chapter about libraries, neede dependencies and so on. If you have licensing 
problems just make one clear site with core libs link, dep libs link and 
explanation what feature they are enabling and so on. And make some quick start 
page in which you explainn dependecies on simple sample app :-)Do not take 
alibistic aproach of hiding everithing besides Maven. :-)

Off topic section:
We use Maven for more than one year, also Maven2, in the begining there was 
some WoW`s about how Maven Manages project. Really great. But as the project 
continued and wee needed to add many not so standard feature to project, like 
advanced autorization, very non standard libraries we were forced in the 
troubles wchich could be avoided when there was no Maven2. also the project 
layout is not the best for our taste. IMHO of cource. Rewriting project build 
to ANT took us 6 days, but from that time we saved us a lot of time and nerves 
of solving Maven troubles. From that time we just developed, exactly what we 
were paid for. Idea of Maven2 is very nice and usefull, but implementation is 
kind of tragedy :-/. If I would Alayster Crowley I`d like Maven. Because its 
black magic, but I`m just dump developer who is not even to able to hypnotize 
someone :-)). as we talked about Ant and Maven2 we really realized the good 
sides of Maven. but Ant has simple basic idea with few bilding bl

oc

 ks, which when you combine them wiselly works perfectly. YOU do no need to 
study Ant. Just use it. In Maven  wee need to study Maven, Study black Magic 
without success. :-) It remainds me of one Joke. Americans was looking for some 
pen, which could be used in space without troubles, They invested 1 000 000 $ 
in research and finally had one. Russians in the meantime used pencils. :-) (If 
you do not like Russians just switch the roles ;-) )

So we found Maven2 usefull with small to mid project with some commonly used 
libraries but here it stops. Once you set up good dependencies in Ant you well 
understand what library you use and why (maven shields you from this in some 
way) and yuo are able to solve troubles with build system fast. We do not 
really to care about looking for jars in google. Using Maven it is not that 
time saving. It is more confortable I agree, but not worth the time to solve 
Maven troubles.

There is lot of buzz about \Convention over configuration\, But if that 
convention is badly designed, like Maven project layout, our aproach is flexibility over 
convention. (Jsp is convention but then came grrat wicket wchich is typical flexibility 
over convention, or good convention over bad convention :-) ). But reality besides Rails 
and Wicket I did not see any good convention (over configuration).

EnD of off topic: Uff ;-)
Robert


- Originálna Správa -
Od: Jonathan Locke  
Komu:  
Poslaná: 06.09.2007 04:07 
Predmet: Re: Wicket libraries




not only would the download be bigger, but 

Page state, undo and versioning?

2007-09-06 Thread wicket user
Hi,

My scenario is the following, I've got a page that allows a user to send an
sms to themselves every 20 seconds to a maximum of two times just incase
something in the network stopped the sms from getting to them in the first
place.

I have an ajax timer that enables the resend button after the specified time
and a count property of the page that stores the number of retries.

All works well and the button is disabled and enabled as expected in the
normal flow of events.

BUT when the user hits the back button after everything has been disabled
it's all enabled again, it's clearly to do with the undo ability of wicket
but no matter what I try I can't seemed to keep those components disabled on
an undo.

I've tried:

- setting the page to versioned/unversioned
- checking the page state onBeforeRendering and trying to set the value

What's really missing in my mind is a fundemental UNDERSTANDING of how this
works and how I deal with this problem. It seems such as simple thing but
I'm more then a little confused and starting to get irked.

So my questions (plural) are the following:
- where can I read more about what happens when the back button is hit?
- is there a way I can TEST this scenario with WicketTester?
- how do I keep that page in the same state on back being hit
- Maybe I'm tackling this the wrong way and I should be storing the state in
a session?

Thanks as always
Simon

ps. Wicket rocks, it's just my understanding that doesn't


Re: Twice Behavior on the same event handler (wicket 1.2.x)

2007-09-06 Thread Alex Objelean

I am curious, what is your use case for chaining behaviors? 
I think that if you have two things that you want to chain, then chain them
in the same handler, or use decorator to add the client-side code.

Alex


paolo di tommaso wrote:
 
 Carlos,
 
 Can you provide an example of your custom implementation of chained
 behaviour?
 
 
 Thanks, Paolo
 
 
 On 9/6/07, Carlos Pita [EMAIL PROTECTED] wrote:

  Currently people will have to build it in themselves like you did. We
  can investigate whether this can be improved for future versions, but

 From my own experience I wouldn't say that wicket should support this.
 It's too easy to write it yourself just to fit your specific needs,
 and otoh seems difficult to predict and support a significant number
 of possible use cases in a general way that keeps everyone happy, as
 you remarked.

 Regards,
 Carlos

 
  Eelco
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 

-- 
View this message in context: 
http://www.nabble.com/Twice-Behavior-on-the-same-event-handler-%28wicket-1.2.x%29-tf4386351.html#a12518265
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Strange bug in Wicket-1.3.0-beta2

2007-09-06 Thread Matej Knopp
You should try this with latest trunk. This should be fixed already,
but after beta 3.

-Matej

On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:

 When using wicket-1.3.0-beta3, still have the same problem.

 Here is again the stacktrace:

 org.apache.wicket.WicketRuntimeException: component
 body:panel:actionDetailsContainer:actionDetails:panel:pricesTabPanel:panel:tableContainer:pricesColumnContainer:pricesColumn:199
 not found on page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[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:394)
  at
 org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:440)
  at
 org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139)
  at org.apache.wicket.RequestCycle.step(RequestCycle.java:1091)
  at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1177)
  at org.apache.wicket.RequestCycle.request(RequestCycle.java:500)
  at
 org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:261)
  at
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:127)
  at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
  at
 org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
  at
 org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
 org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
 org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
 org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
 org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
  at
 org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
  at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  at
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
  at
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
  at
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
  at
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
  at
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
  at
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
  at
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
  at
 org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
  at
 org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
  at
 org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
  at
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
  at java.lang.Thread.run(Thread.java:595)


 igor.vaynberg wrote:
 
  try with latest trunk
 
  -igor
 
 
  On 8/15/07, Alex Objelean [EMAIL PROTECTED] wrote:
 
 
  I've got randomly an exception when clicking on the table row which has
  an
  AjaxEventBehavior assigned.
  Below is the stacktrace. Any ideas?
 
  [10:34:27.875] ERROR [http-8080-Processor1] RequestCycle - component
  body:panel:actionListContainer:actionList:form:actionList:14 not found on
  page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener
  interface = [RequestListenerInterface name=IBehaviorListener,
  method=public
  abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
  org.apache.wicket.WicketRuntimeException: component
  body:panel:actionListContainer:actionList:form:actionList:14 not found on
  page 

Re: Strange bug in Wicket-1.3.0-beta2

2007-09-06 Thread Alex Objelean

Right now, I do not know if this kind of issue can be fixed on the wicket
side. But what I do know for sure, is that this have to do with making
multiple ajax request which are scheduled by the Wicket.Channel and are
executed synchronously and which affects the DOM when the response is
arrived, thus the component tree is out of sync with the actual DOM. (For
instance user clicks 5 times on the Edit button, which is a slow operation
and its response change the component's DOM)

I am searching for workarounds for this issue. It is about preventing user
to make multiple request (blocking), but this is not that easy (God bless
IE).

Alex


Alex Objelean wrote:
 
 I've got randomly an exception when clicking on the table row which has an
 AjaxEventBehavior assigned.
 Below is the stacktrace. Any ideas?
 
 [10:34:27.875] ERROR [http-8080-Processor1] RequestCycle - component
 body:panel:actionListContainer:actionList:form:actionList:14 not found on
 page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener
 interface = [RequestListenerInterface name=IBehaviorListener,
 method=public abstract void
 org.apache.wicket.behavior.IBehaviorListener.onRequest()]
 org.apache.wicket.WicketRuntimeException: component
 body:panel:actionListContainer:actionList:form:actionList:14 not found on
 page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[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:394)
   at
 org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:440)
   at
 org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139)
   at org.apache.wicket.RequestCycle.step(RequestCycle.java:1090)
   at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1176)
   at org.apache.wicket.RequestCycle.request(RequestCycle.java:499)
   at
 org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:257)
   at
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:127)
   at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
   at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
   at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
   at
 org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
   at
 org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
   at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
   at
 org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
   at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
   at
 org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
   at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
   at
 org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
   at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
   at
 org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
   at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
   at
 org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
   at
 org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
   at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
   at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
   at
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
   at
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
   at
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
   at
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
   at
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
   at
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
   at
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
   at
 org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
   at
 

Re: JavaScript Frameworks

2007-09-06 Thread bmarvell

Sure i wanna do real programming in javascript.

My issue was, the back end devs here can tap away writing wicket but it wont
cover 100% of the interactions that are needed on the front end. So I hoped
that if wicked used a preferred JS framework for some of its widgets I could
save alot of overhead and go with that on the _other_ frontend interactions
i have to deal with.

Anyways, thanks for the help people.


Johan Compagner wrote:
 
 ahh so you want to do real programming in the javascript?
 So attaching purely in client side javascript events and those events call
 the server?
 
 Thats not how wicket works, in wicket you normally don't program
 javascript
 you get it pushed
 and the events get attached by the serverside.
 
 johan
 
 
 On 9/5/07, bmarvell [EMAIL PROTECTED] wrote:


 Sorry,

 Again mine is coming from a very front end perspective ie writing JS in a
 progressive enhancement style.

 Your pseudo code looks like the other end of the spectrum ie java code

 My main point over this thread was to also appreciate that while wicket
 is
 designed for java devs it needs to have JS framework code that can be
 used
 by UI developers.

 Hence why I believe having the ability to write things in a front end way
 is
 a GOOD thing.



 Nino Saturnino Martinez Vazquez Wael wrote:
 
  hmm I'll have to take a deeper look into this.
 
  The main idea about the input events are that you should be able to
 just
  add events of any sort (mouse, key, time?) to anycomponent that will
  either trigger that component or another, this means triggering from
  client to server. No real work has been done on the input events
 project
  other that the project are setup on the stuff svn, also some base
  infrastructure has been done.
 
  pseudo code example:
 
  form myform;
 
  label.add(new Event(Events.keypressed(a),Event.keydown, myform));
 
  above should trigger myform when a are pressed and label has focus.
 
  disclaimer : this might be bad example:)
 
  regards Nino
 
  bmarvell wrote:
  I personally think a CSS DOM traversal/manipulation model that can tie
 to
  events elegantly is what's needed.
 
  i.e:
 
  http://jquery.com
 
  http://bennolan.com/behaviour/
 
  Being able to say:
 
  $(#somthing li).click(.
 
  Is so much easier to code and read than:
 
  document.getElementById
 (something).getElementsByTagName(li)..
 
 
  Nino Saturnino Martinez Vazquez Wael wrote:
 
  on the Events part I might aswell go on with the input events
 contrib...
  As this now has been up a lot of times one the mailing list..
 
  I might seem to find some time to do it..
 
  But it would be really nice to see what people would like of features
  from it?
 
  regards Nino
 
  bmarvell wrote:
 
  Right then so for completeness:
 
  * Ajax Calls [In house]
  * Animation [animator.js]
  * Dom manipulation and traversal (CSS style for this is becoming
 highly
  favourable) [??]
  * Events [??]
 
  Has any of this been addressed or considered yet?
 
  I'm just coming in from the point of a front end developer and
 trying
  to
  identify whats either missing or I cant find :confused:
 
 
 
 
  Gerolf Seitz wrote:
 
 
  So for those specific issues are we to say:
 
 
 
 http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/
 
  Is the future??
 
 
  in this case, take a look at
 
 http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-animator
  ;)
 
  gerolf
 
  Matej Knopp-2 wrote:
 
 
  Hi,
 
  this question has been asked here numerous times. The thing is,
  there
  is in fact no real alternative of wicket-ajax for us.
 
  Wicket is not built about Ajax widgets.Wicket is about
 server-side
  components that can be partially updated using Ajax. That's a
  fundamental difference.
 
  As for the features, wicket-ajax has numerous advanced features
 such
  as
   - asynchronous pipeline that allows loading dependencies in
  asynchronous way, yet respecting the order (unlike e.g. dojo
 where
  the
  depending javascript are loaded using synchronous http requests
  which
  block entire browser = usability disaster)
  - ajax channels that allow you to stack or drop pending requests
  - multipart ajax response for replacing multiple components in
 one
  response, ajax header contribution processing (so that component
 can
  render header response as it would normally do, wicket
 transparently
  processes it and loads all dependencies (javascript references,
  stylesheets, etc) in an asynchronous way while respecting the
 order)
  - wicket-ajax.js is about 7kb compressed (with stripped down
  comments). As this is a general purpose ajax framework, the size
  matters. For sites where you using ajax only on certain places,
  having
  a 200kb javascript dependency would be quite a burden
  - there's more to it, the code is quite well documented, if you
 are
  interested you can dig into it, also you should search achives,
 this
  has been discussed here already.
 
  -Matej
 
 
  On 9/5/07, 

Re: Tracking down an elusive error during migration to 1.3

2007-09-06 Thread Johan Compagner
not the case that David has..
If i write a test case for the ValueMap and i get and put username in it
everything works.
Ofcourse if i set the debug logging level then i get a debug warning because
we do log there when
we couldn't find a get or a is property method..

johan


On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:

 you wrote it! :)

 -igor


 On 9/5/07, Johan Compagner [EMAIL PROTECTED] wrote:
 
  is also something really going wrong??
 
  because 501 is this:
 
  try
  {
  method = clz.getMethod(is + name, null);
  
  }
  catch (Exception e)
  {
  log.debug(Cannot find getter  + clz + . +
 expression,
  e);
  }
 
  we try to TEST if we can find it, and then do a debug log if we still
  can't
  find it
  after that we will see that it is a map and fallback on that.
 
  johan
 
 
  On 9/5/07, David Leangen [EMAIL PROTECTED] wrote:
  
  
   Migrating from 1.2 to 1.3.
  
   I've been trying to track down the cause of the following error.
  
   Since this is using reflection, I'm not getting any useful line
 numbers
   or direct information on the cause.
  
  
   If anybody can shed some light on this for me, I'd really appreciate
 it!
  
   All I know is that it happens at render time when visiting one of the
   components, but it's difficult to find the exact component.
  
  
  
   java.lang.NoSuchMethodException:
   org.apache.wicket.util.value.ValueMap.isUsername()
   at java.lang.Class.getMethod(Class.java:1581)
   at
   org.apache.wicket.util.lang.PropertyResolver.findGetter(
   PropertyResolver.java:501)
   at
   org.apache.wicket.util.lang.PropertyResolver.getGetAndSetter(
   PropertyResolver.java:317)
  
   ...
  
  
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 



Re: Page state, undo and versioning?

2007-09-06 Thread Gwyn Evans
On Thursday, September 6, 2007, 9:12:32 AM, wicket [EMAIL PROTECTED] wrote:

 My scenario is the following, I've got a page that allows a user to send an
 sms to themselves every 20 seconds to a maximum of two times just incase
 something in the network stopped the sms from getting to them in the first
 place.

[Offtopic] Does that actually work, as my expectation/experience would
suggest that you'll either get two SMs or none?

/Gwyn


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Progressive Enhancement

2007-09-06 Thread bmarvell

Guys,

While I'm ruffling the wicket feathers I thought I'd ask about about another
issue that's been bothering me with wicket.

From what I can see you either have the option of using AJAX or not. This is
all well and good but they seem like very forked approaches. So what I'm
trying to say is has there been any thought into taking a progressive
enhancement approach?

Taking that approach would mean pages that were ajax would work if the the
user disabled javascript or not. Not to mention a whole wealth of other
benefits that can be found here...

http://en.wikipedia.org/wiki/Progressive_enhancement

Just a question/thought don't flame me ;)
-- 
View this message in context: 
http://www.nabble.com/Progressive-Enhancement-tf4390623.html#a12518275
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Re: Wicket libraries stack trace

2007-09-06 Thread Robo
Hello Gwyn,

So after I put wicket-velocity jar in my build path, I`m getting following 
errors. (I`m using nothing from it and the prove is when I remove it it deploys 
OK.)
---6.9.2007 11:37:21 org.apache.catalina.core.StandardContext filterStart
SEVERE: Exception starting filter HelloWorldApplication
java.lang.NoClassDefFoundError: org/apache/velocity/app/Velocity
at org.apache.wicket.velocity.Initializer.init(Initializer.java:64)
at org.apache.wicket.Application.callInitializers(Application.java:808)
at 
org.apache.wicket.Application.initializeComponents(Application.java:638)
at 
org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:423)
at 
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275)
at 
org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397)
at 
org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:108)
at 
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3693)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4340)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at 
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626)
at 
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553)
at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at 
org.apache.catalina.core.StandardService.start(StandardService.java:516)
at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:566)
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.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
6.9.2007 11:37:25 org.apache.catalina.core.StandardContext filterStart
SEVERE: Exception starting filter HelloWorldApplication
java.lang.NoClassDefFoundError: org/apache/velocity/app/Velocity
at org.apache.wicket.velocity.Initializer.init(Initializer.java:64)
at org.apache.wicket.Application.callInitializers(Application.java:808)
at 
org.apache.wicket.Application.initializeComponents(Application.java:638)
at 
org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:423)
at 
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275)
at 
org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397)
at 
org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:108)
at 
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3693)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4340)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at 
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626)
at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:511)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1220)
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(BaseModelMBean.java:297)
at 

Re: Wicket validation flaw?

2007-09-06 Thread Matej Knopp
I thought we were trimming textfield strings, but now i see it's no
longer the case. Is it a regression or a feature?

Also the missing message doesn't make much sense, can you please
report a JIRA issue and attach a quick start project?

-Matej

On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:

 I've discovered the following issue:
 When using a DateTextField in a form (with the format: dd/MM/), user by
 mistake add an extra space (for instance: 06/09/2007 ) and submit the
 form. The are two problems:

 1) I would expect the convertor to convert this value correct, but the
 AbstractConverter.parse method throws a ConversionException because:
 (position.getIndex() != stringValue.length())

 2) The above exception is not reported anywhere, because validate method
 does not check if the input is valid after converting its value:



public final void validate()
{
validateRequired();
if (isValid())
{
convertInput();
 
if (isValid()  isRequired()  getConvertedInput() 
  == null 
  isInputNullable())
{
reportRequiredError();
}
  /*isn't something like this missing here?*/ if
  (!isValid()) { /*report Conversion error*/ }
if (isValid())
{
validateValidators();
}
}
}
 

 Any thoughts?

 Thank you!
 Alex.
 --
 View this message in context: 
 http://www.nabble.com/Wicket-validation-flaw--tf4390183.html#a12517215
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Wicket libraries stack trace

2007-09-06 Thread Gwyn Evans
On Thursday, September 6, 2007, 9:52:46 AM, Robo [EMAIL PROTECTED] wrote:

 So after I put wicket-velocity jar in my build path, I`m getting
 following errors. (I`m using nothing from it and the prove is
 when I remove it it deploys OK.)
...
 So please explain me why Tomcat is complaining at deployment time
 about velocity just including it in the build path?

What's happening is that the Wicket Application instance has searched
the classpath to read all the wicket.properties files provided. The
one in the wicket-velocity jar says
initializer=org.apache.wicket.velocity.Initializer, so it's trying
to run that initializer instance, but you're missing the dependances.

If using Maven, you'd have them, but if not, you can go to
MvnRepository (http://mvnrepository.com/) and search which would take
you to http://mvnrepository.com/artifact/velocity/velocity/1.4 where
it shows that you need velocity-dep-1.4.jar too.

That's a useful site to bookmark, whether using Maven or not (probably
even more if not!)

/Gwyn


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Strange bug in Wicket-1.3.0-beta2

2007-09-06 Thread Alex Objelean

Thank you very much Matej! To be honest, I didn't expected to have such a
prompt response. :)

Btw, when beta-4 is out?

Alex.


Matej Knopp-2 wrote:
 
 Yes, I know what's causing it. And as I said, this should be already
 taken care of. I've added a special precondition evaluated right
 before each scheduled ajax request to check if the originating DOM
 element is still in the document.
 
 -Matej
 
 On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:

 Right now, I do not know if this kind of issue can be fixed on the wicket
 side. But what I do know for sure, is that this have to do with making
 multiple ajax request which are scheduled by the Wicket.Channel and are
 executed synchronously and which affects the DOM when the response is
 arrived, thus the component tree is out of sync with the actual DOM. (For
 instance user clicks 5 times on the Edit button, which is a slow
 operation
 and its response change the component's DOM)

 I am searching for workarounds for this issue. It is about preventing
 user
 to make multiple request (blocking), but this is not that easy (God
 bless
 IE).

 Alex


 Alex Objelean wrote:
 
  I've got randomly an exception when clicking on the table row which has
 an
  AjaxEventBehavior assigned.
  Below is the stacktrace. Any ideas?
 
  [10:34:27.875] ERROR [http-8080-Processor1] RequestCycle - component
  body:panel:actionListContainer:actionList:form:actionList:14 not found
 on
  page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener
  interface = [RequestListenerInterface name=IBehaviorListener,
  method=public abstract void
  org.apache.wicket.behavior.IBehaviorListener.onRequest()]
  org.apache.wicket.WicketRuntimeException: component
  body:panel:actionListContainer:actionList:form:actionList:14 not found
 on
  page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[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:394)
at
 
 org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:440)
at
 
 org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1090)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1176)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:499)
at
 
 org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:257)
at
 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:127)
at
 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
 
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
at
 
 org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
at
 
 org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
at
 
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
 
 org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
at
 
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
 
 org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
at
 
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
 
 org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
at
 
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
 
 org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
at
 
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
 
 org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
at
 
 org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
at
 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
 
 

Re: Strange bug in Wicket-1.3.0-beta2

2007-09-06 Thread Matej Knopp
Dunno, there's still work to do, but there are snapshot somewhere
available, you can grab those if you don't want to build wicket.

-Matej

On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:

 Thank you very much Matej! To be honest, I didn't expected to have such a
 prompt response. :)

 Btw, when beta-4 is out?

 Alex.


 Matej Knopp-2 wrote:
 
  Yes, I know what's causing it. And as I said, this should be already
  taken care of. I've added a special precondition evaluated right
  before each scheduled ajax request to check if the originating DOM
  element is still in the document.
 
  -Matej
 
  On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
 
  Right now, I do not know if this kind of issue can be fixed on the wicket
  side. But what I do know for sure, is that this have to do with making
  multiple ajax request which are scheduled by the Wicket.Channel and are
  executed synchronously and which affects the DOM when the response is
  arrived, thus the component tree is out of sync with the actual DOM. (For
  instance user clicks 5 times on the Edit button, which is a slow
  operation
  and its response change the component's DOM)
 
  I am searching for workarounds for this issue. It is about preventing
  user
  to make multiple request (blocking), but this is not that easy (God
  bless
  IE).
 
  Alex
 
 
  Alex Objelean wrote:
  
   I've got randomly an exception when clicking on the table row which has
  an
   AjaxEventBehavior assigned.
   Below is the stacktrace. Any ideas?
  
   [10:34:27.875] ERROR [http-8080-Processor1] RequestCycle - component
   body:panel:actionListContainer:actionList:form:actionList:14 not found
  on
   page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener
   interface = [RequestListenerInterface name=IBehaviorListener,
   method=public abstract void
   org.apache.wicket.behavior.IBehaviorListener.onRequest()]
   org.apache.wicket.WicketRuntimeException: component
   body:panel:actionListContainer:actionList:form:actionList:14 not found
  on
   page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[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:394)
 at
  
  org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:440)
 at
  
  org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139)
 at org.apache.wicket.RequestCycle.step(RequestCycle.java:1090)
 at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1176)
 at org.apache.wicket.RequestCycle.request(RequestCycle.java:499)
 at
  
  org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:257)
 at
  
  org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:127)
 at
  
  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
 at
  
  org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at
  
  org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
 at
  
  org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
 at
  
  org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
 at
  
  org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
 at
  
  org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
 at
  
  org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
 at
  
  org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
 at
  
  org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
 at
  
  org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
 at
  
  org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
 at
  
  org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
 at
  
  org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
 at
  
  org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
 at
  
  org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
 at
  
  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
 at
  
  

Re: Strange bug in Wicket-1.3.0-beta2

2007-09-06 Thread Matej Knopp
http://www.wicketstuff.org/maven/repository/org/apache/wicket/

On 9/6/07, Matej Knopp [EMAIL PROTECTED] wrote:
 Dunno, there's still work to do, but there are snapshot somewhere
 available, you can grab those if you don't want to build wicket.

 -Matej

 On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
 
  Thank you very much Matej! To be honest, I didn't expected to have such a
  prompt response. :)
 
  Btw, when beta-4 is out?
 
  Alex.
 
 
  Matej Knopp-2 wrote:
  
   Yes, I know what's causing it. And as I said, this should be already
   taken care of. I've added a special precondition evaluated right
   before each scheduled ajax request to check if the originating DOM
   element is still in the document.
  
   -Matej
  
   On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
  
   Right now, I do not know if this kind of issue can be fixed on the wicket
   side. But what I do know for sure, is that this have to do with making
   multiple ajax request which are scheduled by the Wicket.Channel and are
   executed synchronously and which affects the DOM when the response is
   arrived, thus the component tree is out of sync with the actual DOM. (For
   instance user clicks 5 times on the Edit button, which is a slow
   operation
   and its response change the component's DOM)
  
   I am searching for workarounds for this issue. It is about preventing
   user
   to make multiple request (blocking), but this is not that easy (God
   bless
   IE).
  
   Alex
  
  
   Alex Objelean wrote:
   
I've got randomly an exception when clicking on the table row which has
   an
AjaxEventBehavior assigned.
Below is the stacktrace. Any ideas?
   
[10:34:27.875] ERROR [http-8080-Processor1] RequestCycle - component
body:panel:actionListContainer:actionList:form:actionList:14 not found
   on
page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[id = 0], listener
interface = [RequestListenerInterface name=IBehaviorListener,
method=public abstract void
org.apache.wicket.behavior.IBehaviorListener.onRequest()]
org.apache.wicket.WicketRuntimeException: component
body:panel:actionListContainer:actionList:form:actionList:14 not found
   on
page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[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:394)
  at
   
   org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:440)
  at
   
   org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139)
  at org.apache.wicket.RequestCycle.step(RequestCycle.java:1090)
  at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1176)
  at org.apache.wicket.RequestCycle.request(RequestCycle.java:499)
  at
   
   org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:257)
  at
   
   org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:127)
  at
   
   org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  at
   
   org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  at
   
   org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
  at
   
   org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
  at
   
   org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
  at
   
   org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
   
   org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
  at
   
   org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
   
   org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
  at
   
   org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
   
   org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
  at
   
   org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
   
   org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
  at
   
   org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
   
   org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
  at
   
   

Re: Wicket validation flaw?

2007-09-06 Thread Alex Objelean

Done, see here:  https://issues.apache.org/jira/browse/WICKET-934 WICKET-934 


Matej Knopp-2 wrote:
 
 I thought we were trimming textfield strings, but now i see it's no
 longer the case. Is it a regression or a feature?
 
 Also the missing message doesn't make much sense, can you please
 report a JIRA issue and attach a quick start project?
 
 -Matej
 
 On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:

 I've discovered the following issue:
 When using a DateTextField in a form (with the format: dd/MM/), user
 by
 mistake add an extra space (for instance: 06/09/2007 ) and submit the
 form. The are two problems:

 1) I would expect the convertor to convert this value correct, but the
 AbstractConverter.parse method throws a ConversionException because:
 (position.getIndex() != stringValue.length())

 2) The above exception is not reported anywhere, because validate method
 does not check if the input is valid after converting its value:



public final void validate()
{
validateRequired();
if (isValid())
{
convertInput();
 
if (isValid()  isRequired() 
 getConvertedInput() == null 
  isInputNullable())
{
reportRequiredError();
}
  /*isn't something like this missing here?*/ if
  (!isValid()) { /*report Conversion error*/ }
if (isValid())
{
validateValidators();
}
}
}
 

 Any thoughts?

 Thank you!
 Alex.
 --
 View this message in context:
 http://www.nabble.com/Wicket-validation-flaw--tf4390183.html#a12517215
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Wicket-validation-flaw--tf4390183.html#a12519551
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Progressive Enhancement

2007-09-06 Thread Erik van Oosten
Here is an article on the subject:

http://day-to-day-stuff.blogspot.com/2007/01/backward-compatible-ajax-development.html

Regards,
Erik.


 Taking that approach would mean pages that were ajax would
 work if the the user disabled javascript or not. Not to mention
 a whole wealth of other benefits that can be found here...



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?

2007-09-06 Thread Alex Objelean

I've grabbed the latest SNAPSHOT from the repository and have noticed that
AbstractRepeater#onBeforeRender is final. I wonder what is the reason for
this? (I need to do something in it's subclass)
/**
 * @see org.apache.wicket.Component#onBeforeRender()
 */
protected final void onBeforeRender()
{
if (isVisibleInHierarchy())
{
onPopulate();
}
super.onBeforeRender();
}

Alex
-- 
View this message in context: 
http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Progressive Enhancement

2007-09-06 Thread bmarvell

Thanks :)

Erik van Oosten wrote:
 
 Here is an article on the subject:
 
 http://day-to-day-stuff.blogspot.com/2007/01/backward-compatible-ajax-development.html
 
 Regards,
 Erik.
 
 
 Taking that approach would mean pages that were ajax would
 work if the the user disabled javascript or not. Not to mention
 a whole wealth of other benefits that can be found here...
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Progressive-Enhancement-tf4390623.html#a12520702
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?

2007-09-06 Thread Alex Objelean

I would prefer to use onBeforeRender, instead of onPopulate, since it is the
I do in other components. Why would I use different life-cycle methods,
depending on the component I'm using?

Alex


Matej Knopp-2 wrote:
 
 IMHO that's a bit wrong.
 You can subclass onPopulate instead, but i think we can remove the
 code, because after recent changes onBeforeRender() is only called
 when component is visible in hierarchy.
 
 -Matej
 
 On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:

 I've grabbed the latest SNAPSHOT from the repository and have noticed
 that
 AbstractRepeater#onBeforeRender is final. I wonder what is the reason for
 this? (I need to do something in it's subclass)
 /**
  * @see org.apache.wicket.Component#onBeforeRender()
  */
 protected final void onBeforeRender()
 {
 if (isVisibleInHierarchy())
 {
 onPopulate();
 }
 super.onBeforeRender();
 }

 Alex
 --
 View this message in context:
 http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520766
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?

2007-09-06 Thread Alex Objelean

Thank you again, Matej! :)
Will it be fixed, or should I create a task in JIRA?

Alex 


Matej Knopp-2 wrote:
 
 Some time ago onBeforeRender was called always, even if the component
 was not visible. This had caused problems with repeaters, therefore
 this restriction - to make sure onPopulate is called only when
 component is visible. But IMHO that's no longer necessary.
 
 -Matej
 
 On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:

 I would prefer to use onBeforeRender, instead of onPopulate, since it is
 the
 I do in other components. Why would I use different life-cycle methods,
 depending on the component I'm using?

 Alex


 Matej Knopp-2 wrote:
 
  IMHO that's a bit wrong.
  You can subclass onPopulate instead, but i think we can remove the
  code, because after recent changes onBeforeRender() is only called
  when component is visible in hierarchy.
 
  -Matej
 
  On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
 
  I've grabbed the latest SNAPSHOT from the repository and have noticed
  that
  AbstractRepeater#onBeforeRender is final. I wonder what is the reason
 for
  this? (I need to do something in it's subclass)
  /**
   * @see org.apache.wicket.Component#onBeforeRender()
   */
  protected final void onBeforeRender()
  {
  if (isVisibleInHierarchy())
  {
  onPopulate();
  }
  super.onBeforeRender();
  }
 
  Alex
  --
  View this message in context:
 
 http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520766
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12521043
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?

2007-09-06 Thread Matej Knopp
Please do, so that we don't forget.

-Matej

On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:

 Thank you again, Matej! :)
 Will it be fixed, or should I create a task in JIRA?

 Alex


 Matej Knopp-2 wrote:
 
  Some time ago onBeforeRender was called always, even if the component
  was not visible. This had caused problems with repeaters, therefore
  this restriction - to make sure onPopulate is called only when
  component is visible. But IMHO that's no longer necessary.
 
  -Matej
 
  On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
 
  I would prefer to use onBeforeRender, instead of onPopulate, since it is
  the
  I do in other components. Why would I use different life-cycle methods,
  depending on the component I'm using?
 
  Alex
 
 
  Matej Knopp-2 wrote:
  
   IMHO that's a bit wrong.
   You can subclass onPopulate instead, but i think we can remove the
   code, because after recent changes onBeforeRender() is only called
   when component is visible in hierarchy.
  
   -Matej
  
   On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
  
   I've grabbed the latest SNAPSHOT from the repository and have noticed
   that
   AbstractRepeater#onBeforeRender is final. I wonder what is the reason
  for
   this? (I need to do something in it's subclass)
   /**
* @see org.apache.wicket.Component#onBeforeRender()
*/
   protected final void onBeforeRender()
   {
   if (isVisibleInHierarchy())
   {
   onPopulate();
   }
   super.onBeforeRender();
   }
  
   Alex
   --
   View this message in context:
  
  http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
   Sent from the Wicket - User mailing list archive at Nabble.com.
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
 
  --
  View this message in context:
  http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520766
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

 --
 View this message in context: 
 http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12521043
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



wicket tester / tester.assertResultPage(clazz, filename);

2007-09-06 Thread Nino Saturnino Martinez Vazquez Wael

Hi

Im trying to create a test that renders a page and then compares it to 
the expected result. Currently I keep getting diff errors although I 
just copied the contents of the html file from the tester.dumpPage() and 
placed it in the expected result file. I guess its just a matter of 
spaces thats wrong, but not matter how I change them they dont seem to 
add up apparently.


As it can be somewhat a task guessing how the contents of a wicket page 
might look, I thought this was the most simple approach to doing this 
but I might be wrong?


regards Nino

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: wicket tester / tester.assertResultPage(clazz, filename);

2007-09-06 Thread Nino Saturnino Martinez Vazquez Wael

I should also mentioned that Im testing by doing this:

WicketTester.assertResultPage(this.getClass(), filename);

Nino Saturnino Martinez Vazquez Wael wrote:

Hi

Im trying to create a test that renders a page and then compares it to 
the expected result. Currently I keep getting diff errors although I 
just copied the contents of the html file from the tester.dumpPage() 
and placed it in the expected result file. I guess its just a matter 
of spaces thats wrong, but not matter how I change them they dont seem 
to add up apparently.


As it can be somewhat a task guessing how the contents of a wicket 
page might look, I thought this was the most simple approach to doing 
this but I might be wrong?


regards Nino

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?

2007-09-06 Thread Alex Objelean

Done. Here is the issue link: 
https://issues.apache.org/jira/browse/WICKET-935 WICKET-935 


Matej Knopp-2 wrote:
 
 Please do, so that we don't forget.
 
 -Matej
 
 On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:

 Thank you again, Matej! :)
 Will it be fixed, or should I create a task in JIRA?

 Alex


 Matej Knopp-2 wrote:
 
  Some time ago onBeforeRender was called always, even if the component
  was not visible. This had caused problems with repeaters, therefore
  this restriction - to make sure onPopulate is called only when
  component is visible. But IMHO that's no longer necessary.
 
  -Matej
 
  On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
 
  I would prefer to use onBeforeRender, instead of onPopulate, since it
 is
  the
  I do in other components. Why would I use different life-cycle
 methods,
  depending on the component I'm using?
 
  Alex
 
 
  Matej Knopp-2 wrote:
  
   IMHO that's a bit wrong.
   You can subclass onPopulate instead, but i think we can remove the
   code, because after recent changes onBeforeRender() is only called
   when component is visible in hierarchy.
  
   -Matej
  
   On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
  
   I've grabbed the latest SNAPSHOT from the repository and have
 noticed
   that
   AbstractRepeater#onBeforeRender is final. I wonder what is the
 reason
  for
   this? (I need to do something in it's subclass)
   /**
* @see org.apache.wicket.Component#onBeforeRender()
*/
   protected final void onBeforeRender()
   {
   if (isVisibleInHierarchy())
   {
   onPopulate();
   }
   super.onBeforeRender();
   }
  
   Alex
   --
   View this message in context:
  
 
 http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
   Sent from the Wicket - User mailing list archive at Nabble.com.
  
  
  
 -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
  
 -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
 
  --
  View this message in context:
 
 http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520766
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12521043
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12521149
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Strange bug in Wicket-1.3.0-beta2

2007-09-06 Thread Alex Objelean

With the latest SNAPSHOT, the application throws Exception almost always
:(... I thing, it has not been tested too much. Here is the stacktrace: 

.apache.wicket.WicketRuntimeException: component
body:panel:actionListContainer:actionList:form:actionList:65 not found on
page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[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:393)
 at
org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:439)
 at
org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139)
 at org.apache.wicket.RequestCycle.step(RequestCycle.java:1077)
 at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1173)
 at org.apache.wicket.RequestCycle.request(RequestCycle.java:483)
 at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:277)
 at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:129)
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
 at
org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
 at
org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
 at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
 at
org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
 at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
 at
org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
 at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
 at
org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
 at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
 at
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
 at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
 at
org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
 at
org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
 at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
 at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
 at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
 at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
 at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
 at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
 at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
 at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
 at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
 at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
 at java.lang.Thread.run(Thread.java:595)



Matej Knopp-2 wrote:
 
 http://www.wicketstuff.org/maven/repository/org/apache/wicket/
 
 On 9/6/07, Matej Knopp [EMAIL PROTECTED] wrote:
 Dunno, there's still work to do, but there are snapshot somewhere
 available, you can grab those if you don't want to build wicket.

 -Matej

 On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
 
  Thank you very much Matej! To be honest, I didn't expected to have such
 a
  prompt response. :)
 
  Btw, when beta-4 is out?
 
  Alex.
 
 
  Matej Knopp-2 wrote:
  
   Yes, I know what's causing it. And as I said, this should be already
   taken care of. I've added a special precondition evaluated right
   before each scheduled ajax request to check if the originating DOM
   element is still in the document.
  
   -Matej
  
   On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
  
   Right now, I do not know if this kind of issue can 

Howto use AttributeModifier

2007-09-06 Thread Per Newgro
Hi *,

i use wicket-1.2.6. I try to change the background-color of an gridtable item. 
But i dont get it to work. Is there a howto or doc for it? javadoc is not that 
detailed.

My goal is to display a table with link as cell-content. If i click on the link 
the cell should be marked selected by changing the color.

Maybe there is a better (simplier) way?

Thanks for your help

Per

Here is my code (i removed some not required details, to shorten up the mail).

package wicket.quickstart;

import java.util.Date;

import wicket.AttributeModifier;
import wicket.Component;
import wicket.PageParameters;
import wicket.behavior.SimpleAttributeModifier;
import wicket.extensions.markup.html.repeater.data.GridView;
import wicket.extensions.markup.html.repeater.data.IDataProvider;
import wicket.extensions.markup.html.repeater.data.ListDataProvider;
import wicket.extensions.markup.html.repeater.refreshing.Item;
import wicket.markup.html.basic.Label;
import wicket.markup.html.link.Link;
import wicket.model.IModel;
import wicket.model.Model;

public class SelectDay extends QuickStartPage {
  private static class HighlitableDataItem extends Item {
private boolean highlite = true;
private AttributeModifier modifier = null;

public void toggleHighlite() {
  highlite = !highlite;
}

public HighlitableDataItem(String id, int index, IModel model) {
  super(id, index, model);
  modifier = new AttributeModifier(class, selected, new Model() {
public Object getObject(Component component) {
  if (highlite){
return selected;
  }
  return deselected;
}
  });
  add(modifier);
}
  }

  public SelectDay(final PageParameters parameters) {
List list = new ArrayList();
list.add(1);
list.add(2);
list.add(3);
IDataProvider dataProvider = new ListDataProvider(list);
GridView gridView = new GridView(rows, dataProvider) {

  protected void populateItem(final Item item) {
final Integer weekday = (Integer) item
.getModelObject();
Link link = new Link(toggleHighlite) {

  public void onClick() {
System.out.println(onclick);
HighlitableDataItem hitem = (HighlitableDataItem) item;
hitem.toggleHighlite();
  }
};
link.add(new Label(linklabel, weekday));
item.add(link);
item.add(new Label(day, ));
  }

  protected void populateEmptyItem(Item item) {
throw new UnsupportedOperationException(Unexpected);
  }

  protected Item newItem(String id, int index, IModel model) {
Item result = null;
Object o = model.getObject(this);
if (o instanceof Integer) {
  result = new HighlitableDataItem(id, index, model);
  result.add(new SimpleAttributeModifier(style,
background-color:#ff;));
} else {
  result = new Item(id, index, model);
}

return result;
  }
};

gridView.setRows(2);
gridView.setColumns(2);
add(gridView);
  }
}

SelectDay.html
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
html
head
  titleCalendar/title
link rel=stylesheet href=buma.css type=text/css media=all /

/head

body

h1QuickStart/h1

pCalendar/p
div
table class=calendar
  tbody
tr wicket:id=rows
  td wicket:id=cols
a href=# wicket:id=toggleHighlitespan 
wicket:id=linklabel/span/a
span wicket:id=day/span
  /td
/tr
  /tbody
/table
/div
/body
/html

buma.css


table.calendar {
margin:auto;
align: center;
border-spacing: 3px;
}

table.calendar td {
background: #FFBF00;
text-align: center;
color: #33;
border: 1px solid;
border-color: #33;
padding: 1px 7px;
margin: 3px;
empty-cells: hide;
}

table.calendar .selected {
background: #FF;
text-align: center;
color: #33;
border: 1px solid;
border-color: #33;
padding: 1px 7px;
margin: 3px;
empty-cells: hide;
}

table.calendar .deselected {
background: #FF00FF;
text-align: center;
color: #33;
border: 1px solid;
border-color: #33;
padding: 1px 7px;
margin: 3px;
empty-cells: hide;
}

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: How to set wicket's locale?

2007-09-06 Thread Gabor Szokoli
On 9/5/07, Johan Compagner [EMAIL PROTECTED] wrote:
 can  you make an jira issue for this?

https://issues.apache.org/jira/browse/WICKET-936

Any ideas on encapsulating the session as a propertymodel for components in 1.2?


Gabor

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: How to set wicket's locale?

2007-09-06 Thread Martijn Dashorst
new PropertyModel(Page.this, session.foo.sushi.bar);

?


On 9/6/07, Gabor Szokoli [EMAIL PROTECTED] wrote:
 On 9/5/07, Johan Compagner [EMAIL PROTECTED] wrote:
  can  you make an jira issue for this?

 https://issues.apache.org/jira/browse/WICKET-936

 Any ideas on encapsulating the session as a propertymodel for components in 
 1.2?


 Gabor

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Strange bug in Wicket-1.3.0-beta2

2007-09-06 Thread Matej Knopp
that's weird. could be a bug in precodition check. Can you please
create a jira entry and add a quickstart project? This might be a
corner case, I'd like to fix this asap.

-Matej

On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:

 With the latest SNAPSHOT, the application throws Exception almost always
 :(... I thing, it has not been tested too much. Here is the stacktrace:

 .apache.wicket.WicketRuntimeException: component
 body:panel:actionListContainer:actionList:form:actionList:65 not found on
 page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[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:393)
  at
 org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:439)
  at
 org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139)
  at org.apache.wicket.RequestCycle.step(RequestCycle.java:1077)
  at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1173)
  at org.apache.wicket.RequestCycle.request(RequestCycle.java:483)
  at
 org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:277)
  at
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:129)
  at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
  at
 org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
  at
 org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
 org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
 org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
 org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
 org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
 org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
  at
 org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
  at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  at
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
  at
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
  at
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
  at
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
  at
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
  at
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
  at
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
  at
 org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
  at
 org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
  at
 org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
  at
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
  at java.lang.Thread.run(Thread.java:595)



 Matej Knopp-2 wrote:
 
  http://www.wicketstuff.org/maven/repository/org/apache/wicket/
 
  On 9/6/07, Matej Knopp [EMAIL PROTECTED] wrote:
  Dunno, there's still work to do, but there are snapshot somewhere
  available, you can grab those if you don't want to build wicket.
 
  -Matej
 
  On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
  
   Thank you very much Matej! To be honest, I didn't expected to have such
  a
   prompt response. :)
  
   Btw, when beta-4 is out?
  
   Alex.
  
  
   Matej Knopp-2 wrote:
   
Yes, I know what's causing it. And as I 

Re: Strange bug in Wicket-1.3.0-beta2

2007-09-06 Thread Alex Objelean

It's quite hard to create a quickstart project, since the project I'm working
on is very large. But if you think that it is enough to create a JIRA task
with the stacktrace and short description, than I'll do it.

Alex


Matej Knopp-2 wrote:
 
 that's weird. could be a bug in precodition check. Can you please
 create a jira entry and add a quickstart project? This might be a
 corner case, I'd like to fix this asap.
 
 -Matej
 
 On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:

 With the latest SNAPSHOT, the application throws Exception almost always
 :(... I thing, it has not been tested too much. Here is the stacktrace:

 .apache.wicket.WicketRuntimeException: component
 body:panel:actionListContainer:actionList:form:actionList:65 not found on
 page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[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:393)
  at
 org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:439)
  at
 org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139)
  at org.apache.wicket.RequestCycle.step(RequestCycle.java:1077)
  at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1173)
  at org.apache.wicket.RequestCycle.request(RequestCycle.java:483)
  at
 org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:277)
  at
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:129)
  at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
  at
 org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
  at
 org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
 org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
 org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
 org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
 org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
  at
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at
 org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
  at
 org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
  at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
  at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  at
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
  at
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
  at
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
  at
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
  at
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
  at
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
  at
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
  at
 org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
  at
 org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
  at
 org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
  at
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
  at java.lang.Thread.run(Thread.java:595)



 Matej Knopp-2 wrote:
 
  http://www.wicketstuff.org/maven/repository/org/apache/wicket/
 
  On 9/6/07, Matej Knopp [EMAIL PROTECTED] wrote:
  Dunno, there's still work to do, but there are snapshot somewhere
  available, you can grab those if you don't want to build wicket.
 
  -Matej
 
  On 9/6/07, Alex 

Re: Strange bug in Wicket-1.3.0-beta2

2007-09-06 Thread Matej Knopp
Unfortunately just a jira issue will not od that. Can't you try to
isolate the problem?

-Matej

On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:

 It's quite hard to create a quickstart project, since the project I'm working
 on is very large. But if you think that it is enough to create a JIRA task
 with the stacktrace and short description, than I'll do it.

 Alex


 Matej Knopp-2 wrote:
 
  that's weird. could be a bug in precodition check. Can you please
  create a jira entry and add a quickstart project? This might be a
  corner case, I'd like to fix this asap.
 
  -Matej
 
  On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
 
  With the latest SNAPSHOT, the application throws Exception almost always
  :(... I thing, it has not been tested too much. Here is the stacktrace:
 
  .apache.wicket.WicketRuntimeException: component
  body:panel:actionListContainer:actionList:form:actionList:65 not found on
  page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[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:393)
   at
  org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:439)
   at
  org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139)
   at org.apache.wicket.RequestCycle.step(RequestCycle.java:1077)
   at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1173)
   at org.apache.wicket.RequestCycle.request(RequestCycle.java:483)
   at
  org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:277)
   at
  org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:129)
   at
  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
   at
  org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
   at
  org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
   at
  org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
   at
  org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
   at
  org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
   at
  org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
   at
  org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
   at
  org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
   at
  org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
   at
  org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
   at
  org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
   at
  org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
   at
  org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
   at
  org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
   at
  org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
   at
  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
   at
  org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
   at
  org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
   at
  org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
   at
  org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
   at
  org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
   at
  org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
   at
  org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
   at
  org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
   at
  org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
   at
  org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
   at
  org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
   at
  org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
   at java.lang.Thread.run(Thread.java:595)
 
 
 
  Matej Knopp-2 wrote:
  
   

Re: Strange bug in Wicket-1.3.0-beta2

2007-09-06 Thread Matej Knopp
Also, can you post code of the serverside event handler?

-Matej

On 9/6/07, Matej Knopp [EMAIL PROTECTED] wrote:
 Unfortunately just a jira issue will not od that. Can't you try to
 isolate the problem?

 -Matej

 On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
 
  It's quite hard to create a quickstart project, since the project I'm 
  working
  on is very large. But if you think that it is enough to create a JIRA task
  with the stacktrace and short description, than I'll do it.
 
  Alex
 
 
  Matej Knopp-2 wrote:
  
   that's weird. could be a bug in precodition check. Can you please
   create a jira entry and add a quickstart project? This might be a
   corner case, I'd like to fix this asap.
  
   -Matej
  
   On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
  
   With the latest SNAPSHOT, the application throws Exception almost always
   :(... I thing, it has not been tested too much. Here is the stacktrace:
  
   .apache.wicket.WicketRuntimeException: component
   body:panel:actionListContainer:actionList:form:actionList:65 not found on
   page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[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:393)
at
   org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:439)
at
   org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1077)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1173)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:483)
at
   org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:277)
at
   org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:129)
at
   org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
   org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
   org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
at
   org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
at
   org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
at
   org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
   org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
at
   org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
   org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
at
   org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
   org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
at
   org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
   org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
at
   org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
   org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
at
   org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
at
   org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
   org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
   org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
   org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
   org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
   org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
   org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
   org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
   org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
   org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at
   org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
   org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)

Re: wicket tester / tester.assertResultPage(clazz, filename);

2007-09-06 Thread Nino Saturnino Martinez Vazquez Wael

Fidling around with the spaces, I've now boiled it down to this error only:

ERROR - DiffUtil   - ===

It's not that descriptive though:( Cant really see whats wrong..

regards Nino

Nino Saturnino Martinez Vazquez Wael wrote:

I should also mentioned that Im testing by doing this:

WicketTester.assertResultPage(this.getClass(), filename);

Nino Saturnino Martinez Vazquez Wael wrote:

Hi

Im trying to create a test that renders a page and then compares it 
to the expected result. Currently I keep getting diff errors although 
I just copied the contents of the html file from the 
tester.dumpPage() and placed it in the expected result file. I guess 
its just a matter of spaces thats wrong, but not matter how I change 
them they dont seem to add up apparently.


As it can be somewhat a task guessing how the contents of a wicket 
page might look, I thought this was the most simple approach to doing 
this but I might be wrong?


regards Nino

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: wicket tester / tester.assertResultPage(clazz, filename);

2007-09-06 Thread Nino Saturnino Martinez Vazquez Wael

looking at the sourcefile I saw this option:

-Dwicket.replace.expected.results=true

could this be what I was looking for to genereate the expected results? 
I think so:)


regards Nino

Nino Saturnino Martinez Vazquez Wael wrote:
Fidling around with the spaces, I've now boiled it down to this error 
only:


ERROR - DiffUtil   - ===

It's not that descriptive though:( Cant really see whats wrong..

regards Nino

Nino Saturnino Martinez Vazquez Wael wrote:

I should also mentioned that Im testing by doing this:

WicketTester.assertResultPage(this.getClass(), filename);

Nino Saturnino Martinez Vazquez Wael wrote:

Hi

Im trying to create a test that renders a page and then compares it 
to the expected result. Currently I keep getting diff errors 
although I just copied the contents of the html file from the 
tester.dumpPage() and placed it in the expected result file. I guess 
its just a matter of spaces thats wrong, but not matter how I change 
them they dont seem to add up apparently.


As it can be somewhat a task guessing how the contents of a wicket 
page might look, I thought this was the most simple approach to 
doing this but I might be wrong?


regards Nino

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Strange bug in Wicket-1.3.0-beta2

2007-09-06 Thread Alex Objelean

I will do that as soon as I can (hope tomorrow. Anyway, the quickstart is
easy to create). Till then, a short description:
I use a RefreshingView table with actions (some business entity). Each row
has attached an AjaxEventBehavior to onclick event. When a row is clicked,
another component (action summary) is refreshed. 

When using the SNAPSHOT version, I've got the exception when clicking any
row.

PS: I do not know if it is a precondition bug, maybe the wicket-ajax.js have
some other malicious changes. 


Matej Knopp-2 wrote:
 
 Unfortunately just a jira issue will not od that. Can't you try to
 isolate the problem?
 
 -Matej
 
 On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:

 It's quite hard to create a quickstart project, since the project I'm
 working
 on is very large. But if you think that it is enough to create a JIRA
 task
 with the stacktrace and short description, than I'll do it.

 Alex


 Matej Knopp-2 wrote:
 
  that's weird. could be a bug in precodition check. Can you please
  create a jira entry and add a quickstart project? This might be a
  corner case, I'd like to fix this asap.
 
  -Matej
 
  On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
 
  With the latest SNAPSHOT, the application throws Exception almost
 always
  :(... I thing, it has not been tested too much. Here is the
 stacktrace:
 
  .apache.wicket.WicketRuntimeException: component
  body:panel:actionListContainer:actionList:form:actionList:65 not found
 on
  page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[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:393)
   at
 
 org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:439)
   at
 
 org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139)
   at org.apache.wicket.RequestCycle.step(RequestCycle.java:1077)
   at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1173)
   at org.apache.wicket.RequestCycle.request(RequestCycle.java:483)
   at
 
 org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:277)
   at
 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:129)
   at
 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
   at
 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
   at
 
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
   at
 
 org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
   at
 
 org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
   at
 
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
   at
 
 org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
   at
 
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
   at
 
 org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
   at
 
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
   at
 
 org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
   at
 
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
   at
 
 org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
   at
 
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
   at
 
 org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
   at
 
 org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
   at
 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
   at
 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
   at
 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
   at
 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
   at
 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
   at
 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
   at
 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
   at
 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
   at
 
 

DIV TAG HEADER DO NOT WORK IN WICKET

2007-09-06 Thread bhupat parmar
THE HEADER IS NOT WORKING


DIV id=header
UL
  LIA href=# wicket:id=homeLinkHome/A/LI
  LI id=current wicket:id=trendArchiveA href=#Trend
Archive/A/LI
  LIA href=# wicket:id=latestLookLink The Latest
Looks/A/LI
  LI class=advanced wicket:id=pepsiStyleLinkA href=#Pepsi
Style/A /LI
  LIA href=# wicket:id=myClosetLinkMy Closet/A /LI
  LIA href=# wicket:id=submitStyleLinkSubmit Style /A/LI
/UL
  /DIV/td


Re: DIV TAG HEADER DO NOT WORK IN WICKET

2007-09-06 Thread Nino Saturnino Martinez Vazquez Wael

hmm should'nt it be in  or '' like this:
div id=header?

regards Nino

bhupat parmar wrote:

THE HEADER IS NOT WORKING


DIV id=header
UL
  LIA href=# wicket:id=homeLinkHome/A/LI
  LI id=current wicket:id=trendArchiveA href=#Trend
Archive/A/LI
  LIA href=# wicket:id=latestLookLink The Latest
Looks/A/LI
  LI class=advanced wicket:id=pepsiStyleLinkA href=#Pepsi
Style/A /LI
  LIA href=# wicket:id=myClosetLinkMy Closet/A /LI
  LIA href=# wicket:id=submitStyleLinkSubmit Style /A/LI
/UL
  /DIV/td

  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Strange bug in Wicket-1.3.0-beta2

2007-09-06 Thread Alex Objelean

It's only a false alarm. Sorry. My fault. Probably I didn't perform a 'clean'
before the application has been deployed. The issue is CLOSED!

PS: Big 'THANK YOU' to Matej :).


Alex Objelean wrote:
 
 Last post was completely wrong.
 Here is another handler which works ok:
 
 var
 wcall=wicketAjaxGet('?wicket:interface=:0:body:panel:actionDetailsContainer:actionDetails:panel:actionSummaryButtons:editOr',
 function() { }.bind(this), function() { }.bind(this), function() {return
 Wicket.$$(this)}.bind(this));return !wcall;
 
 
 Alex Objelean wrote:
 
 Yep, any row.
 What have I noticed also is that other ajax interaction works ok. The
 only difference is that one using 
 wicketAjaxGet method, and another wicketAjaxPost (this one is ok). Maybe
 the bug is somewhere in this funtion: wicketAjaxGet?
 
 Alex
 
 
 Matej Knopp-2 wrote:
 
 When clicking _any_ row? Now that really is interesting. I hope you'll
 able to provide the quickstart soon.
 
 -Matej
 
 On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:

 I will do that as soon as I can (hope tomorrow. Anyway, the quickstart
 is
 easy to create). Till then, a short description:
 I use a RefreshingView table with actions (some business entity). Each
 row
 has attached an AjaxEventBehavior to onclick event. When a row is
 clicked,
 another component (action summary) is refreshed.

 When using the SNAPSHOT version, I've got the exception when clicking
 any
 row.

 PS: I do not know if it is a precondition bug, maybe the wicket-ajax.js
 have
 some other malicious changes.


 Matej Knopp-2 wrote:
 
  Unfortunately just a jira issue will not od that. Can't you try to
  isolate the problem?
 
  -Matej
 
  On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
 
  It's quite hard to create a quickstart project, since the project
 I'm
  working
  on is very large. But if you think that it is enough to create a
 JIRA
  task
  with the stacktrace and short description, than I'll do it.
 
  Alex
 
 
  Matej Knopp-2 wrote:
  
   that's weird. could be a bug in precodition check. Can you please
   create a jira entry and add a quickstart project? This might be a
   corner case, I'd like to fix this asap.
  
   -Matej
  
   On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
  
   With the latest SNAPSHOT, the application throws Exception almost
  always
   :(... I thing, it has not been tested too much. Here is the
  stacktrace:
  
   .apache.wicket.WicketRuntimeException: component
   body:panel:actionListContainer:actionList:form:actionList:65 not
 found
  on
   page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[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:393)
at
  
 
 org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:439)
at
  
 
 org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139)
at
 org.apache.wicket.RequestCycle.step(RequestCycle.java:1077)
at
 org.apache.wicket.RequestCycle.steps(RequestCycle.java:1173)
at
 org.apache.wicket.RequestCycle.request(RequestCycle.java:483)
at
  
 
 org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:277)
at
  
 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:129)
at
  
 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
  
 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
  
 
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
at
  
 
 org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
at
  
 
 org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
at
  
 
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
  
 
 org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
at
  
 
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
  
 
 org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
at
  
 
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
  
 
 org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
at
  
 
 org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
  
 
 

Re: Strange bug in Wicket-1.3.0-beta2

2007-09-06 Thread Matej Knopp
You're welcome :)

On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:

 It's only a false alarm. Sorry. My fault. Probably I didn't perform a 'clean'
 before the application has been deployed. The issue is CLOSED!

 PS: Big 'THANK YOU' to Matej :).


 Alex Objelean wrote:
 
  Last post was completely wrong.
  Here is another handler which works ok:
 
  var
  wcall=wicketAjaxGet('?wicket:interface=:0:body:panel:actionDetailsContainer:actionDetails:panel:actionSummaryButtons:editOr',
  function() { }.bind(this), function() { }.bind(this), function() {return
  Wicket.$$(this)}.bind(this));return !wcall;
 
 
  Alex Objelean wrote:
 
  Yep, any row.
  What have I noticed also is that other ajax interaction works ok. The
  only difference is that one using
  wicketAjaxGet method, and another wicketAjaxPost (this one is ok). Maybe
  the bug is somewhere in this funtion: wicketAjaxGet?
 
  Alex
 
 
  Matej Knopp-2 wrote:
 
  When clicking _any_ row? Now that really is interesting. I hope you'll
  able to provide the quickstart soon.
 
  -Matej
 
  On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
 
  I will do that as soon as I can (hope tomorrow. Anyway, the quickstart
  is
  easy to create). Till then, a short description:
  I use a RefreshingView table with actions (some business entity). Each
  row
  has attached an AjaxEventBehavior to onclick event. When a row is
  clicked,
  another component (action summary) is refreshed.
 
  When using the SNAPSHOT version, I've got the exception when clicking
  any
  row.
 
  PS: I do not know if it is a precondition bug, maybe the wicket-ajax.js
  have
  some other malicious changes.
 
 
  Matej Knopp-2 wrote:
  
   Unfortunately just a jira issue will not od that. Can't you try to
   isolate the problem?
  
   -Matej
  
   On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
  
   It's quite hard to create a quickstart project, since the project
  I'm
   working
   on is very large. But if you think that it is enough to create a
  JIRA
   task
   with the stacktrace and short description, than I'll do it.
  
   Alex
  
  
   Matej Knopp-2 wrote:
   
that's weird. could be a bug in precodition check. Can you please
create a jira entry and add a quickstart project? This might be a
corner case, I'd like to fix this asap.
   
-Matej
   
On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
   
With the latest SNAPSHOT, the application throws Exception almost
   always
:(... I thing, it has not been tested too much. Here is the
   stacktrace:
   
.apache.wicket.WicketRuntimeException: component
body:panel:actionListContainer:actionList:form:actionList:65 not
  found
   on
page ro.isdc.centerparcs.dpa.ui.page.DPADashboardPage[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:393)
 at
   
  
  org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:439)
 at
   
  
  org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139)
 at
  org.apache.wicket.RequestCycle.step(RequestCycle.java:1077)
 at
  org.apache.wicket.RequestCycle.steps(RequestCycle.java:1173)
 at
  org.apache.wicket.RequestCycle.request(RequestCycle.java:483)
 at
   
  
  org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:277)
 at
   
  
  org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:129)
 at
   
  
  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
 at
   
  
  org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at
   
  
  org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
 at
   
  
  org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
 at
   
  
  org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
 at
   
  
  org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
 at
   
  
  org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
 at
   
  
  org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
 at
   
  
  org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
 at
   
  
  org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
 at
   
  
  

Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?

2007-09-06 Thread Igor Vaynberg
the reason for it being final is that the super.onbeforerender() call HAS to
be done last, otherwise new items do not get onbeforerender called on them.

so if we remove final will you remember to always call it last? i think the
chances are that are pretty small, thus its final.

-igor


On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:


 I've grabbed the latest SNAPSHOT from the repository and have noticed that
 AbstractRepeater#onBeforeRender is final. I wonder what is the reason for
 this? (I need to do something in it's subclass)
 /**
  * @see org.apache.wicket.Component#onBeforeRender()
  */
 protected final void onBeforeRender()
 {
 if (isVisibleInHierarchy())
 {
 onPopulate();
 }
 super.onBeforeRender();
 }

 Alex
 --
 View this message in context:
 http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Re: How to set wicket's locale?

2007-09-06 Thread Igor Vaynberg
 sushi


-igor


On 9/6/07, Martijn Dashorst [EMAIL PROTECTED] wrote:

 new PropertyModel(Page.this, session.foo.sushi.bar);

 ?


 On 9/6/07, Gabor Szokoli [EMAIL PROTECTED] wrote:
  On 9/5/07, Johan Compagner [EMAIL PROTECTED] wrote:
   can  you make an jira issue for this?
 
  https://issues.apache.org/jira/browse/WICKET-936
 
  Any ideas on encapsulating the session as a propertymodel for components
 in 1.2?
 
 
  Gabor
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


 --
 Buy Wicket in Action: http://manning.com/dashorst
 Apache Wicket 1.3.0-beta3 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Re: YAML / Wicket integration

2007-09-06 Thread Johannes Schneider

Yes, you are right. All integration is just about adding something  :-) .
The benefit of integration projects is that they care about the 
integration. You don't have to manually download and install all those 
resources.
But of couse you don't have to use it. Just add the CSS resources 
manually. :-)



Johannes Schneider

Alex Objelean wrote:

I like the idea of the YAML or YUI grids. It's aim is to simplify CSS
development. But I do not see any reason to create this kind of projects
(wicket-yaml, wicket-yui-grids, etc) which integrates css frameworks.
All integration is about, is just to add some CSS resources to you web page
and that's it.


Johannes Schneider-3 wrote:

Hi,

I have created a small project that integrates the great CSS framework 
YAML (http://www.yaml.de/en/home.html) into Wicket. As I am new to 
Wicket I really appreciate every feedback I could get.


Project home page:

http://cedarsoft.org/wicket/yaml-integration/index.html

Download link:

http://build.cedarsoft.de:8111/guestAuth/repository/download/bt14/.lastSuccessful/yaml-integration/target/yaml-integration-all.jar



Regards,

Johannes Schneider

 





--
Johannes Schneider
Im Lindenwasen 15
72810 Gomaringen

Fon +49 7072 9229972
Fax +49 7072 50
Mobil +49 178 1364488

[EMAIL PROTECTED]
http://www.johannes-schneider.info


smime.p7s
Description: S/MIME Cryptographic Signature


Re: YAML / Wicket integration

2007-09-06 Thread Johannes Schneider

The source code is available:

https://svn.cedarsoft.eu/open/eu.cedarsoft.wicket/trunk/yaml-integration/


Jan Mikkelsen wrote:

Hi Johannes

I think YAML looks extremely interesting. I did not know about it. But 
commenting on your framework is difficult without sourcecode.


Best regards,
Jan Mikkelsen

Johannes Schneider wrote:

Hi,

I have created a small project that integrates the great CSS framework 
YAML (http://www.yaml.de/en/home.html) into Wicket. As I am new to 
Wicket I really appreciate every feedback I could get.


Project home page:

http://cedarsoft.org/wicket/yaml-integration/index.html

Download link:

http://build.cedarsoft.de:8111/guestAuth/repository/download/bt14/.lastSuccessful/yaml-integration/target/yaml-integration-all.jar 





Regards,

Johannes Schneider



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
Johannes Schneider
Im Lindenwasen 15
72810 Gomaringen

Fon +49 7072 9229972
Fax +49 7072 50
Mobil +49 178 1364488

[EMAIL PROTECTED]
http://www.johannes-schneider.info


smime.p7s
Description: S/MIME Cryptographic Signature


And The Fastest Growing Web Framework Is...

2007-09-06 Thread cowwoc

This might be of interest to the Wicket community:

http://www.javalobby.org/java/forums/t101110.html
-- 
View this message in context: 
http://www.nabble.com/And-The-Fastest-Growing-Web-Framework-Is...-tf4392768.html#a12524620
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: applicationwide datePattern

2007-09-06 Thread Dipu Seminlal
try using session.setLocale()
thats how i do it.

Regards
Dipu

On 9/6/07, Korbinian Bachl [EMAIL PROTECTED] wrote:


 Hi,

 can anyone tell me how to change the default date pattern wicket should
 use in the whole app?

 I mean i can do:

 add(new DatePicker() {
  protected String getDatePattern() {
  return dd.MM.;
  }

 on each component manually, but that doesnt seem to be the right way.

 Regards,

 Korbinian


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?

2007-09-06 Thread Igor Vaynberg
a javadoc warning wont stop emails coming to this list :)

onbeforerendercalled() is also an ugly way, uglier then onpopulate() which
is at least more semantically named.

the root problem is that java does not contain a compiler directive that
would check for this, there is some support for this in JSR305, but who
knows when that will come to fruition. until then the only sure way to do
this is to make the method final :|

-igor


On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:


 The way I do it, is this:

 protected void onBeforeRender() {
 //my init code
 super.onBeforeRender();
 }

 I think it can be documented in the javadoc, that it is mandatory to call
 super at the end.
 User can also have a problem if just override the onBeforeRender without
 calling the super.

 I think, there is a lack of another life-cycle method which would not
 force
 user to call super. Something like the below:

 protected void onBeforeRender() {
 onBeforeRenderCalled()
 super.onBeforeRender();
 }

 where
 onBeforeRenderCalled()
 is an empty method which would allow user to add his init logic.

 Alex.




 igor.vaynberg wrote:
 
  the reason for it being final is that the super.onbeforerender() call
 HAS
  to
  be done last, otherwise new items do not get onbeforerender called on
  them.
 
  so if we remove final will you remember to always call it last? i think
  the
  chances are that are pretty small, thus its final.
 
  -igor
 
 
  On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
 
 
  I've grabbed the latest SNAPSHOT from the repository and have noticed
  that
  AbstractRepeater#onBeforeRender is final. I wonder what is the reason
 for
  this? (I need to do something in it's subclass)
  /**
   * @see org.apache.wicket.Component#onBeforeRender()
   */
  protected final void onBeforeRender()
  {
  if (isVisibleInHierarchy())
  {
  onPopulate();
  }
  super.onBeforeRender();
  }
 
  Alex
  --
  View this message in context:
 
 http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12524545
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?

2007-09-06 Thread Johan Compagner
I take the discussion is about removing onPopulate now?
why not keep onPopulate and remove the final?


On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:

 the reason for it being final is that the super.onbeforerender() call HAS
 to
 be done last, otherwise new items do not get onbeforerender called on
 them.

 so if we remove final will you remember to always call it last? i think
 the
 chances are that are pretty small, thus its final.

 -igor


 On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
 
 
  I've grabbed the latest SNAPSHOT from the repository and have noticed
 that
  AbstractRepeater#onBeforeRender is final. I wonder what is the reason
 for
  this? (I need to do something in it's subclass)
  /**
   * @see org.apache.wicket.Component#onBeforeRender()
   */
  protected final void onBeforeRender()
  {
  if (isVisibleInHierarchy())
  {
  onPopulate();
  }
  super.onBeforeRender();
  }
 
  Alex
  --
  View this message in context:
 
 http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 



Re: DIV TAG HEADER DO NOT WORK IN WICKET

2007-09-06 Thread Johan Compagner
TSEE IS THAT AS LOUD AS YOU CAN GET?

On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:

 WHAT IS WRONG WITH IT?

 -IGOR

 On 9/6/07, bhupat parmar [EMAIL PROTECTED] wrote:
 
  THE HEADER IS NOT WORKING
 
 
  DIV id=header
  UL
LIA href=# wicket:id=homeLinkHome/A/LI
LI id=current wicket:id=trendArchiveA href=#Trend
  Archive/A/LI
LIA href=# wicket:id=latestLookLink The Latest
  Looks/A/LI
LI class=advanced wicket:id=pepsiStyleLinkA
  href=#Pepsi
  Style/A /LI
LIA href=# wicket:id=myClosetLinkMy Closet/A /LI
LIA href=# wicket:id=submitStyleLinkSubmit Style
  /A/LI
  /UL
/DIV/td
 



Re: And The Fastest Growing Web Framework Is...

2007-09-06 Thread C. Bergström
On 9/6/07, cowwoc [EMAIL PROTECTED] wrote:
 This might be of interest to the Wicket community:

   
If you really think about this.. It just means that it takes more
developers (jobs) in order to accomplish the same thing it takes with
just a handful of wicket developers :P   So I guess if you're in the
perspective of
out-of-work-can't-find-a-job-what-should-I-learn-because-wicket-was-too-hard
then I guess it's interesting.. *cough* not..

** All meant in good (attempted) humour.. please ignore :) **

./C

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: And The Fastest Growing Web Framework Is...

2007-09-06 Thread Johan Compagner
http://www.indeed.com/jobtrends?q=java%2C+jsfl=

java is all you need to know for wicket
so jsf seems pretty low to me in that picture..

On 9/6/07, cowwoc [EMAIL PROTECTED] wrote:


 This might be of interest to the Wicket community:

 http://www.javalobby.org/java/forums/t101110.html
 --
 View this message in context:
 http://www.nabble.com/And-The-Fastest-Growing-Web-Framework-Is...-tf4392768.html#a12524620
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Re: DIV TAG HEADER DO NOT WORK IN WICKET

2007-09-06 Thread cwilkes

UR RIGHT.  THE DIFFERENCE BETWEEN XHTML AND HTML IS THAT ATTRIBUTES MUST BE
QUOTED:
  http://www.w3.org/TR/xhtml1/#diffs



Nino Saturnino Martinez Vazquez Wael wrote:
 
 hmm should'nt it be in  or '' like this:
 div id=header?
 
 regards Nino
 
 bhupat parmar wrote:
 THE HEADER IS NOT WORKING


 DIV id=header
 
-- 
View this message in context: 
http://www.nabble.com/DIV-TAG-HEADER-DO-NOT-WORK-IN-WICKET-tf4392231.html#a12525267
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Wicket libraries

2007-09-06 Thread Al Maw

Robo wrote:

Ok, seems removing \wicket-velocity-1.3.0-beta3.jar\ from build
path solved problem with velocity problem. But please explain me why
removing package from build path solves the problem if nowhere in my
Hello World code i call for any of the velocity packages. Is there
some duplicities in packages or what?


I expect because Wicket looks on the classpath for Wicket modules to 
initialise, finds some in that JAR, tries to and then can't find one of 
its dependencies.


Modern Java apps tend to be complex beasts, with lots of dependencies. 
If you insist on managing these manually, you can expect to have a fair 
bit of work to do. That's why things like Ivy and Maven 2 were invented.



As to Maven2. It seems that like you in some way force developers to Maven2. :-)


No, not at all. But if you've deliberately chosen to manage your 
dependencies manually when there are perfectly good ways of doing it 
automatically, then we're not going to hold your hand for you. We don't 
get paid to do this, you know.


If you don't like Maven 2 no one is forcing you to use it. Use Ivy 
instead. Or use the standalone Maven 2 Ant tasks for doing dependencies.


Alternatively, install Maven 2, use it to build a quickstart WAR file 
with all the things you need, and then grab the JARs from there.


Any of these options would take you a tenth of the time you've spent 
bitching on this mailing list.



Yes Maven solves you some problems with dependecies and also si
suitable for small project but at big projects it definitely fails.
:-/


So Geronimo is a small project? And Jetty? And Apache Directory Server? 
And Wicket for that matter? And the several-hundreds-of-thousands-of- 
lines, 200+ dependencies projects we have here that use it? Jeez - I may 
have a high horse, but yours is scraping the stratosphere. Sure, it has 
some issues, but so does anything complex.


The simple point is that for most people, Ivy or Maven 2 do what they 
want it to do. If you don't like any of these automated tools and insist 
on doing it all manually, you can't expect us to have all that much time 
for you, as we don't get paid to do this, you know. It's like you're 
complaining that there's no documentation on how to hammer in a nail 
using a screwdriver.



So please. I know you have lot of work with wicket, and as users can

see you have a good aproach. But please do spend some time to at least
write one chapter about libraries, neede dependencies and so on. If you
have licensing problems just make one clear site with core libs link,
dep libs link and explanation what feature they are enabling and so on.
And make some quick start page in which you explainn dependecies on
simple sample app :-)Do not take alibistic aproach of hiding everithing
besides Maven. :-)

Why don't you write a wiki page for us?

Despite the fact I'm not being paid to be your tech support, I've taken 
some time out to give you a text file exhaustively detailing the 
required dependencies for each of our modules, including the transitive 
ones. I have done the work for you (not that you've even murmured a 
thank you), so why are you still bitching about it?



Al
--
Alastair Maw
Wicket-biased blog at http://herebebeasties.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Twice Behavior on the same event handler (wicket 1.2.x)

2007-09-06 Thread Scott Swank
Would it make sense to have a behavior that was implemented as a Chain
of Responsibility

http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern

Then it would just be a matter of adding that behavior to your component.


On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:

 I am curious, what is your use case for chaining behaviors?
 I think that if you have two things that you want to chain, then chain them
 in the same handler, or use decorator to add the client-side code.

 Alex


 paolo di tommaso wrote:
 
  Carlos,
 
  Can you provide an example of your custom implementation of chained
  behaviour?
 
 
  Thanks, Paolo
 
 
  On 9/6/07, Carlos Pita [EMAIL PROTECTED] wrote:
 
   Currently people will have to build it in themselves like you did. We
   can investigate whether this can be improved for future versions, but
 
  From my own experience I wouldn't say that wicket should support this.
  It's too easy to write it yourself just to fit your specific needs,
  and otoh seems difficult to predict and support a significant number
  of possible use cases in a general way that keeps everyone happy, as
  you remarked.
 
  Regards,
  Carlos
 
  
   Eelco
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 

 --
 View this message in context: 
 http://www.nabble.com/Twice-Behavior-on-the-same-event-handler-%28wicket-1.2.x%29-tf4386351.html#a12518265
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-- 
Scott Swank
reformed mathematician

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: And The Fastest Growing Web Framework Is...

2007-09-06 Thread Thomas Singer
Well, such charts do not make me fear to placed the bet on the wrong horse. 
I've taken a look at a large number of frameworks and found Wicket to be the 
best one for our purposes. This cannot be changed by such charts, but only 
by JSF being better than Wicket.


In Germany, the best sold car is the VW Golf. But does this mean I should 
buy one? No, there are a lot of better alternatives (in the meaning of 
quality and design, for example).


Cheers,
Tom

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: And The Fastest Growing Web Framework Is...

2007-09-06 Thread Johan Compagner

 In Germany, the best sold car is the VW Golf. But does this mean I should
 buy one? No, there are a lot of better alternatives (in the meaning of
 quality and design, for example).



really? i thought it was German Build Quality! The best there is!
Are there even better? (don't mention now ofcourse other german brands ;) )


Re: Re: Wicket libraries stack trace

2007-09-06 Thread Eelco Hillenius
On 06 Sep 2007 11:44:56 +0200 (CEST), Robo [EMAIL PROTECTED] wrote:
 Ok Thnaks for explanation.

 And do not look for truth in jokes. Jokes are just jokes ;-)

But you are not using Velocity panel right? Why do you include that
jar in the first place? You can just include the core wicket jar.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Re: Re: Wicket libraries stack trace

2007-09-06 Thread Robo
And why not? Besides that Wicket is doing some initialization of not used 
libraries is there any restriction of not including not neccesary libraries in 
classpath? Most time I develop someting I have many libraries in my classpath 
even if I do not use them ...

Robo


- Originálna Správa -
Od: \Eelco Hillenius\  
Komu:  
Poslaná: 06.09.2007 18:09 
Predmet: Re: Re: Wicket libraries stack trace

 On 06 Sep 2007 11:44:56 +0200 (CEST), Robo  wrote:
  Ok Thnaks for explanation.
 
  And do not look for truth in jokes. Jokes are just jokes ;-)
 
 But you are not using Velocity panel right? Why do you include that
 jar in the first place? You can just include the core wicket jar.
 
 Eelco
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


__
Mozaika storočia denníka SME - http://mozaika.sme.sk



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: And The Fastest Growing Web Framework Is...

2007-09-06 Thread Eelco Hillenius
 really? i thought it was German Build Quality! The best there is!
 Are there even better? (don't mention now ofcourse other german brands ;) )

Trabant is German :)

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Re: Re: Wicket libraries stack trace

2007-09-06 Thread Eelco Hillenius
On 06 Sep 2007 17:23:13 +0200 (CEST), Robo [EMAIL PROTECTED] wrote:
 And why not? Besides that Wicket is doing some initialization of not used 
 libraries is there any restriction of not including not neccesary libraries 
 in classpath? Most time I develop someting I have many libraries in my 
 classpath even if I do not use them ...

Because you seem to be running into trouble with your dependencies. If
you include wicket-velocity, you need Velocity (which you could have
guessed from the name of the project) and any dependencies Velocity
has. If don't include wicket-velocity, you don't need Velocity. It's
that simple.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: How to set wicket's locale?

2007-09-06 Thread Evan Chooly
T-37 minutes until sushi time!

On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:

  sushi


 -igor


 On 9/6/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
 
  new PropertyModel(Page.this, session.foo.sushi.bar);
 
  ?
 
 
  On 9/6/07, Gabor Szokoli [EMAIL PROTECTED] wrote:
   On 9/5/07, Johan Compagner [EMAIL PROTECTED] wrote:
can  you make an jira issue for this?
  
   https://issues.apache.org/jira/browse/WICKET-936
  
   Any ideas on encapsulating the session as a propertymodel for
 components
  in 1.2?
  
  
   Gabor
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
 
  --
  Buy Wicket in Action: http://manning.com/dashorst
  Apache Wicket 1.3.0-beta3 is released
  Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 



Re: Wicket problem with slf4j 1.4

2007-09-06 Thread Ceki Gulcu
Tauren Mills tauren at tauren.com writes:

 
 Thanks everyone for the help.  I got it working with the following jars:
 
 log4j-1.2.15.jar
 slf4j-api-1.4.2.jar
 slf4j-log4j12-1.4.2.jar
 
 Is that what others are using?
 
 I had troubles while using logback, but I may not have used the right
 jars or got the configuration right.  It seemed that Jetty was having
 troubles and throwing exceptions.  What is the right combination of
 jars to use with logback?
 
 Tauren

That looks correct for the SLF4J/log4j combo. For the SLF4J/logback combo, you
would need

slf4j-api-1.4.3.jar (1.4.2 is OK too)
logback-core-0.9.8.jar
logback-classic-0.9.8.jar

I hope this helps,








-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Re: Wicket libraries

2007-09-06 Thread Eelco Hillenius
 Java jars are nto at all complex beast. They become tricky in situation where 
 you just put some of them inclasspath and they do what you normally do not 
 expect. Lib should be lib and when not called by developer they should do 
 nothing. Deliberatly breaking this rule makes the jars, beast ... :-)

Sorry, but that is b.s. Could you point me where this 'rule' is
defined? You bet you can have troubles if you just mindlessly include
all kinds of jars. Furthermore, what is your whole point of having to
include jars you are not using? If you would be using them, you'd need
those other dependencies, period.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Re: Re: Re: Wicket libraries stack trace

2007-09-06 Thread Robo
After small troubles I had with it I know it. But from my point of view it is 
not correct to initiatie not used libraries just by including it in App Server 
classpath. From my point of view lib is lib, and when nto called by developer 
it sould not be initiated by App server. I runned into troubles with 
dependecies SELF initialized itself. I saw this behaviur several times before 
but everytime I`m suprised. As I said from my point of view, lib is lib. But 
this guides me to troubles :-) But to be concrete I need to develop demo app 
using fove frameworks, not using Maven :-), so I put every lib in wicket into 
lib dir to not to solve missing lib troubles when building demo app. But it 
raised contrary, unnessesary \self living\ lib problem.

So Eelco we could probably close this thread as my troubles with Hello World 
are solved, now begins the trouble with demo app.

So thanks for help and good product. Demo app will be presented week after next 
week so we`ll see hov wicket compares to other frameworks.

Robo


- Originálna Správa -
Od: \Eelco Hillenius\  
Komu:  
Poslaná: 06.09.2007 18:17 
Predmet: Re: Re: Re: Wicket libraries stack trace

 On 06 Sep 2007 17:23:13 +0200 (CEST), Robo  wrote:
  And why not? Besides that Wicket is doing some initialization of not used 
  libraries is there any restriction of not including not neccesary libraries 
  in classpath? Most time I develop someting I have many libraries in my 
  classpath even if I do not use them ...
 
 Because you seem to be running into trouble with your dependencies. If
 you include wicket-velocity, you need Velocity (which you could have
 guessed from the name of the project) and any dependencies Velocity
 has. If don\'t include wicket-velocity, you don\'t need Velocity. It\'s
 that simple.
 
 Eelco
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


__
Sprievodca herným svetom - http://hry.sme.sk/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Re: Re: Re: Wicket libraries stack trace

2007-09-06 Thread Eelco Hillenius
On 06 Sep 2007 18:11:09 +0200 (CEST), Robo [EMAIL PROTECTED] wrote:
 After small troubles I had with it I know it. But from my point of view it is 
 not correct to initiatie not used libraries just by including it in App 
 Server classpath. From my point of view lib is lib, and when nto called by 
 developer it sould not be initiated by App server. I runned into troubles 
 with dependecies SELF initialized itself. I saw this behaviur several times 
 before but everytime I`m suprised. As I said from my point of view, lib is 
 lib. But this guides me to troubles :-) But to be concrete I need to develop 
 demo app using fove frameworks, not using Maven :-), so I put every lib in 
 wicket into lib dir to not to solve missing lib troubles when building demo 
 app. But it raised contrary, unnessesary \self living\ lib problem.

You can't really depend on libs following such rules. All sorts of
frameworks do this, from Guice to Seam to logging libraries, and it
can get you in trouble with XML handling as well. As a general rule,
only include what you need.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Twice Behavior on the same event handler (wicket 1.2.x)

2007-09-06 Thread Carlos Pita
Alex:
We implemented a subclass of Form that has some sophisticated
validation and customized feedback panels built-in. This form
automatically instruments its fields with an ajax  validating
behavior. But sometimes -not that often- a field needs to ajax-do a
bit more than just being validated, so this extra behavior is passed
as a handler that knows how to react onSubmit and onError. Well, to
the point: at first we implemented this extra behavior as sort of
chained behavior, but then, as we found out that this generality was
adding extra complexity and didn't really pay off, we moved out to a
simpler schema with a handler implementing an onSubmit/onError
barebones interface, to which the only behavior delegates at last. So
now there is only one behavior and nothing that resembles a chain. In
part, that's the reason why I feel that such a functionality is out of
the scope of a general framework/toolkit as wicket is.

Regards,
Carlos

On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:

 I am curious, what is your use case for chaining behaviors?
 I think that if you have two things that you want to chain, then chain them
 in the same handler, or use decorator to add the client-side code.

 Alex


 paolo di tommaso wrote:
 
  Carlos,
 
  Can you provide an example of your custom implementation of chained
  behaviour?
 
 
  Thanks, Paolo
 
 
  On 9/6/07, Carlos Pita [EMAIL PROTECTED] wrote:
 
   Currently people will have to build it in themselves like you did. We
   can investigate whether this can be improved for future versions, but
 
  From my own experience I wouldn't say that wicket should support this.
  It's too easy to write it yourself just to fit your specific needs,
  and otoh seems difficult to predict and support a significant number
  of possible use cases in a general way that keeps everyone happy, as
  you remarked.
 
  Regards,
  Carlos
 
  
   Eelco
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 

 --
 View this message in context: 
 http://www.nabble.com/Twice-Behavior-on-the-same-event-handler-%28wicket-1.2.x%29-tf4386351.html#a12518265
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Re: Re: Wicket libraries

2007-09-06 Thread Robo
Sorry Eelco but me and also quite a lot of other developers(I know, contrary to 
others developers) consider same b.s. libraries which are \alive\ just 
because they are in classpath. It is like talking when nobody asks you ... Look 
at Java SDK do you need all packages to build console \Hello World!\ No. And 
who cares. They are just there and do their stuff when needed. So why 
wicket-velocity is doing job developer do not want and did not asked to. Where 
is writen that I cannot put mindesly tens of useles libs when they just sit 
there, assuming of course the packages are not duplicating. Do you understand 
why there are packages Eelco. Unles the class is uniqeu develioper should not 
be afreaid of using other class he wanted. To push your false premise to edge, 
why you deliberatly put all packages and classes into jar when you need just 
few of them also with dependencies. Isn`t it b.s.? Yes it is .. and also it is 
not conceptual ... Do not make zombie libraries and there will
  be no problem with dependecies. Got the point? If not I`m not alble not help 
you sorry ...

Robo 


- Originálna Správa -
Od: \Eelco Hillenius\  
Komu:  
Poslaná: 06.09.2007 18:59 
Predmet: Re: Re: Wicket libraries

  Java jars are nto at all complex beast. They become tricky in situation 
  where you just put some of them inclasspath and they do what you normally 
  do not expect. Lib should be lib and when not called by developer they 
  should do nothing. Deliberatly breaking this rule makes the jars, beast ... 
  :-)
 
 Sorry, but that is b.s. Could you point me where this \'rule\' is
 defined? You bet you can have troubles if you just mindlessly include
 all kinds of jars. Furthermore, what is your whole point of having to
 include jars you are not using? If you would be using them, you\'d need
 those other dependencies, period.
 
 Eelco
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


__
Najoriginalnejsie technologicke hracky - http://pocitace.sme.sk/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?

2007-09-06 Thread Igor Vaynberg
because the final is there for a very important reason?

-igor


On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:

 I take the discussion is about removing onPopulate now?
 why not keep onPopulate and remove the final?


 On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
 
  the reason for it being final is that the super.onbeforerender() call
 HAS
  to
  be done last, otherwise new items do not get onbeforerender called on
  them.
 
  so if we remove final will you remember to always call it last? i think
  the
  chances are that are pretty small, thus its final.
 
  -igor
 
 
  On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
  
  
   I've grabbed the latest SNAPSHOT from the repository and have noticed
  that
   AbstractRepeater#onBeforeRender is final. I wonder what is the reason
  for
   this? (I need to do something in it's subclass)
   /**
* @see org.apache.wicket.Component#onBeforeRender()
*/
   protected final void onBeforeRender()
   {
   if (isVisibleInHierarchy())
   {
   onPopulate();
   }
   super.onBeforeRender();
   }
  
   Alex
   --
   View this message in context:
  
 
 http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
   Sent from the Wicket - User mailing list archive at Nabble.com.
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 



Re: DIV TAG HEADER DO NOT WORK IN WICKET

2007-09-06 Thread Igor Vaynberg
I JUST LOVED HIS POST BECAUSE HE DOESNT SAY WHAT IS BROKEN. ID HATE TO SEE
HIS BUG REPORTS.

-IGOR


On 9/6/07, cwilkes [EMAIL PROTECTED] wrote:


 UR RIGHT.  THE DIFFERENCE BETWEEN XHTML AND HTML IS THAT ATTRIBUTES MUST
 BE
 QUOTED:
   http://www.w3.org/TR/xhtml1/#diffs



 Nino Saturnino Martinez Vazquez Wael wrote:
 
  hmm should'nt it be in  or '' like this:
  div id=header?
 
  regards Nino
 
  bhupat parmar wrote:
  THE HEADER IS NOT WORKING
 
 
  DIV id=header
 
 --
 View this message in context:
 http://www.nabble.com/DIV-TAG-HEADER-DO-NOT-WORK-IN-WICKET-tf4392231.html#a12525267
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Re: How to set wicket's locale?

2007-09-06 Thread Igor Vaynberg
you suck!

-igor


On 9/6/07, Evan Chooly [EMAIL PROTECTED] wrote:

 T-37 minutes until sushi time!

 On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
 
   sushi
 
 
  -igor
 
 
  On 9/6/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
  
   new PropertyModel(Page.this, session.foo.sushi.bar);
  
   ?
  
  
   On 9/6/07, Gabor Szokoli [EMAIL PROTECTED] wrote:
On 9/5/07, Johan Compagner [EMAIL PROTECTED] wrote:
 can  you make an jira issue for this?
   
https://issues.apache.org/jira/browse/WICKET-936
   
Any ideas on encapsulating the session as a propertymodel for
  components
   in 1.2?
   
   
Gabor
   
   
 -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
  
  
   --
   Buy Wicket in Action: http://manning.com/dashorst
   Apache Wicket 1.3.0-beta3 is released
   Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 



Re: Re: Re: Re: Re: Wicket libraries stack trace

2007-09-06 Thread Robo
Yes I know Eelco. That is why there are so much troubles in Java programming 
land. Misusing of basic concepts ... That is why one needs some sort of COC, 
because there is lot`s of b.s. around ... J2EE 1.4 countained so much of it 
that lots of developers refused to use it And it had to be rewriten ... Apache 
Struts ... JSF ... Why did you started Wicket? Did`nt you wrote that MVC is 
kind of missconceptin? And I ask you Who told that? Eelco Hilenius? Yes and you 
were probably right. And in that time you with the tapestry was alone against 
the JSF Struts community. So accpet pleace that someone else is seeing 
miisconceptions and b.s. in other aspetcs of java programming and habits. OK? 
:-)

Can we finish? As you can see I do not share view of major java programmers but 
accepting the situation ... :-))

Robo


- Originálna Správa -
Od: \Eelco Hillenius\  
Komu:  
Poslaná: 06.09.2007 19:08 
Predmet: Re: Re: Re: Re: Wicket libraries stack trace

 On 06 Sep 2007 18:11:09 +0200 (CEST), Robo  wrote:
  After small troubles I had with it I know it. But from my point of view it 
  is not correct to initiatie not used libraries just by including it in App 
  Server classpath. From my point of view lib is lib, and when nto called by 
  developer it sould not be initiated by App server. I runned into troubles 
  with dependecies SELF initialized itself. I saw this behaviur several times 
  before but everytime I`m suprised. As I said from my point of view, lib is 
  lib. But this guides me to troubles :-) But to be concrete I need to 
  develop demo app using fove frameworks, not using Maven :-), so I put every 
  lib in wicket into lib dir to not to solve missing lib troubles when 
  building demo app. But it raised contrary, unnessesary \\\self living\\\ 
  lib problem.
 
 You can\'t really depend on libs following such rules. All sorts of
 frameworks do this, from Guice to Seam to logging libraries, and it
 can get you in trouble with XML handling as well. As a general rule,
 only include what you need.
 
 Eelco
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


__
Mozaika storočia denníka SME - http://mozaika.sme.sk



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?

2007-09-06 Thread Johan Compagner
please tell me, tell me!

johan


On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:

 because the final is there for a very important reason?

 -igor


 On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
 
  I take the discussion is about removing onPopulate now?
  why not keep onPopulate and remove the final?
 
 
  On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
  
   the reason for it being final is that the super.onbeforerender() call
  HAS
   to
   be done last, otherwise new items do not get onbeforerender called on
   them.
  
   so if we remove final will you remember to always call it last? i
 think
   the
   chances are that are pretty small, thus its final.
  
   -igor
  
  
   On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
   
   
I've grabbed the latest SNAPSHOT from the repository and have
 noticed
   that
AbstractRepeater#onBeforeRender is final. I wonder what is the
 reason
   for
this? (I need to do something in it's subclass)
/**
 * @see org.apache.wicket.Component#onBeforeRender()
 */
protected final void onBeforeRender()
{
if (isVisibleInHierarchy())
{
onPopulate();
}
super.onBeforeRender();
}
   
Alex
--
View this message in context:
   
  
 
 http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
Sent from the Wicket - User mailing list archive at Nabble.com.
   
   
   
 -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
  
 



Re: How to set wicket's locale?

2007-09-06 Thread Johan Compagner
can you send some over?

On 9/6/07, Evan Chooly [EMAIL PROTECTED] wrote:

 T-37 minutes until sushi time!

 On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
 
   sushi
 
 
  -igor
 
 
  On 9/6/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
  
   new PropertyModel(Page.this, session.foo.sushi.bar);
  
   ?
  
  
   On 9/6/07, Gabor Szokoli [EMAIL PROTECTED] wrote:
On 9/5/07, Johan Compagner [EMAIL PROTECTED] wrote:
 can  you make an jira issue for this?
   
https://issues.apache.org/jira/browse/WICKET-936
   
Any ideas on encapsulating the session as a propertymodel for
  components
   in 1.2?
   
   
Gabor
   
   
 -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
  
  
   --
   Buy Wicket in Action: http://manning.com/dashorst
   Apache Wicket 1.3.0-beta3 is released
   Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 



Re: Howto use AttributeModifier

2007-09-06 Thread Carlos Pita
Per,
use a AbstractReadOnlyModel or a DetachableLoadableModel for the
attribute value.
Regards,
Carlos

On 9/6/07, Per Newgro [EMAIL PROTECTED] wrote:
 Ok. I tried the Attribute Modifier(String, String, boolean, Model) 
 Constructor but it didn't worked. There have been exactly the same results.

 Thanks for your help
 Per
  Original-Nachricht 
  Datum: Thu, 6 Sep 2007 15:34:14 +0200
  Von: Gerolf Seitz [EMAIL PROTECTED]
  An: users@wicket.apache.org
  Betreff: Re: Howto use AttributeModifier

  you used the constructor AttributeModifer(String, String, Model), which
  only
  modifies the attribute if it's already there.
  if you use Attribute Modifier(String, String, boolean, Model), the
  attribute
  will be added to the tag in case it does not exist yet.
 
  gerolf
 
 --
 Pt! Schon vom neuen GMX MultiMessenger gehört?
 Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Howto use AttributeModifier

2007-09-06 Thread Carlos Pita
Or a PropertyModel.


On 9/6/07, Carlos Pita [EMAIL PROTECTED] wrote:
 Per,
 use a AbstractReadOnlyModel or a DetachableLoadableModel for the
 attribute value.
 Regards,
 Carlos

 On 9/6/07, Per Newgro [EMAIL PROTECTED] wrote:
  Ok. I tried the Attribute Modifier(String, String, boolean, Model) 
  Constructor but it didn't worked. There have been exactly the same results.
 
  Thanks for your help
  Per
   Original-Nachricht 
   Datum: Thu, 6 Sep 2007 15:34:14 +0200
   Von: Gerolf Seitz [EMAIL PROTECTED]
   An: users@wicket.apache.org
   Betreff: Re: Howto use AttributeModifier
 
   you used the constructor AttributeModifer(String, String, Model), which
   only
   modifies the attribute if it's already there.
   if you use Attribute Modifier(String, String, boolean, Model), the
   attribute
   will be added to the tag in case it does not exist yet.
  
   gerolf
  
  --
  Pt! Schon vom neuen GMX MultiMessenger gehört?
  Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Twice Behavior on the same event handler (wicket 1.2.x)

2007-09-06 Thread Igor Vaynberg
the problem with this stuff is that there is no single pattern that will
work

sometimes you want a chain where if a link fails the chain shortcircuits
other times you dont want the shortcircuit

sometimes you care about the order, other times you do not

there are many variations of this and they are almost impossible to
configure, so this isnt an easy problem.

-igor


On 9/6/07, Scott Swank [EMAIL PROTECTED] wrote:

 Would it make sense to have a behavior that was implemented as a Chain
 of Responsibility

 http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern

 Then it would just be a matter of adding that behavior to your component.


 On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
 
  I am curious, what is your use case for chaining behaviors?
  I think that if you have two things that you want to chain, then chain
 them
  in the same handler, or use decorator to add the client-side code.
 
  Alex
 
 
  paolo di tommaso wrote:
  
   Carlos,
  
   Can you provide an example of your custom implementation of chained
   behaviour?
  
  
   Thanks, Paolo
  
  
   On 9/6/07, Carlos Pita [EMAIL PROTECTED] wrote:
  
Currently people will have to build it in themselves like you did.
 We
can investigate whether this can be improved for future versions,
 but
  
   From my own experience I wouldn't say that wicket should support
 this.
   It's too easy to write it yourself just to fit your specific needs,
   and otoh seems difficult to predict and support a significant number
   of possible use cases in a general way that keeps everyone happy, as
   you remarked.
  
   Regards,
   Carlos
  
   
Eelco
   
   
 -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
  
 
  --
  View this message in context:
 http://www.nabble.com/Twice-Behavior-on-the-same-event-handler-%28wicket-1.2.x%29-tf4386351.html#a12518265
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


 --
 Scott Swank
 reformed mathematician

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Re: Wicket libraries

2007-09-06 Thread Xavier Hanin
You can use Ivy to resolve wicket dependencies and produce a report, if you
have trouble to generate a report with maven ATM. The report details may be
slightly different from what you get with m2, since Ivy is not 100%
compatible with m2, but it's better than nothing. If you're interested, I
can provide the build.xml to generate it (with automatic download  of Ivy so
that you only need ant 1.6+ on your box to test it). Would you be interested
as a workaround until you get maven 2 site generation working?

Xavier

On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote:

 Skinning was not a problem, just generating a coherent site with just
 one command:

 cd wicket-1.x
 mvn site:deploy

 This just doesn't work (tm).

 Martijn

 On 9/5/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
  we dont need links, just a list. and i thought the trouble was related
 to
  skinning? if thats still the case can we just put a vanilla maven site
 on
  wicket-stuff or somewhere?
 
  -igor
 
 
  On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
  
   Remember the troubles I had with generating the site? Tim was working
   on it, but it still is a long shot from being workable.
  
   And yes, it has a list of dependencies, but I don't think they
   generate a link to download each and every one of them :|
  
   Martijn
  
   On 9/5/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
why dont we generate the maven stie somewhere? doesnt that have a
 list
   of
dependencies for each module?
   
-igor
   
   
On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote:

 On 9/5/07, Al Maw [EMAIL PROTECTED] wrote:
  That said, maybe we should provide a separate ZIP with the
   dependencies.
  I guess if you're using Ivy or Maven 2, you're not going to be
  downloading the ZIP at all. There may be licensing issues with
 this,
  though. What do people think? Martijn?

 Including the deps just doesn't increase the size to a double, but
 a 5
 or 6 fold (iirc 65MB). The problem is with transitive deps that
 are
 test/compile/provided scope (for instance Spring includes just
 about
 the world).

 The best way currently is to do it as we do now IMO. The current
 direct deps are license compatible, but I really don't want to
 check
 all transitive deps for license compatibility. The current
 examples is
 already quite humongous in the dependency department.

 I have proposed a couple of weeks ago to move examples out of the
 main
 distribution, and make it a separate download, and do the same
 with
 the quickstart. The benefit would be that the license requirements
 for
 the main distribution download becomes smaller, only the stuff we
 include in the sources ourselves.

 Both the examples and quickstart would then include all necessary
 runtime deps for building a wicket application (as described in
 chapter 3 of wicket in action, and provided with wicket 1.2 until
 now). This makes them easier to provide a license file for. I just
 lack the time to make it so.

 In short: I don't like the idea of adding an all libs project and
 make
 it downloadable from Apache. We could make that a wicket stuff
 project
 though but the size would resemble downloading a whole maven
 repository.

 Martijn

 --
 Buy Wicket in Action: http://manning.com/dashorst
 Apache Wicket 1.3.0-beta3 is released
 Get it now:
 http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


   
  
  
   --
   Buy Wicket in Action: http://manning.com/dashorst
   Apache Wicket 1.3.0-beta3 is released
   Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 


 --
 Buy Wicket in Action: http://manning.com/dashorst
 Apache Wicket 1.3.0-beta3 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/


Re: Re: Wicket libraries

2007-09-06 Thread Igor Vaynberg
On 06 Sep 2007 17:35:26 +0200 (CEST), Robo [EMAIL PROTECTED] wrote:

 Stop it now please Al. You take oo personal aproach. Nobody forced you in
 responding.


heh, what you have to understand is that wicket is oss - so it IS personal.
it is something we work on in our spare time so it is kind of a hobby (a
demanding hobby). we do care about it a great deal. constructive criticism
is always welcome, but you have to have a level of respect on the lists.

You make Wicket And I`m the user. If you do not like it do not do it. But
 there is some responsibilities about product you develop towards product
 users so do not confuse roles please.


wrong again. its the other way around. if you do not like it do not use it.
we do not owe you anything. we put wicket out there for people to use, no
strings attached.

And besides that I`m also kind of customer As I paid for the book ;-)


you paid for the book, but we get nothing from that. so how do you connect
the dots?

And besides that I several times said how Wicket is great is that not enaugh
 for you? :-))


thank you.

And btw I thanked to Gvyn at the end of my troubles as his responcese solved
 them. I do not thank before my troubles gets solved ;-) I`m not teacher in
 the dance school.


its not the missing thank you, it is more your superior attitute and your
lecturing tone. so in fact you do come across as a teacher.

What I`m doing now is preparing presentation to my chiefs and currrently I`m
 coping with five frameworks amking demo apps and have two weeks for it. That
 is Why I`m not writing wiki and that is why I`m sometimes upset about lack
 of docs, working 18-20 hours per day ...


sounds like your chiefs are pretty dumb if they expect you to learn five
frameworks in two weeks, find a better job.

as for the issue at hand, i believe the velocity initializer should be
rewritten to check if whatever it needs is actually on the classpath, and
noop quietly if its not. please file a jira issue.



-igor


Java jars are nto at all complex beast. They become tricky in situation
 where you just put some of them inclasspath and they do what you normally do
 not expect. Lib should be lib and when not called by developer they should
 do nothing. Deliberatly breaking this rule makes the jars, beast ... :-)

 So Finishing this personal thread and thank you for much of your time ;-))

 Robo


 - Originálna Správa -
 Od: Al Maw
 Komu:
 Poslaná: 06.09.2007 17:44
 Predmet: Re: Wicket libraries

  Robo wrote:
   Ok, seems removing \\\wicket-velocity-1.3.0-beta3.jar\\\ from build
   path solved problem with velocity problem. But please explain me why
   removing package from build path solves the problem if nowhere in my
   Hello World code i call for any of the velocity packages. Is there
   some duplicities in packages or what?
 
  I expect because Wicket looks on the classpath for Wicket modules to
  initialise, finds some in that JAR, tries to and then can\'t find one of
  its dependencies.
 
  Modern Java apps tend to be complex beasts, with lots of dependencies.
  If you insist on managing these manually, you can expect to have a fair
  bit of work to do. That\'s why things like Ivy and Maven 2 were
 invented.
 
   As to Maven2. It seems that like you in some way force developers to
 Maven2. :-)
 
  No, not at all. But if you\'ve deliberately chosen to manage your
  dependencies manually when there are perfectly good ways of doing it
  automatically, then we\'re not going to hold your hand for you. We
 don\'t
  get paid to do this, you know.
 
  If you don\'t like Maven 2 no one is forcing you to use it. Use Ivy
  instead. Or use the standalone Maven 2 Ant tasks for doing dependencies.
 
  Alternatively, install Maven 2, use it to build a quickstart WAR file
  with all the things you need, and then grab the JARs from there.
 
  Any of these options would take you a tenth of the time you\'ve spent
  bitching on this mailing list.
 
   Yes Maven solves you some problems with dependecies and also si
   suitable for small project but at big projects it definitely fails.
   :-/
 
  So Geronimo is a small project? And Jetty? And Apache Directory Server?
  And Wicket for that matter? And the several-hundreds-of-thousands-of-
  lines, 200+ dependencies projects we have here that use it? Jeez - I may
  have a high horse, but yours is scraping the stratosphere. Sure, it has
  some issues, but so does anything complex.
 
  The simple point is that for most people, Ivy or Maven 2 do what they
  want it to do. If you don\'t like any of these automated tools and
 insist
  on doing it all manually, you can\'t expect us to have all that much
 time
  for you, as we don\'t get paid to do this, you know. It\'s like you\'re
  complaining that there\'s no documentation on how to hammer in a nail
  using a screwdriver.
 
   So please. I know you have lot of work with wicket, and as users can
  see you have a good aproach. But please do spend some time to at least
  write one 

Re: AjaxFallbackLink inside ListView

2007-09-06 Thread pokkie

Worked like a charm, thanks Kent. 

You the same Kent Tong that wrote a online Tapestry book?



Kent Tong wrote:
 
 
 
 pokkie wrote:
 
 My question is, how do I use this information to get the selected entity
 which represents a row in my listView? 
 
 
 Try:
 
 public class Test extends WebPage {
 
   public Test() {
   ListString list = Arrays.asList(new String[] { a, b, c 
 });
   ListView eachItem = new ListView(eachItem, list) {
   @Override
   protected void populateItem(ListItem item) {
   item.add(new IndicatingAjaxFallbackLink(link) 
 {
   @Override
   public void onClick(AjaxRequestTarget 
 target) {
   
 handleClick(getParent().getModelObjectAsString());
   }
 
   });
   }
   };
   add(eachItem);
   }
 
   private void handleClick(String clickedItem) {
   System.out.println(clickedItem);
   }
 }
 

-- 
View this message in context: 
http://www.nabble.com/AjaxFallbackLink-inside-ListView-tf4389622.html#a12527658
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Re: Re: Wicket libraries

2007-09-06 Thread Eelco Hillenius
On 06 Sep 2007 18:24:44 +0200 (CEST), Robo [EMAIL PROTECTED] wrote:
 Sorry Eelco but me and also quite a lot of other developers(I know, contrary 
 to others developers) consider same b.s. libraries which are \alive\ just 
 because they are in classpath. It is like talking when nobody asks you ... 
 Look at Java SDK do you need all packages to build console \Hello World!\ 
 No. And who cares. They are just there and do their stuff when needed. So why 
 wicket-velocity is doing job developer do not want and did not asked to. 
 Where is writen that I cannot put mindesly tens of useles libs when they just 
 sit there, assuming of course the packages are not duplicating. Do you 
 understand why there are packages Eelco. Unles the class is uniqeu develioper 
 should not be afreaid of using other class he wanted. To push your false 
 premise to edge, why you deliberatly put all packages and classes into jar 
 when you need just few of them also with dependencies. Isn`t it b.s.? Yes it 
 is .. and also it is not conceptual ... Do not make zombie libraries and 
 there wi
 ll
   be no problem with dependecies. Got the point? If not I`m not alble not 
 help you sorry ...

Yeah, it's not that I don't get your point, it's just that I don't
agree. What I'm saying is that you don't live in that perfect world
and not all software acts like you seem to expect. There is no rule
that you can't what we do, and Java makes it possible. AND many other
frameworks do this kind of initialization as well, so you can have the
same problem in many other occasions. Not to mention problems with
versioning and shared server libs you might have (especially with
older app server versions) if you just include every jar you come
across.

Anyway, to my knowledge, wicket-velocity is the only project that
initializes pulling in more dependencies. And as you're not using
that, we can end this discussion now.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Re: Re: Re: Re: Wicket libraries stack trace

2007-09-06 Thread Eelco Hillenius
On 06 Sep 2007 18:32:44 +0200 (CEST), Robo [EMAIL PROTECTED] wrote:
 Yes I know Eelco. That is why there are so much troubles in Java programming 
 land. Misusing of basic concepts ... That is why one needs some sort of COC, 
 because there is lot`s of b.s. around ... J2EE 1.4 countained so much of it 
 that lots of developers refused to use it And it had to be rewriten ... 
 Apache Struts ... JSF ... Why did you started Wicket? Did`nt you wrote that 
 MVC is kind of missconceptin? And I ask you Who told that? Eelco Hilenius? 
 Yes and you were probably right. And in that time you with the tapestry was 
 alone against the JSF Struts community. So accpet pleace that someone else is 
 seeing miisconceptions and b.s. in other aspetcs of java programming and 
 habits. OK? :-)

Sure. You know, if you would just try to have a little bit more of a
constructive tone... I'm sure we can patch wicket-velocity so that it
avoids pulling in Velocity too early. And maybe the project tries to
do too much upfront. Should be pretty easy to fix if you want to
create a JIRA issue for it.

About calling initializers (that's what triggers Velocity loading in
this case), the feature is generally nice. We can use it to e.g.
automatically register shared resources or like wicket-jmx does,
register resources, so that to enable functionality in that lib is as
easy as dropping in a jar. That's pretty cool functionality in my
book.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Twice Behavior on the same event handler (wicket 1.2.x)

2007-09-06 Thread Eelco Hillenius
On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
 the problem with this stuff is that there is no single pattern that will
 work

 sometimes you want a chain where if a link fails the chain shortcircuits
 other times you dont want the shortcircuit

 sometimes you care about the order, other times you do not

 there are many variations of this and they are almost impossible to
 configure, so this isnt an easy problem.

Yeah, that's the problem. Maybe if we would make the kind of chaining
dependent on the attribute values? Furthermore, AttributeModifier and
SimpleAttributeModifier are two convenience classes, but you can do
the same by e.g. directly implementing IBehavior, not to mention the
AjaxBehaviors that directly change attributes. Which makes that any
chaining would be hard to get water proof.

It's probably not completely impossible though. If someone can make a
good proposal (with working code!) :)

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?

2007-09-06 Thread Johan Compagner
and?
why can't AbstractRepeater.onBeforeRender() be not final?
If i overwrite to do what ever i want (but i do need to call onBeforeRender
at some point else we generate an error)
then it comes in AbstractRepeater.onBeforeRender()
that first does the onPopulate so the items are created and then calls the
super..
That i can never change even if onBeforeRender is not final..

johan


On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:

 since component.onbeforerender() is what cascades the onbeforerender()
 call
 to the children, when it comes to repeaters it is absolutely vital that
 super.onbeforerender() be called last, that way it will cascade to any new
 items added in repeater's onbeforerender().

 -igor

 On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
 
  please tell me, tell me!
 
  johan
 
 
  On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
  
   because the final is there for a very important reason?
  
   -igor
  
  
   On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
   
I take the discussion is about removing onPopulate now?
why not keep onPopulate and remove the final?
   
   
On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:

 the reason for it being final is that the super.onbeforerender()
  call
HAS
 to
 be done last, otherwise new items do not get onbeforerender called
  on
 them.

 so if we remove final will you remember to always call it last? i
   think
 the
 chances are that are pretty small, thus its final.

 -igor


 On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
 
 
  I've grabbed the latest SNAPSHOT from the repository and have
   noticed
 that
  AbstractRepeater#onBeforeRender is final. I wonder what is the
   reason
 for
  this? (I need to do something in it's subclass)
  /**
   * @see org.apache.wicket.Component#onBeforeRender()
   */
  protected final void onBeforeRender()
  {
  if (isVisibleInHierarchy())
  {
  onPopulate();
  }
  super.onBeforeRender();
  }
 
  Alex
  --
  View this message in context:
 

   
  
 
 http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
 
   -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

   
  
 



Re: @SpringBean and serialization checker

2007-09-06 Thread Johan Compagner
the custom serialization is already off by default for quite some time
the
org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException:
only kicks in (so also for the default) when an IOException happens with
writeObject
So that you get a nice trace which field it exactly is of what object.

johan




On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:

 i dont think our custom serialization works right with proxies yet is the
 thing

 -igor


 On 9/6/07, leok [EMAIL PROTECTED] wrote:
 
 
  It's a little hard for me to tear out all the @SpringBean declarations
 in
  my
  webapp. I could try using the standard serialization method you speak of
  and
  monitor the behavior. It seemed a little strange that this Exception
 would
  pop up with such a basic config so I figured that I was missing
 something.
 
 
  igor.vaynberg wrote:
  
   so if you remove @SpringBean dao the errors go away?
  
   it def shouldnt be happening, maybe its a problem in wicket's custom
   serialization. there is a way to make wicket use standard
   serialization...cant remember off the top of my head right now...
  
   -igor
  
   On 9/6/07, leok [EMAIL PROTECTED] wrote:
  
  
   Hi,
  
   I'm using the @SpringBean + SpringComponentInjector to inject daos in
  my
   Wicket web pages. With Wicket 1.3b3, I'm noticing the following
  exception
   in
   my Tomcat (v6.0.13) logs:
  
  
  
 
 org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException:
   Unable to serialize class: org.apache.commons.dbcp.BasicDataSource
  
   This exception occurs randomly and emerges from different page
 objects
   while
   browsing my webapp (probably SecondLevelSessionCache behavior?) and,
 if
   session persistence is enabled, at app shutdown. Nowhere in my
   application
   am I using the BasicDataSource class explicitly except in my
 beans.xml
   datasource configuration.
  
   My understanding was that a LazyInitProxyFactory would be serialized
 in
   place of the dao if the @SpringBean annotation were used. The page in
   which
   this occurred has a single @SpringBean private MyDao myDao; member
   field
   in it. I have no daos -- injected or otherwise -- in my WebSession
   instances.
  
   Is there some other configuration issue I'm missing? Or is this
  expected
   behavior? I'm relatively new to Spring and Wicket so the former is
  likely
   possible.
  
   Thanks!
   leo
  
   --
   View this message in context:
  
 
 http://www.nabble.com/%40SpringBean-and-serialization-checker-tf4392171.html#a12522589
   Sent from the Wicket - User mailing list archive at Nabble.com.
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
  
 
  --
  View this message in context:
 
 http://www.nabble.com/%40SpringBean-and-serialization-checker-tf4392171.html#a12524903
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 



Re: applicationwide datePattern

2007-09-06 Thread Korbinian Bachl

that worked - thank you

Best Regards,

Korbinian

Francis De Brabandere schrieb:

You can override newConverterLocator in your Application

@Override
protected IConverterLocator newConverterLocator() {
ConverterLocator locator = new ConverterLocator();
locator.set(java.sql.Date.class, dateConverter);
locator.set(Date.class, dateConverter);
locator.set(Timestamp.class, dateConverter);
return locator;
}

with dateConverter being something like this

public final class DateTimeConverter extends DateConverter {
@Override
public DateFormat getDateFormat(Locale locale) {
return DateFormat.getDateTimeInstance(DateFormat.MEDIUM,
DateFormat.SHORT, locale);
}
}



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?

2007-09-06 Thread Johan Compagner
no not for the onces that make a Repeater.
Because then we aren't being able to tell that the populate should really be
done before the call to super.onBeforeRender

So having an onPopulate is fine. Repeaters should use that method to
populate them selfs and we then also take care of the order
but if somebody extends again that repeater he should be able to overwrite
onBeforeRender()
i think classes that implement the onPopulate should make that method
final... Because that shouldn't be overridable (we don't have the check
there that super is called)

So just removing final of onBeforeRender (for developers who extend the real
repeater again)
and having an onPopulate for concreet classes that extend AbstractRepeater
directly. (and those should make onPopulate final)

johan


On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:

 if it was not final then there would be little point for keeping
 onpopulate,
 it would just be confusing

 -igor


 On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
 
  and?
  why can't AbstractRepeater.onBeforeRender() be not final?
  If i overwrite to do what ever i want (but i do need to call
  onBeforeRender
  at some point else we generate an error)
  then it comes in AbstractRepeater.onBeforeRender()
  that first does the onPopulate so the items are created and then calls
 the
  super..
  That i can never change even if onBeforeRender is not final..
 
  johan
 
 
  On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
  
   since component.onbeforerender() is what cascades the onbeforerender()
   call
   to the children, when it comes to repeaters it is absolutely vital
 that
   super.onbeforerender() be called last, that way it will cascade to any
  new
   items added in repeater's onbeforerender().
  
   -igor
  
   On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
   
please tell me, tell me!
   
johan
   
   
On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:

 because the final is there for a very important reason?

 -igor


 On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
 
  I take the discussion is about removing onPopulate now?
  why not keep onPopulate and remove the final?
 
 
  On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
  
   the reason for it being final is that the super.onbeforerender
 ()
call
  HAS
   to
   be done last, otherwise new items do not get onbeforerender
  called
on
   them.
  
   so if we remove final will you remember to always call it
 last?
  i
 think
   the
   chances are that are pretty small, thus its final.
  
   -igor
  
  
   On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
   
   
I've grabbed the latest SNAPSHOT from the repository and
 have
 noticed
   that
AbstractRepeater#onBeforeRender is final. I wonder what is
 the
 reason
   for
this? (I need to do something in it's subclass)
/**
 * @see org.apache.wicket.Component#onBeforeRender()
 */
protected final void onBeforeRender()
{
if (isVisibleInHierarchy())
{
onPopulate();
}
super.onBeforeRender();
}
   
Alex
--
View this message in context:
   
  
 

   
  
 
 http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
Sent from the Wicket - User mailing list archive at
 Nabble.com
  .
   
   
   

  -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
 [EMAIL PROTECTED]
   
   
  
 

   
  
 



Re: Re: Re: Re: Re: Re: Wicket libraries stack trace

2007-09-06 Thread Robo
Sorry Eelco but I did not start this small personal war. In my previus of topic 
marked post I said lot of good about wicket and made lot of PLEASE do this ... 
I know you have lot of work ... IMHO ... and so on ... Also thanked to Gwyn? 
... :-))) Al getted touched about my troubles with Maven, you started to 
talking b.s. and mindless way of something and started to solve and the same 
time started to solve some morality questions and so on.  Gwyn started to look 
for truth in Joke :-)) POint me in one of my post when I said about Maven, or 
your work, that it is b.s. or mindless something. ... YOu will not find it. And 
also any personal negative sentences towards to any of the developers.

I`m not trying to be polite. I`m rying to be correct to people. At the same 
time you are too polite and agresive ... :-)

So after more than 26 hours of programming and mailing I`ll go for a Little bit 
of sleep. :-))

Bye
Robo


- Originálna Správa -
Od: \Eelco Hillenius\  
Komu:  
Poslaná: 06.09.2007 19:54 
Predmet: Re: Re: Re: Re: Re: Wicket libraries stack trace

 On 06 Sep 2007 18:32:44 +0200 (CEST), Robo  wrote:
  Yes I know Eelco. That is why there are so much troubles in Java 
  programming land. Misusing of basic concepts ... That is why one needs some 
  sort of COC, because there is lot`s of b.s. around ... J2EE 1.4 countained 
  so much of it that lots of developers refused to use it And it had to be 
  rewriten ... Apache Struts ... JSF ... Why did you started Wicket? Did`nt 
  you wrote that MVC is kind of missconceptin? And I ask you Who told that? 
  Eelco Hilenius? Yes and you were probably right. And in that time you with 
  the tapestry was alone against the JSF Struts community. So accpet pleace 
  that someone else is seeing miisconceptions and b.s. in other aspetcs of 
  java programming and habits. OK? :-)
 
 Sure. You know, if you would just try to have a little bit more of a
 constructive tone... I\'m sure we can patch wicket-velocity so that it
 avoids pulling in Velocity too early. And maybe the project tries to
 do too much upfront. Should be pretty easy to fix if you want to
 create a JIRA issue for it.
 
 About calling initializers (that\'s what triggers Velocity loading in
 this case), the feature is generally nice. We can use it to e.g.
 automatically register shared resources or like wicket-jmx does,
 register resources, so that to enable functionality in that lib is as
 easy as dropping in a jar. That\'s pretty cool functionality in my
 book.
 
 Eelco
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


__
Najpopulárnejší blog na Slovensku - http://blog.sme.sk/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?

2007-09-06 Thread Igor Vaynberg
if it was not final then there would be little point for keeping onpopulate,
it would just be confusing

-igor


On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:

 and?
 why can't AbstractRepeater.onBeforeRender() be not final?
 If i overwrite to do what ever i want (but i do need to call
 onBeforeRender
 at some point else we generate an error)
 then it comes in AbstractRepeater.onBeforeRender()
 that first does the onPopulate so the items are created and then calls the
 super..
 That i can never change even if onBeforeRender is not final..

 johan


 On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
 
  since component.onbeforerender() is what cascades the onbeforerender()
  call
  to the children, when it comes to repeaters it is absolutely vital that
  super.onbeforerender() be called last, that way it will cascade to any
 new
  items added in repeater's onbeforerender().
 
  -igor
 
  On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
  
   please tell me, tell me!
  
   johan
  
  
   On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
   
because the final is there for a very important reason?
   
-igor
   
   
On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:

 I take the discussion is about removing onPopulate now?
 why not keep onPopulate and remove the final?


 On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
 
  the reason for it being final is that the super.onbeforerender()
   call
 HAS
  to
  be done last, otherwise new items do not get onbeforerender
 called
   on
  them.
 
  so if we remove final will you remember to always call it last?
 i
think
  the
  chances are that are pretty small, thus its final.
 
  -igor
 
 
  On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
  
  
   I've grabbed the latest SNAPSHOT from the repository and have
noticed
  that
   AbstractRepeater#onBeforeRender is final. I wonder what is the
reason
  for
   this? (I need to do something in it's subclass)
   /**
* @see org.apache.wicket.Component#onBeforeRender()
*/
   protected final void onBeforeRender()
   {
   if (isVisibleInHierarchy())
   {
   onPopulate();
   }
   super.onBeforeRender();
   }
  
   Alex
   --
   View this message in context:
  
 

   
  
 
 http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
   Sent from the Wicket - User mailing list archive at Nabble.com
 .
  
  
  
   
 -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 

   
  
 



Re: Re: Re: Wicket libraries

2007-09-06 Thread Alexandre Bairos
If you care about the product of your own work, it 's personal. O.S.S. is
based on self motivated developers who, by definition, care about their
work.

On 06 Sep 2007 19:36:36 +0200 (CEST), Robo [EMAIL PROTECTED] wrote:

 No Igor. Software is never personal. war is personal, dying of my mother,
 father and youg brother bombed by army aircraft is personal but software
 sure not ;-)

 If you can point me please to ANY of the disrespect sentences, except AL`s
 \why are you still bitching about it\ please do it ... :-)

 Robo


 - Originálna Správa -
 Od: \Igor Vaynberg\
 Komu:
 Poslaná: 06.09.2007 19:36
 Predmet: Re: Re: Wicket libraries

 
  On 06 Sep 2007 17:35:26 +0200 (CEST), Robo  wrote:
  
   Stop it now please Al. You take oo personal aproach. Nobody forced you
 in
   responding.
 
 
  heh, what you have to understand is that wicket is oss - so it IS
 personal.
  it is something we work on in our spare time so it is kind of a hobby (a
  demanding hobby). we do care about it a great deal. constructive
 criticism
  is always welcome, but you have to have a level of respect on the lists.
 
  You make Wicket And I`m the user. If you do not like it do not do it.
 But
   there is some responsibilities about product you develop towards
 product
   users so do not confuse roles please.
 
 
  wrong again. its the other way around. if you do not like it do not use
 it.
  we do not owe you anything. we put wicket out there for people to use,
 no
  strings attached.
 
  And besides that I`m also kind of customer As I paid for the book ;-)
 
 
  you paid for the book, but we get nothing from that. so how do you
 connect
  the dots?
 
  And besides that I several times said how Wicket is great is that not
 enaugh
   for you? :-))
 
 
  thank you.
 
  And btw I thanked to Gvyn at the end of my troubles as his responcese
 solved
   them. I do not thank before my troubles gets solved ;-) I`m not
 teacher in
   the dance school.
 
 
  its not the missing thank you, it is more your superior attitute and
 your
  lecturing tone. so in fact you do come across as a teacher.
 
  What I`m doing now is preparing presentation to my chiefs and currrently
 I`m
   coping with five frameworks amking demo apps and have two weeks for
 it. That
   is Why I`m not writing wiki and that is why I`m sometimes upset about
 lack
   of docs, working 18-20 hours per day ...
 
 
  sounds like your chiefs are pretty dumb if they expect you to learn five
  frameworks in two weeks, find a better job.
 
  as for the issue at hand, i believe the velocity initializer should be
  rewritten to check if whatever it needs is actually on the classpath,
 and
  noop quietly if its not. please file a jira issue.
 
 
 
  -igor
 
 
  Java jars are nto at all complex beast. They become tricky in situation
   where you just put some of them inclasspath and they do what you
 normally do
   not expect. Lib should be lib and when not called by developer they
 should
   do nothing. Deliberatly breaking this rule makes the jars, beast ...
 :-)
  
   So Finishing this personal thread and thank you for much of your time
 ;-))
  
   Robo
  
  
   - Originálna Správa -
   Od: Al Maw
   Komu:
   Poslaná: 06.09.2007 17:44
   Predmet: Re: Wicket libraries
  
Robo wrote:
 Ok, seems removing \\\wicket-velocity-1.3.0-beta3.jar\\\
 from build
 path solved problem with velocity problem. But please explain me
 why
 removing package from build path solves the problem if nowhere in
 my
 Hello World code i call for any of the velocity packages. Is there
 some duplicities in packages or what?
   
I expect because Wicket looks on the classpath for Wicket modules to
initialise, finds some in that JAR, tries to and then can\\\'t find
 one of
its dependencies.
   
Modern Java apps tend to be complex beasts, with lots of
 dependencies.
If you insist on managing these manually, you can expect to have a
 fair
bit of work to do. That\\\'s why things like Ivy and Maven 2 were
   invented.
   
 As to Maven2. It seems that like you in some way force developers
 to
   Maven2. :-)
   
No, not at all. But if you\\\'ve deliberately chosen to manage your
dependencies manually when there are perfectly good ways of doing it
automatically, then we\\\'re not going to hold your hand for you. We
   don\\\'t
get paid to do this, you know.
   
If you don\\\'t like Maven 2 no one is forcing you to use it. Use
 Ivy
instead. Or use the standalone Maven 2 Ant tasks for doing
 dependencies.
   
Alternatively, install Maven 2, use it to build a quickstart WAR
 file
with all the things you need, and then grab the JARs from there.
   
Any of these options would take you a tenth of the time you\\\'ve
 spent
bitching on this mailing list.
   
 Yes Maven solves you some problems with dependecies and also si
 suitable for small project but at big projects it definitely
 fails.
 :-/
   
So 

Basic Wicket, and form submit question

2007-09-06 Thread Arint
Ok when the user press the submit button on a wicket form, how do you make 
it go to another page?  onSubmit has a void return 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?

2007-09-06 Thread Johan Compagner
thats why i said the concreet repeaters that implement onPopulate should
make them final
also what do you mean with funny errors,
you only get funny errors when you override both or 1 and start calling the
other.
calling super on different times in your onBeforeRender doesn't create
anything funny
except one thing. Before the onBeforeRender you have the old items after it
the new onces.

johan


On 9/6/07, Jan Kriesten [EMAIL PROTECTED] wrote:


 i think onPopulate() is there for just about 2 or 3 weeks and before the
 docs
 stated that calling super() would be vital.

 so, i really don't see a benefit in having a onpopulate() _and_ a
 non-final
 onbeforerender(). actually, if i override both, i could get funny errors
 changing a call to super.onbeforerender() at the end of an overridden
 onbeforerender() to the beginning - since code in onpopulate() would be
 called
 on different initialization stages.

 having no onpopulate() would move the responsability back into the
 onbeforerender() again.

 i would prefer to get lost of onpopulate() in favor of onbeforerender().

 my 2c

 regards, --- jan.



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Displaying images and Test from DB

2007-09-06 Thread Aaron Hutchings
Is there something like listview that I configure for displaying text and
images?  I do not need any sorting ..



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Creating a disableable AjaxSubmitLink

2007-09-06 Thread Anthony J Webster
Hi,

I'm trying to create a disableable AjaxSubmitLink. When a user clicks on the 
link further clicks must not result in anything until the 'submission' is 
complete. This call be achieved by adding return false; in a call decorator. 
However I'm stuggling with the re-enabling. I need to strip the return false 
and put the original destination back.

form.add(new AjaxSubmitLink(randomise, form) {

protected void onSubmit(AjaxRequestTarget target, Form form) {
   somethingLong();
}
protected IAjaxCallDecorator getAjaxCallDecorator() {
return new AjaxCallDecorator() {

public CharSequence decorateScript(CharSequence script) {
return return false; + script;
}
public CharSequence decorateOnSuccessScript(CharSequence 
script) {
// NEED TO RESET TO PREVIOUS STATE
}
public CharSequence decorateOnFailureScript(CharSequence 
script) {
// NEED TO RESET TO PREVIOUS STATE
}
};
}
});

Any help would be most appreciated.

Thanks in advance

Anthony

Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?

2007-09-06 Thread Johan Compagner
ok,
i don't like to have onBeforeRender final because we have the whole i called
the super check for that.
But i do like the onPopulate because that makes much more clear that the
repeaters do there there work
because why should that happen in onBeforeRender? The api does speak for
them self then

So i will remove the final of the onBeforeRender()
but make all onPopulate implementations final because that just for the
implementors
The only exception being RepeatingView because thats just an empty
implementation thats is supposed to be overwritten again..

by the way, these discussion do drain you, but your are happily contributing
to threads like Wicket Libraries :)

On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:

 i will leave it up to you guys as to what you want to do and how. honestly
 discussions like this drain my attention span.

 the only reason i introduced onpopulate is so that i could make
 onbeforerender final.

 -igor


 On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
 
  thats why i said the concreet repeaters that implement onPopulate should
  make them final
  also what do you mean with funny errors,
  you only get funny errors when you override both or 1 and start calling
  the
  other.
  calling super on different times in your onBeforeRender doesn't create
  anything funny
  except one thing. Before the onBeforeRender you have the old items after
  it
  the new onces.
 
  johan
 
 
  On 9/6/07, Jan Kriesten [EMAIL PROTECTED] wrote:
  
  
   i think onPopulate() is there for just about 2 or 3 weeks and before
 the
   docs
   stated that calling super() would be vital.
  
   so, i really don't see a benefit in having a onpopulate() _and_ a
   non-final
   onbeforerender(). actually, if i override both, i could get funny
 errors
   changing a call to super.onbeforerender() at the end of an overridden
   onbeforerender() to the beginning - since code in onpopulate() would
 be
   called
   on different initialization stages.
  
   having no onpopulate() would move the responsability back into the
   onbeforerender() again.
  
   i would prefer to get lost of onpopulate() in favor of
 onbeforerender().
  
   my 2c
  
   regards, --- jan.
  
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 



Problem with DropDownChoice and AjaxFormComponentUpdatingBehavior

2007-09-06 Thread JulianS

I am using Wicket 1.2.6. I have 3 DropDownChoices (and some other fields) on
a form. 

The first DropDownChoice resets the selections in the other DropDownChoices
using AjaxFormComponentUpdatingBehavior(onchange). All the DropDownChoices
use PropertyModels.

This all works fine until the form is submitted and validation fails. In
this (normal) situation the form is still visible, with the feedback
messages displayed, but the 2nd and 3rd DropDownChoices no longer react to
the first DropDownChoice. I have verified that the properties on which
DropDownChoices depend are being correctly set.

Is there anything I can do to make them behave properly? Any help is
appreciated.

Thanks,
Julian

-- 
View this message in context: 
http://www.nabble.com/Problem-with-DropDownChoice-and-AjaxFormComponentUpdatingBehavior-tf4394596.html#a12531138
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Displaying images and Test from DB

2007-09-06 Thread Jonathan Locke


you can build your own component very easily.  listview can contain
labels and/or images in any way you desire.


Aaron Hutchings wrote:
 
 Is there something like listview that I configure for displaying text and
 images?  I do not need any sorting ..
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Basic-Wicket%2C-and-form-submit-question-tf4394056.html#a12531233
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?

2007-09-06 Thread Johan Compagner
who? that overrides onBeforeRender?
why should those call super last?
that depends on what they want.

On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:

 because we are going in circles here

 even with onpopulate you still have to make sure you call super last!

 -igor


 On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
 
  ok,
  i don't like to have onBeforeRender final because we have the whole i
  called
  the super check for that.
  But i do like the onPopulate because that makes much more clear that the
  repeaters do there there work
  because why should that happen in onBeforeRender? The api does speak for
  them self then
 
  So i will remove the final of the onBeforeRender()
  but make all onPopulate implementations final because that just for the
  implementors
  The only exception being RepeatingView because thats just an empty
  implementation thats is supposed to be overwritten again..
 
  by the way, these discussion do drain you, but your are happily
  contributing
  to threads like Wicket Libraries :)
 
  On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
  
   i will leave it up to you guys as to what you want to do and how.
  honestly
   discussions like this drain my attention span.
  
   the only reason i introduced onpopulate is so that i could make
   onbeforerender final.
  
   -igor
  
  
   On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
   
thats why i said the concreet repeaters that implement onPopulate
  should
make them final
also what do you mean with funny errors,
you only get funny errors when you override both or 1 and start
  calling
the
other.
calling super on different times in your onBeforeRender doesn't
 create
anything funny
except one thing. Before the onBeforeRender you have the old items
  after
it
the new onces.
   
johan
   
   
On 9/6/07, Jan Kriesten [EMAIL PROTECTED] wrote:


 i think onPopulate() is there for just about 2 or 3 weeks and
 before
   the
 docs
 stated that calling super() would be vital.

 so, i really don't see a benefit in having a onpopulate() _and_ a
 non-final
 onbeforerender(). actually, if i override both, i could get funny
   errors
 changing a call to super.onbeforerender() at the end of an
  overridden
 onbeforerender() to the beginning - since code in onpopulate()
 would
   be
 called
 on different initialization stages.

 having no onpopulate() would move the responsability back into the
 onbeforerender() again.

 i would prefer to get lost of onpopulate() in favor of
   onbeforerender().

 my 2c

 regards, --- jan.




  -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


   
  
 



Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?

2007-09-06 Thread Johan Compagner
sure no problem, just point them out :)

On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:

 well, whenever those emails comein...why doesnt onbeforerender is getting
 called...you can answer them :)

 -igor


 On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
 
  who? that overrides onBeforeRender?
  why should those call super last?
  that depends on what they want.
 
  On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
  
   because we are going in circles here
  
   even with onpopulate you still have to make sure you call super last!
  
   -igor
  
  
   On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
   
ok,
i don't like to have onBeforeRender final because we have the whole
 i
called
the super check for that.
But i do like the onPopulate because that makes much more clear that
  the
repeaters do there there work
because why should that happen in onBeforeRender? The api does speak
  for
them self then
   
So i will remove the final of the onBeforeRender()
but make all onPopulate implementations final because that just for
  the
implementors
The only exception being RepeatingView because thats just an empty
implementation thats is supposed to be overwritten again..
   
by the way, these discussion do drain you, but your are happily
contributing
to threads like Wicket Libraries :)
   
On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:

 i will leave it up to you guys as to what you want to do and how.
honestly
 discussions like this drain my attention span.

 the only reason i introduced onpopulate is so that i could make
 onbeforerender final.

 -igor


 On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
 
  thats why i said the concreet repeaters that implement
 onPopulate
should
  make them final
  also what do you mean with funny errors,
  you only get funny errors when you override both or 1 and start
calling
  the
  other.
  calling super on different times in your onBeforeRender doesn't
   create
  anything funny
  except one thing. Before the onBeforeRender you have the old
 items
after
  it
  the new onces.
 
  johan
 
 
  On 9/6/07, Jan Kriesten [EMAIL PROTECTED] wrote:
  
  
   i think onPopulate() is there for just about 2 or 3 weeks and
   before
 the
   docs
   stated that calling super() would be vital.
  
   so, i really don't see a benefit in having a onpopulate()
 _and_
  a
   non-final
   onbeforerender(). actually, if i override both, i could get
  funny
 errors
   changing a call to super.onbeforerender() at the end of an
overridden
   onbeforerender() to the beginning - since code in onpopulate()
   would
 be
   called
   on different initialization stages.
  
   having no onpopulate() would move the responsability back into
  the
   onbeforerender() again.
  
   i would prefer to get lost of onpopulate() in favor of
 onbeforerender().
  
   my 2c
  
   regards, --- jan.
  
  
  
  
   
 -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 

   
  
 



DetachableContactModel question

2007-09-06 Thread Cristi Manole
Hello,

In the repeteater samples, the one with ajax capability you have 
DetachableContactModel. 

My question is why 

protected Object load()
 {
  // loads contact from the database
  return getContactsDB().get(id);
 }

does not just return the Contact object?

It is already determined by the constructor.
 public DetachableContactModel(Contact c)
 {
  this(c.getId());
  contact = c;
 }
[this is the one called by SortableDataProvider]

Why the extra roundtrip to the database?

Sorry if this is a silly question.

Thks in advance.

Re: AjaxFallbackLink inside ListView

2007-09-06 Thread Kent Tong



pokkie wrote:
 
 Worked like a charm, thanks Kent. 
 
 You the same Kent Tong that wrote a online Tapestry book?
 

Yep.
-- 
View this message in context: 
http://www.nabble.com/AjaxFallbackLink-inside-ListView-tf4389622.html#a12534270
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



  1   2   >