Re: Example of wicketstuff-minis' Veil
great! :) Igor Vaynberg wrote: should be fixed, noticed i fixed the version, it is now 1.3-snap instead of 1.3.0-snap -igor On Wed, Jun 11, 2008 at 11:53 AM, nitinkc <[EMAIL PROTECTED]> wrote: Igor, Any updates on this?? thanks! nitinkc wrote: Here is the stack trace: Root cause:java.lang.IllegalStateException: This behavior is already bound to component. An instance of this behavior cannot be reused between components. Bound component: [MarkupContainer [Component id = test, page = , path = test.Button]] at org.wicketstuff.minis.veil.Veil.bind(Veil.java:64) at org.apache.wicket.Component.add(Component.java:922) at com.uprr.app.hrw.wicket.page.scheduling.EventDetailsPage.(EventDetailsPage.java:235) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at java.lang.Class.newInstance0(Class.java:350) at java.lang.Class.newInstance(Class.java:303) at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:58) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:262) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:283) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:210) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:90) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1166) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1241) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1316) at org.apache.wicket.RequestCycle.request(RequestCycle.java:493) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:354) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:194) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3393) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(Unknown Source) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2140) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2046) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1366) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200) at weblogic.work.ExecuteThread.run(ExecuteThread.java:172) I am using: wicketstuff-minis-1.3.0-SNAPSHOT.jar igor.vaynberg wrote: can you paste the stack trace please? are you using latest trunk? -igor On Tue, Jun 3, 2008 at 6:38 AM, nitinkc <[EMAIL PROTECTED]> wrote: I need an example of wicketstuff-minis' veil behavior. I added this to one of my components but keep getting the error that the behavior is already bound to another component and cannot be reused. All I am doing is: Button button = new Button("test"); button.add(new Veil()); form.add(button); This is the only Veil I am using on my page. Thanks. -- View this message in context: http://www.nabble.com/Example-of-wicketstuff-minis%27-Veil-tp17623741p17623741.html 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/Example-of-wicketstuff-minis%27-Veil-tp17623741p17784653.html 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 for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Example of wicketstuff-minis' Veil
should be fixed, noticed i fixed the version, it is now 1.3-snap instead of 1.3.0-snap -igor On Wed, Jun 11, 2008 at 11:53 AM, nitinkc <[EMAIL PROTECTED]> wrote: > > Igor, > Any updates on this?? > thanks! > > > nitinkc wrote: >> >> Here is the stack trace: >> Root cause:java.lang.IllegalStateException: This behavior is already bound >> to component. An instance of this behavior cannot be reused between >> components. Bound component: [MarkupContainer [Component id = test, page = >> , path = test.Button]] at >> org.wicketstuff.minis.veil.Veil.bind(Veil.java:64) at >> org.apache.wicket.Component.add(Component.java:922) at >> com.uprr.app.hrw.wicket.page.scheduling.EventDetailsPage.(EventDetailsPage.java:235) >> at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at >> java.lang.Class.newInstance0(Class.java:350) at >> java.lang.Class.newInstance(Class.java:303) at >> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:58) >> at >> org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:262) >> at >> org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:283) >> at >> org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:210) >> at >> org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:90) >> at >> org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1166) >> at org.apache.wicket.RequestCycle.step(RequestCycle.java:1241) at >> org.apache.wicket.RequestCycle.steps(RequestCycle.java:1316) at >> org.apache.wicket.RequestCycle.request(RequestCycle.java:493) at >> org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:354) >> at >> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:194) >> at >> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42) >> at >> weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3393) >> at >> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) >> at weblogic.security.service.SecurityManager.runAs(Unknown Source) at >> weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2140) >> at >> weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2046) >> at >> weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1366) >> at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200) at >> weblogic.work.ExecuteThread.run(ExecuteThread.java:172) >> >> I am using: wicketstuff-minis-1.3.0-SNAPSHOT.jar >> >> >> igor.vaynberg wrote: >>> >>> can you paste the stack trace please? are you using latest trunk? >>> >>> -igor >>> >>> On Tue, Jun 3, 2008 at 6:38 AM, nitinkc <[EMAIL PROTECTED]> wrote: I need an example of wicketstuff-minis' veil behavior. I added this to one of my components but keep getting the error that the behavior is already bound to another component and cannot be reused. All I am doing is: Button button = new Button("test"); button.add(new Veil()); form.add(button); This is the only Veil I am using on my page. Thanks. -- View this message in context: http://www.nabble.com/Example-of-wicketstuff-minis%27-Veil-tp17623741p17623741.html 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/Example-of-wicketstuff-minis%27-Veil-tp17623741p17784653.html > 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: Making Component easier to Generify
looked over the article. what they do is a ui decorator, it is not the software decorator pattern. there is no method delegation to the child component. what they create is a composite, you can do the same thing in wicket with a Border. -igor On Thu, Jun 12, 2008 at 9:55 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > right. so when you would do it with a class you will actually have to > rewire all the methods to forward to the delegate instead of calling > super. that is pure insanity and does not make any sense when methods > hold logic. that is why it works with an interface, no logic for you > to override and forward to the delegate, only the message dispatch > itself. sure, technically you can do it even with a concrete class, > but you can also do a lot of other things that dont make sense. > > -igor > > On Thu, Jun 12, 2008 at 5:54 PM, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: >> Igor Vaynberg wrote: >>> >>> look at the java example. notice Window is an interface. >>> >> >> Yeah, but that's just because it's good practice to use the interface when >> there is one. Notice that the actually decorated class is a new >> SimpleWindow() in DecoratedWindowTest. Window might as well have been an >> abstract class, or even a concrete one. The idea is that the contract of the >> class you wrap is maintained, if that is an interface your decorator >> implements that, when it's a class your decorator extends it. Same idea. Of >> course, interfaces are cleaner and you can even decorate more then one >> interface when you want to, but decorating a class is not uncommon practice >> (at least where I come from). >> >> Example: http://www.onjava.com/pub/a/onjava/2003/02/05/decorator.html >> >>> eg you cant do: add(new DecoratedComponent(someOtherComponent)); >>> >> >> No, because component has final methods that you can't override so you can't >> delegate to them (that whas my point), but not because you can't decorate a >> class. >> >> Matthijs. >> >> PS. If you insist on that you can only decorate an interface, I'll call it >> wrap-extend or something :) >> >>> -igor >>> >>> On Thu, Jun 12, 2008 at 5:05 PM, Matthijs Wensveen <[EMAIL PROTECTED]> >>> wrote: >>> Why would the decorator design pattern only work with interfaces? Maybe we're talking about two different this here? (I'm talking about this one: http://en.wikipedia.org/wiki/Decorator_pattern) I can see why behaviors were introduced. A simple example: a factory method creates a link. In my subclass I want the same link with the same onClick behavior but I also want "hello" to be outputted to System.out. How would I go about doing this with a Behavior? I couldn't figure it out... (which isn't saying it's impossible). Matthijs [EMAIL PROTECTED] wrote: > > decorators only work with interfaces, component class is not. This is > part of the reason why we have behaviors > > -igor > > On 6/12/08, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: > > >> >> Some useful design patterns like Decorator don't work with final >> methods. Wicket components sometimes have overridable factory methods >> for child components. The decorator pattern could be very useful here, >> because you'd be able to decorate the original component with some >> extra >> functionality (Link.onClick for example). Unfortunately this doesn't >> work because some methods are final. >> >> Matthijs >> >> Igor Vaynberg wrote: >> >> >>> >>> i mean generally, for methods, fields, and func args :) most of this >>> stuff can stay final, but people dont bother doing it because its >>> extra typing. >>> >>> -igor >>> >>> On Thu, Jun 12, 2008 at 8:38 AM, James Carman >>> <[EMAIL PROTECTED]> wrote: >>> >>> >>> You mean like C++? On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > indeed. i wouldnt mind if final was the default in java :) > > -igor > > On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst > <[EMAIL PROTECTED]> wrote: > > > >> >> Without the use of final wicket would not have made it this far. >> >> Martijn >> >> On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <[EMAIL PROTECTED]> >> wrote: >> >> >> >>> >>> I understand the reasoning, however I think "best practice" can be >>> debated. >>> To use your example Swing allows the user to override quite a bit, >>> and >>> it >>> doesn't make any (or very few) assumptions on what should and >>> should >>> not be >>> done. >>> >>> I don't like API's that assume I'm an idiot and
Re: Making Component easier to Generify
right. so when you would do it with a class you will actually have to rewire all the methods to forward to the delegate instead of calling super. that is pure insanity and does not make any sense when methods hold logic. that is why it works with an interface, no logic for you to override and forward to the delegate, only the message dispatch itself. sure, technically you can do it even with a concrete class, but you can also do a lot of other things that dont make sense. -igor On Thu, Jun 12, 2008 at 5:54 PM, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: > Igor Vaynberg wrote: >> >> look at the java example. notice Window is an interface. >> > > Yeah, but that's just because it's good practice to use the interface when > there is one. Notice that the actually decorated class is a new > SimpleWindow() in DecoratedWindowTest. Window might as well have been an > abstract class, or even a concrete one. The idea is that the contract of the > class you wrap is maintained, if that is an interface your decorator > implements that, when it's a class your decorator extends it. Same idea. Of > course, interfaces are cleaner and you can even decorate more then one > interface when you want to, but decorating a class is not uncommon practice > (at least where I come from). > > Example: http://www.onjava.com/pub/a/onjava/2003/02/05/decorator.html > >> eg you cant do: add(new DecoratedComponent(someOtherComponent)); >> > > No, because component has final methods that you can't override so you can't > delegate to them (that whas my point), but not because you can't decorate a > class. > > Matthijs. > > PS. If you insist on that you can only decorate an interface, I'll call it > wrap-extend or something :) > >> -igor >> >> On Thu, Jun 12, 2008 at 5:05 PM, Matthijs Wensveen <[EMAIL PROTECTED]> >> wrote: >> >>> >>> Why would the decorator design pattern only work with interfaces? Maybe >>> we're talking about two different this here? (I'm talking about this one: >>> http://en.wikipedia.org/wiki/Decorator_pattern) >>> >>> I can see why behaviors were introduced. A simple example: a factory >>> method >>> creates a link. In my subclass I want the same link with the same onClick >>> behavior but I also want "hello" to be outputted to System.out. How would >>> I >>> go about doing this with a Behavior? I couldn't figure it out... (which >>> isn't saying it's impossible). >>> >>> Matthijs >>> >>> [EMAIL PROTECTED] wrote: >>> decorators only work with interfaces, component class is not. This is part of the reason why we have behaviors -igor On 6/12/08, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: > > Some useful design patterns like Decorator don't work with final > methods. Wicket components sometimes have overridable factory methods > for child components. The decorator pattern could be very useful here, > because you'd be able to decorate the original component with some > extra > functionality (Link.onClick for example). Unfortunately this doesn't > work because some methods are final. > > Matthijs > > Igor Vaynberg wrote: > > >> >> i mean generally, for methods, fields, and func args :) most of this >> stuff can stay final, but people dont bother doing it because its >> extra typing. >> >> -igor >> >> On Thu, Jun 12, 2008 at 8:38 AM, James Carman >> <[EMAIL PROTECTED]> wrote: >> >> >> >>> >>> You mean like C++? >>> >>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg >>> <[EMAIL PROTECTED]> >>> wrote: >>> >>> >>> indeed. i wouldnt mind if final was the default in java :) -igor On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > Without the use of final wicket would not have made it this far. > > Martijn > > On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <[EMAIL PROTECTED]> > wrote: > > > >> >> I understand the reasoning, however I think "best practice" can be >> debated. >> To use your example Swing allows the user to override quite a bit, >> and >> it >> doesn't make any (or very few) assumptions on what should and >> should >> not be >> done. >> >> I don't like API's that assume I'm an idiot and prevent me from >> manipulating >> them how I see fit. If I cause a bug that I have to deal with, >> thats >> *my* >> problem to resolve. >> >> In my book (and I'm not the only one) excessive use of final is an >> anti-pattern. >> >> - Brill Pappin >> >> On 12-Jun-08, at 10:01 AM, cowwoc wrote: >> >> >> >> >>> >>> Brill,
RE: Default Focus Behavior?
Here's that link ... http://cwiki.apache.org/confluence/display/WICKET/Request+Focus+on+a+Spe cific+Form+Component Note that the technique outlined does set the focus correctly, but after I use the autocomplete box it throws a runtime exception : Root cause: java.lang.IllegalStateException: No behavior listener found with behaviorId 4; Component: [MarkupContainer [Component id = ac, page = au.com.macquarie.hr.edms.web.ed.EDMainPage, path = 6:edSelectionPanel:form:ac.EDSelectionPanel$EdSelectionForm$1, isVisible = true, isVersioned = false]] at org.apache.wicket.request.target.component.listener.BehaviorRequestTarge t.processEvents(BehaviorRequestTarget.java:95) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(Ab stractRequestCycleProcessor.java:91) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java :1171) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1248) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1349) at org.apache.wicket.RequestCycle.request(RequestCycle.java:493) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387 ) at org.apache.wicket.protocol.http.WicketServlet.doPost(WicketServlet.java: 145) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:173) at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFil terInternal(OpenSessionInViewFilter.java:198) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequ estFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv e.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv e.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:1 48) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:86 9) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.proc essConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint .java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollow erWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool .java:684) at java.lang.Thread.run(Thread.java:619) -Original Message- From: Rod Good Sent: Friday, 13 June 2008 1:06 PM To: users@wicket.apache.org Subject: Re: Default Focus Behavior? Hi, I'm trying to set the 'focus on load' to an AutoCompleteTextField within a form. I tried extending the technique outlined by James Carman (see link) to extend AbstractDefaultAjaxBehavior, without success. Any thoughts on how to do this ? Thanks, Rod. http://cwiki.apache.org/confluence/display/WICKET/Request+Focus+on+a+Spe cific+Form+Component NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Group Limited or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Group Limited does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Group Limited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default Focus Behavior?
Hi, I'm trying to set the 'focus on load' to an AutoCompleteTextField within a form. I tried extending the technique outlined by James Carman (see link) to extend AbstractDefaultAjaxBehavior, without success. Any thoughts on how to do this ? Thanks, Rod. http://cwiki.apache.org/confluence/display/WICKET/Request+Focus+on+a+Spe cific+Form+Component NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Group Limited or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Group Limited does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Group Limited.
Re: Making Component easier to Generify
Igor Vaynberg wrote: look at the java example. notice Window is an interface. Yeah, but that's just because it's good practice to use the interface when there is one. Notice that the actually decorated class is a new SimpleWindow() in DecoratedWindowTest. Window might as well have been an abstract class, or even a concrete one. The idea is that the contract of the class you wrap is maintained, if that is an interface your decorator implements that, when it's a class your decorator extends it. Same idea. Of course, interfaces are cleaner and you can even decorate more then one interface when you want to, but decorating a class is not uncommon practice (at least where I come from). Example: http://www.onjava.com/pub/a/onjava/2003/02/05/decorator.html eg you cant do: add(new DecoratedComponent(someOtherComponent)); No, because component has final methods that you can't override so you can't delegate to them (that whas my point), but not because you can't decorate a class. Matthijs. PS. If you insist on that you can only decorate an interface, I'll call it wrap-extend or something :) -igor On Thu, Jun 12, 2008 at 5:05 PM, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: Why would the decorator design pattern only work with interfaces? Maybe we're talking about two different this here? (I'm talking about this one: http://en.wikipedia.org/wiki/Decorator_pattern) I can see why behaviors were introduced. A simple example: a factory method creates a link. In my subclass I want the same link with the same onClick behavior but I also want "hello" to be outputted to System.out. How would I go about doing this with a Behavior? I couldn't figure it out... (which isn't saying it's impossible). Matthijs [EMAIL PROTECTED] wrote: decorators only work with interfaces, component class is not. This is part of the reason why we have behaviors -igor On 6/12/08, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: Some useful design patterns like Decorator don't work with final methods. Wicket components sometimes have overridable factory methods for child components. The decorator pattern could be very useful here, because you'd be able to decorate the original component with some extra functionality (Link.onClick for example). Unfortunately this doesn't work because some methods are final. Matthijs Igor Vaynberg wrote: i mean generally, for methods, fields, and func args :) most of this stuff can stay final, but people dont bother doing it because its extra typing. -igor On Thu, Jun 12, 2008 at 8:38 AM, James Carman <[EMAIL PROTECTED]> wrote: You mean like C++? On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: indeed. i wouldnt mind if final was the default in java :) -igor On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: Without the use of final wicket would not have made it this far. Martijn On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: I understand the reasoning, however I think "best practice" can be debated. To use your example Swing allows the user to override quite a bit, and it doesn't make any (or very few) assumptions on what should and should not be done. I don't like API's that assume I'm an idiot and prevent me from manipulating them how I see fit. If I cause a bug that I have to deal with, thats *my* problem to resolve. In my book (and I'm not the only one) excessive use of final is an anti-pattern. - Brill Pappin On 12-Jun-08, at 10:01 AM, cowwoc wrote: Brill, This is actually an API "best practice". Classes fall into two categories: ones designed for subclassing, and ones designed to be final. The same goes for methods. Swing is full of examples of what goes wrong when people override methods in classes that haven't been designed with subclassing in mind. Gili Brill Pappin wrote: on removing the finals The final members are the worst thing I've had to deal with in Wicket so far. Although I understand that there may be a reason for them, they are more a hinderance than anything else and seem to be trying to "protect users from themselves". - Brill Pappin On 12-Jun-08, at 1:03 AM, cowwoc wrote: Have you considered moving from subclassing to composition in Wicket using Callable? Currently it is quite common for developers to subclass a component in order to override isVisible() and other properties. I am proposing that instead the component classes become final and properties may only be set using setter methods. The setter methods would take Callable instead of T, so for example setVisible(boolean) would become setVisible(Callable) The benefit of this approach is that you could introduce static factory methods to the Wicket components which would make them much easier to use in their Generic form. You could then intro
Re: Making Component easier to Generify
look at the java example. notice Window is an interface. eg you cant do: add(new DecoratedComponent(someOtherComponent)); -igor On Thu, Jun 12, 2008 at 5:05 PM, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: > Why would the decorator design pattern only work with interfaces? Maybe > we're talking about two different this here? (I'm talking about this one: > http://en.wikipedia.org/wiki/Decorator_pattern) > > I can see why behaviors were introduced. A simple example: a factory method > creates a link. In my subclass I want the same link with the same onClick > behavior but I also want "hello" to be outputted to System.out. How would I > go about doing this with a Behavior? I couldn't figure it out... (which > isn't saying it's impossible). > > Matthijs > > [EMAIL PROTECTED] wrote: >> >> decorators only work with interfaces, component class is not. This is >> part of the reason why we have behaviors >> >> -igor >> >> On 6/12/08, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: >> >>> >>> Some useful design patterns like Decorator don't work with final >>> methods. Wicket components sometimes have overridable factory methods >>> for child components. The decorator pattern could be very useful here, >>> because you'd be able to decorate the original component with some extra >>> functionality (Link.onClick for example). Unfortunately this doesn't >>> work because some methods are final. >>> >>> Matthijs >>> >>> Igor Vaynberg wrote: >>> i mean generally, for methods, fields, and func args :) most of this stuff can stay final, but people dont bother doing it because its extra typing. -igor On Thu, Jun 12, 2008 at 8:38 AM, James Carman <[EMAIL PROTECTED]> wrote: > > You mean like C++? > > On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg > <[EMAIL PROTECTED]> > wrote: > > >> >> indeed. i wouldnt mind if final was the default in java :) >> >> -igor >> >> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >> <[EMAIL PROTECTED]> wrote: >> >> >>> >>> Without the use of final wicket would not have made it this far. >>> >>> Martijn >>> >>> On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <[EMAIL PROTECTED]> >>> wrote: >>> >>> I understand the reasoning, however I think "best practice" can be debated. To use your example Swing allows the user to override quite a bit, and it doesn't make any (or very few) assumptions on what should and should not be done. I don't like API's that assume I'm an idiot and prevent me from manipulating them how I see fit. If I cause a bug that I have to deal with, thats *my* problem to resolve. In my book (and I'm not the only one) excessive use of final is an anti-pattern. - Brill Pappin On 12-Jun-08, at 10:01 AM, cowwoc wrote: > > Brill, > > This is actually an API "best practice". Classes fall into two > categories: > ones designed for subclassing, and ones designed to be final. The > same > goes > for methods. Swing is full of examples of what goes wrong when > people > override methods in classes that haven't been designed with > subclassing in > mind. > > Gili > > > Brill Pappin wrote: > > >> >> on removing the finals >> >> The final members are the worst thing I've had to deal with in >> Wicket >> so far. >> Although I understand that there may be a reason for them, they >> are >> more a hinderance than anything else and seem to be trying to >> "protect >> users from themselves". >> >> - Brill Pappin >> >> >> On 12-Jun-08, at 1:03 AM, cowwoc wrote: >> >> >> >>> >>> Have you considered moving from subclassing to composition in >>> Wicket >>> using >>> Callable? >>> >>> Currently it is quite common for developers to subclass a >>> component >>> in order >>> to override isVisible() and other properties. I am proposing that >>> instead >>> the component classes become final and properties may only be set >>> using >>> setter methods. The setter methods would take Callable instead >>> of >>> T, so >>> for example setVisible(boolean) would become >>> setVisible(Callable) >>> >>> The benefit of this approach is that you could introduce static >>> factory >>> methods to the Wicket components which would make them much >>> easier >>
Re: PasswordTextField model?
no, you dont typically initialize the field. but you do want to retrieve the result right? so you need to give the field a model. wicket might not call model.getobject() on it, but it will call model.setobject() when the form is submitted. models do not contain data for markup, but for components. -igor On Thu, Jun 12, 2008 at 3:04 PM, David Nedrow <[EMAIL PROTECTED]> wrote: > Given the following from the wicket security quickstart (1.3-SNAPSHOT)... > > add(new PasswordTextField("password").setOutputMarkupId(false)); > > glassfish generates the following message > > Couldn't resolve model type of > Model:classname=[org.apache.wicket.model.CompoundPropertyModel$AttachedCompoundPropertyModel]:nestedModel=[Model:classname=[org.apache.wicket.model.CompoundPropertyModel]:nestedModel=[username > = "regular"]] for [MarkupContainer [Component id = password, page = > com.vzbi.ncs.argfrp.webapp.FilterRequest.app.LoginPage, path = > 0:signInPanel:signInForm:password.PasswordTextField, isVisible = true, > isVersioned = false]], please set the type yourself. > > Not setting the model does not seem to create a problem, but it would seem > that the system would prefer that models be set where applicable. > > Is that the case? I have to admit, I'm a little anal about clearing all > warnings in my apps. > > What would an appropriate model be for the above PasswordTextField()? > > Models seem to be the most poorly "exampled" Wicket feature, in that > examples of Models rarely tell one why they are needed and what role they > perform. It's generally, here's an example to make your code work. Clearly, > in most cases the model contains the data for the markup. But what would > that data be for a PasswordTextField()? One isn't normally going to pre-fill > a password field, correct? > > Thanks, > > David > > - > 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: Making Component easier to Generify
Why would the decorator design pattern only work with interfaces? Maybe we're talking about two different this here? (I'm talking about this one: http://en.wikipedia.org/wiki/Decorator_pattern) I can see why behaviors were introduced. A simple example: a factory method creates a link. In my subclass I want the same link with the same onClick behavior but I also want "hello" to be outputted to System.out. How would I go about doing this with a Behavior? I couldn't figure it out... (which isn't saying it's impossible). Matthijs [EMAIL PROTECTED] wrote: decorators only work with interfaces, component class is not. This is part of the reason why we have behaviors -igor On 6/12/08, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: Some useful design patterns like Decorator don't work with final methods. Wicket components sometimes have overridable factory methods for child components. The decorator pattern could be very useful here, because you'd be able to decorate the original component with some extra functionality (Link.onClick for example). Unfortunately this doesn't work because some methods are final. Matthijs Igor Vaynberg wrote: i mean generally, for methods, fields, and func args :) most of this stuff can stay final, but people dont bother doing it because its extra typing. -igor On Thu, Jun 12, 2008 at 8:38 AM, James Carman <[EMAIL PROTECTED]> wrote: You mean like C++? On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: indeed. i wouldnt mind if final was the default in java :) -igor On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: Without the use of final wicket would not have made it this far. Martijn On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: I understand the reasoning, however I think "best practice" can be debated. To use your example Swing allows the user to override quite a bit, and it doesn't make any (or very few) assumptions on what should and should not be done. I don't like API's that assume I'm an idiot and prevent me from manipulating them how I see fit. If I cause a bug that I have to deal with, thats *my* problem to resolve. In my book (and I'm not the only one) excessive use of final is an anti-pattern. - Brill Pappin On 12-Jun-08, at 10:01 AM, cowwoc wrote: Brill, This is actually an API "best practice". Classes fall into two categories: ones designed for subclassing, and ones designed to be final. The same goes for methods. Swing is full of examples of what goes wrong when people override methods in classes that haven't been designed with subclassing in mind. Gili Brill Pappin wrote: on removing the finals The final members are the worst thing I've had to deal with in Wicket so far. Although I understand that there may be a reason for them, they are more a hinderance than anything else and seem to be trying to "protect users from themselves". - Brill Pappin On 12-Jun-08, at 1:03 AM, cowwoc wrote: Have you considered moving from subclassing to composition in Wicket using Callable? Currently it is quite common for developers to subclass a component in order to override isVisible() and other properties. I am proposing that instead the component classes become final and properties may only be set using setter methods. The setter methods would take Callable instead of T, so for example setVisible(boolean) would become setVisible(Callable) The benefit of this approach is that you could introduce static factory methods to the Wicket components which would make them much easier to use in their Generic form. You could then introduce various helper classes to create Callable for constant values, such as Callable.valueOf(true) would return a Callable that always returns true. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html 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/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html 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: [EMA
Re: Making Component easier to Generify
decorators only work with interfaces, component class is not. This is part of the reason why we have behaviors -igor On 6/12/08, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: > Some useful design patterns like Decorator don't work with final > methods. Wicket components sometimes have overridable factory methods > for child components. The decorator pattern could be very useful here, > because you'd be able to decorate the original component with some extra > functionality (Link.onClick for example). Unfortunately this doesn't > work because some methods are final. > > Matthijs > > Igor Vaynberg wrote: >> i mean generally, for methods, fields, and func args :) most of this >> stuff can stay final, but people dont bother doing it because its >> extra typing. >> >> -igor >> >> On Thu, Jun 12, 2008 at 8:38 AM, James Carman >> <[EMAIL PROTECTED]> wrote: >> >>> You mean like C++? >>> >>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <[EMAIL PROTECTED]> >>> wrote: >>> indeed. i wouldnt mind if final was the default in java :) -igor On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > Without the use of final wicket would not have made it this far. > > Martijn > > On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: > >> I understand the reasoning, however I think "best practice" can be >> debated. >> To use your example Swing allows the user to override quite a bit, and >> it >> doesn't make any (or very few) assumptions on what should and should >> not be >> done. >> >> I don't like API's that assume I'm an idiot and prevent me from >> manipulating >> them how I see fit. If I cause a bug that I have to deal with, thats >> *my* >> problem to resolve. >> >> In my book (and I'm not the only one) excessive use of final is an >> anti-pattern. >> >> - Brill Pappin >> >> On 12-Jun-08, at 10:01 AM, cowwoc wrote: >> >> >>> Brill, >>> >>> This is actually an API "best practice". Classes fall into two >>> categories: >>> ones designed for subclassing, and ones designed to be final. The >>> same >>> goes >>> for methods. Swing is full of examples of what goes wrong when people >>> override methods in classes that haven't been designed with >>> subclassing in >>> mind. >>> >>> Gili >>> >>> >>> Brill Pappin wrote: >>> on removing the finals The final members are the worst thing I've had to deal with in Wicket so far. Although I understand that there may be a reason for them, they are more a hinderance than anything else and seem to be trying to "protect users from themselves". - Brill Pappin On 12-Jun-08, at 1:03 AM, cowwoc wrote: > Have you considered moving from subclassing to composition in > Wicket > using > Callable? > > Currently it is quite common for developers to subclass a component > in order > to override isVisible() and other properties. I am proposing that > instead > the component classes become final and properties may only be set > using > setter methods. The setter methods would take Callable instead > of > T, so > for example setVisible(boolean) would become > setVisible(Callable) > > The benefit of this approach is that you could introduce static > factory > methods to the Wicket components which would make them much easier > to use in > their Generic form. You could then introduce various helper classes > to > create Callable for constant values, such as > Callable.valueOf(true) would > return a Callable that always returns true. > -- > View this message in context: > > http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html > 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/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html >>> Sent from the Wicket - User mailing list archive at Nabble.c
Re: users, please give us your opinion: what is your take on generics with Wicket
Eelco Hillenius wrote: > > Hi all, > > We have had several threads in this and the dev list, and some > discussions in the public on how to incorporate generics in Wicket. > > I'd like to use this thread to gather the opinions of as many regular > Wicket users as we can. Please help us get an impression of what our > users think about the issue by completing this simple survey. Note > that it is not a vote; we only want to get an idea of what you think. > > 1) Generifying* Wicket >[x] Can best be done like currently in the 1.4 branch, where models > and components are both generified. I care most about the improved > static type checking generified models and components give Wicket. >[ ] Can best be done in a limited fashion, where we only generify > IModel but not components. I care more about what generifying can do > for API clarity (declaring a component to only accept certain models > for instance) than static type checking. >[ ] Should be avoided, I prefer the way 1.3 works. Because... (fill > in your opinion here). >[ ] (anything other than these choices?) > > 2) How strongly do you feel about your choice above? >[x ] Whatever choice ultimately made, I'll happily convert/ start > using 1.4 and up. >[ ] I might rethink upgrading if my choice doesn't win. >[ ] I definitively won't be using 1.4. if Wicket doesn't go for my > preference. > > Thanks in advance for everyone participating, and pls feel free to > explain yourself further beyond just answering these questions! > > Eelco > > p.s. I suggest that the core devs and most active participants and > previous discussions wait a few days before giving their opinions so > that we don't flood the thread right from the start. > > * Parameterizing would probably be the better word to use, but > generifying seems to be the word that many people use. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17811756.html 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: PasswordTextField model?
On Thu, 12 Jun 2008, David Nedrow wrote: > Couldn't resolve model type of > Model:classname=[org.apache.wicket.model.CompoundPropertyModel > $ > AttachedCompoundPropertyModel > ]:nestedModel > = > [Model:classname > =[org.apache.wicket.model.CompoundPropertyModel]:nestedModel=[username > = "regular"]] for [MarkupContainer [Component id = password, page = > com.vzbi.ncs.argfrp.webapp.FilterRequest.app.LoginPage, path = > 0:signInPanel:signInForm:password.PasswordTextField, isVisible = true, > isVersioned = false]], please set the type yourself. > > Not setting the model does not seem to create a problem, but it would > seem that the system would prefer that models be set where applicable. I think that the problem is not actually the lack of model, but that Wicket cannot figure out to what type of object the model of the formcomponent is supposed to contain. Calling passwordField.setType(TypeOfMyPasswordObject.class) might help. The type can also be supplied in the constructor. > Is that the case? I have to admit, I'm a little anal about clearing > all warnings in my apps. I know the feeling :) Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations Oyhttp://www.ri.fi/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ValueMap, NullSafeKeyComparator and WicketNotSerializableException
Fixed On Thu, Jun 12, 2008 at 11:47 PM, Frank Bille <[EMAIL PROTECTED]> wrote: > https://issues.apache.org/jira/browse/WICKET-1694 > > > > On Thu, Jun 12, 2008 at 11:20 PM, Matthew Hanlon <[EMAIL PROTECTED]> > wrote: > >> Sorry, forgot to mention that I'm using wicket 1.4-SNAPSHOT, rev 667063. >> >> On Thu, Jun 12, 2008 at 4:18 PM, Matthew Hanlon <[EMAIL PROTECTED]> >> wrote: >> >> > I'm getting a WicketNotSerializableException on a couple of my pages. >> The >> > field that seems to be not serializable appears to be a Wicket class, >> > org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator. Any >> > suggestions? I saw a posting on the list earlier today that I though >> may >> > have something to do with it, but I cannot find the reference now. >> > >> > Here's the stacktrace for the exception I'm getting: >> > >> > ERROR Objects:1114 - Error serializing object class >> > com.mycompany.MyPage[object=[Page class = com.mycompany.MyPage, id = 3, >> > version = 0, ajax = 0]] >> > >> org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException: >> > Unable to serialize class: >> > org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator >> > Field hierarchy is: >> > 3 [class=com.mycompany.MyPage, path=3] >> > java.lang.Object org.apache.wicket.Component.data >> > [class=[Ljava.lang.Object;] >> > private org.apache.wicket.spring.ISpringContextLocator >> > org.apache.wicket.spring.SpringBeanLocator.springContextLocator[1] >> > [class=[Lorg.apache.wicket.MetaDataEntry;] >> > private org.apache.wicket.spring.ISpringContextLocator >> > org.apache.wicket.spring.SpringBeanLocator.springContextLocator[1][0] >> > [class=org.apache.wicket.MetaDataEntry] >> > java.lang.Object org.apache.wicket.MetaDataEntry.object >> > [class=org.apache.wicket.PageParameters] >> > private java.util.Comparator java.util.TreeMap.comparator >> > [class=org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator] >> <- >> > field that is not serializable >> > at >> > >> org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:349) >> > at >> > >> org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618) >> > at >> > >> org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541) >> > at >> > >> org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618) >> > at >> > >> org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541) >> > at >> > >> org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:395) >> > at >> > >> org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:395) >> > at >> > >> org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618) >> > at >> > >> org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541) >> > at >> > >> org.apache.wicket.util.io.SerializableChecker.writeObjectOverride(SerializableChecker.java:687) >> > at java.io.ObjectOutputStream.writeObject(Unknown Source) >> > at >> > >> org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:127) >> > at java.io.ObjectOutputStream.writeObject(Unknown Source) >> > at >> > org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1100) >> > at >> > >> org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:200) >> > at >> > >> org.apache.wicket.protocol.http.pagestore.DiskPageStore.storePage(DiskPageStore.java:814) >> > at >> > >> org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.put(SecondLevelCacheSessionStore.java:327) >> > at org.apache.wicket.Session.requestDetached(Session.java:1391) >> > at org.apache.wicket.RequestCycle.detach(RequestCycle.java:1113) >> > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1384) >> > at org.apache.wicket.RequestCycle.request(RequestCycle.java:499) >> > at >> > >> org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387) >> > at >> > >> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:199) >> > at >> > >> org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334) >> > at >> > >> org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:174) >> > at >> > >> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77) >> > at >> > >> org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334) >> > at >> > >> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:286) >> > at >> > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558) >> >
Re: The component(s) below failed to render
Do you add the DropDownChoice to the markup and forgott the wicket id? Michael_Bo wrote: > > Hi, > > i have a problem with some Components. I'm using Wicket Web beans. > If tried to add an additional form to a beanFrom. Then I get The following > Error: > > WicketMessage: The component(s) below failed to render. A common problem > is that you have added a component in code but forgot to reference it in > the markup (thus the component will never be rendered). > > 1. [MarkupContainer [Component id = beanRForm, page = metaWicket.EditPage, > path = 2:beanForm:beanRForm.TkDataBeanEditPanel$TkbeanForm, isVisible = > true, isVersioned = true]] > 2. [MarkupContainer [Component id = beanDropDown, page = > metaWicket.EditPage, path = > 2:beanForm:beanRForm:beanDropDown.DropDownChoice, isVisible = true, > isVersioned = false]] > > Root cause: > > org.apache.wicket.WicketRuntimeException: The component(s) below failed to > render. A common problem is that you have added a component in code but > forgot to reference it in the markup (thus the component will never be > rendered). > > 1. [MarkupContainer [Component id = beanRForm, page = metaWicket.EditPage, > path = 2:beanForm:beanRForm.TkDataBeanEditPanel$TkbeanForm, isVisible = > true, isVersioned = true]] > 2. [MarkupContainer [Component id = beanDropDown, page = > metaWicket.EditPage, path = > 2:beanForm:beanRForm:beanDropDown.DropDownChoice, isVisible = true, > isVersioned = false]] > > at org.apache.wicket.Page.checkRendering(Page.java:1116) > at org.apache.wicket.Page.renderPage(Page.java:914) > at > org.apache.wicket.protocol.http.WebRequestCycle.redirectTo(WebRequestCycle.java:163) > at > org.apache.wicket.request.target.component.PageRequestTarget.respond(PageRequestTarget.java:58) > at > org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104) > at > org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1243) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1330) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:493) > at > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:358) > at > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:194) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) > at org.mortbay.jetty.Server.handle(Server.java:295) > at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:503) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:827) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:511) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:210) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:379) > at > org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) > > What I want is an Additional Dropdownchoice in my beanFrom because the > beanFrom gets its field from a Bean. > I don't really know in what .html file I have to put this additional Bean > > chears > Michael > -- View this message in context: http://www.nabble.com/The-component%28s%29-below-failed-to-render-tp17803377p17810721.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PasswordTextField model?
Given the following from the wicket security quickstart (1.3- SNAPSHOT)... add(new PasswordTextField("password").setOutputMarkupId(false)); glassfish generates the following message Couldn't resolve model type of Model:classname=[org.apache.wicket.model.CompoundPropertyModel $ AttachedCompoundPropertyModel ]:nestedModel = [Model:classname =[org.apache.wicket.model.CompoundPropertyModel]:nestedModel=[username = "regular"]] for [MarkupContainer [Component id = password, page = com.vzbi.ncs.argfrp.webapp.FilterRequest.app.LoginPage, path = 0:signInPanel:signInForm:password.PasswordTextField, isVisible = true, isVersioned = false]], please set the type yourself. Not setting the model does not seem to create a problem, but it would seem that the system would prefer that models be set where applicable. Is that the case? I have to admit, I'm a little anal about clearing all warnings in my apps. What would an appropriate model be for the above PasswordTextField()? Models seem to be the most poorly "exampled" Wicket feature, in that examples of Models rarely tell one why they are needed and what role they perform. It's generally, here's an example to make your code work. Clearly, in most cases the model contains the data for the markup. But what would that data be for a PasswordTextField()? One isn't normally going to pre-fill a password field, correct? Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ValueMap, NullSafeKeyComparator and WicketNotSerializableException
https://issues.apache.org/jira/browse/WICKET-1694 On Thu, Jun 12, 2008 at 11:20 PM, Matthew Hanlon <[EMAIL PROTECTED]> wrote: > Sorry, forgot to mention that I'm using wicket 1.4-SNAPSHOT, rev 667063. > > On Thu, Jun 12, 2008 at 4:18 PM, Matthew Hanlon <[EMAIL PROTECTED]> > wrote: > > > I'm getting a WicketNotSerializableException on a couple of my pages. > The > > field that seems to be not serializable appears to be a Wicket class, > > org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator. Any > > suggestions? I saw a posting on the list earlier today that I though may > > have something to do with it, but I cannot find the reference now. > > > > Here's the stacktrace for the exception I'm getting: > > > > ERROR Objects:1114 - Error serializing object class > > com.mycompany.MyPage[object=[Page class = com.mycompany.MyPage, id = 3, > > version = 0, ajax = 0]] > > > org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException: > > Unable to serialize class: > > org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator > > Field hierarchy is: > > 3 [class=com.mycompany.MyPage, path=3] > > java.lang.Object org.apache.wicket.Component.data > > [class=[Ljava.lang.Object;] > > private org.apache.wicket.spring.ISpringContextLocator > > org.apache.wicket.spring.SpringBeanLocator.springContextLocator[1] > > [class=[Lorg.apache.wicket.MetaDataEntry;] > > private org.apache.wicket.spring.ISpringContextLocator > > org.apache.wicket.spring.SpringBeanLocator.springContextLocator[1][0] > > [class=org.apache.wicket.MetaDataEntry] > > java.lang.Object org.apache.wicket.MetaDataEntry.object > > [class=org.apache.wicket.PageParameters] > > private java.util.Comparator java.util.TreeMap.comparator > > [class=org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator] > <- > > field that is not serializable > > at > > > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:349) > > at > > > org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618) > > at > > > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541) > > at > > > org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618) > > at > > > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541) > > at > > > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:395) > > at > > > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:395) > > at > > > org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618) > > at > > > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541) > > at > > > org.apache.wicket.util.io.SerializableChecker.writeObjectOverride(SerializableChecker.java:687) > > at java.io.ObjectOutputStream.writeObject(Unknown Source) > > at > > > org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:127) > > at java.io.ObjectOutputStream.writeObject(Unknown Source) > > at > > org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1100) > > at > > > org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:200) > > at > > > org.apache.wicket.protocol.http.pagestore.DiskPageStore.storePage(DiskPageStore.java:814) > > at > > > org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.put(SecondLevelCacheSessionStore.java:327) > > at org.apache.wicket.Session.requestDetached(Session.java:1391) > > at org.apache.wicket.RequestCycle.detach(RequestCycle.java:1113) > > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1384) > > at org.apache.wicket.RequestCycle.request(RequestCycle.java:499) > > at > > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387) > > at > > > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:199) > > at > > > org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334) > > at > > > org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:174) > > at > > > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77) > > at > > > org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334) > > at > > > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:286) > > at > > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558) > > at org.mortbay.http.HttpContext.handle(HttpContext.java:1714) > > at > > > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:507) > > at org.mortbay.http.HttpConte
Re: when to save shopping basket for registered and anonymous users?
Hi! Simply because I don't want to do an if - else everytime an Object is added to the Basket. Basket can consist of many different Domain Objects. -Marcus On Wed, Jun 11, 2008 at 10:51 PM, Martin Makundi <[EMAIL PROTECTED]> wrote: > Hi! > > Why do you want to save the basket at a specific technical occurrence > such as .detach? > > If you want, you can always persist changes for a "registered" user > and on the other hand "never" persist them for "anonymous" users. > > Whenever the anonymous user becomes "registered" -> the basket is persisted. > > ** > Martin > > 2008/6/11 Marcus Mattila <[EMAIL PROTECTED]>: >> Hi! >> >> We are developing a shopping basket in our Wicket application. We >> would like to persist the basket as late as possible, and for >> anonymous users only if they sign up to the service. We don't want to >> save lots of anonymous Baskets to the database. We use Wicket 1.3.3 >> and Databinder (as a Hibernate "bridge"). What would be a good save >> point for the Basket-object? >> >> One potential solution is this: >> Override Session.detach() and save Basket there, if user is registered >> and Basket is dirty.. >> If user is anonymous, save when user has signed up and the User >> -domain object is created. >> >> Possibly in the next version: >> For anonymous users, create a cookiebased solution Amazon-style. >> >> Any glaring holes in our solution? Other ways of fulfilling this need? >> >> br, >> Marcus >> >> - >> 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: ValueMap, NullSafeKeyComparator and WicketNotSerializableException
Sorry, forgot to mention that I'm using wicket 1.4-SNAPSHOT, rev 667063. On Thu, Jun 12, 2008 at 4:18 PM, Matthew Hanlon <[EMAIL PROTECTED]> wrote: > I'm getting a WicketNotSerializableException on a couple of my pages. The > field that seems to be not serializable appears to be a Wicket class, > org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator. Any > suggestions? I saw a posting on the list earlier today that I though may > have something to do with it, but I cannot find the reference now. > > Here's the stacktrace for the exception I'm getting: > > ERROR Objects:1114 - Error serializing object class > com.mycompany.MyPage[object=[Page class = com.mycompany.MyPage, id = 3, > version = 0, ajax = 0]] > org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException: > Unable to serialize class: > org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator > Field hierarchy is: > 3 [class=com.mycompany.MyPage, path=3] > java.lang.Object org.apache.wicket.Component.data > [class=[Ljava.lang.Object;] > private org.apache.wicket.spring.ISpringContextLocator > org.apache.wicket.spring.SpringBeanLocator.springContextLocator[1] > [class=[Lorg.apache.wicket.MetaDataEntry;] > private org.apache.wicket.spring.ISpringContextLocator > org.apache.wicket.spring.SpringBeanLocator.springContextLocator[1][0] > [class=org.apache.wicket.MetaDataEntry] > java.lang.Object org.apache.wicket.MetaDataEntry.object > [class=org.apache.wicket.PageParameters] > private java.util.Comparator java.util.TreeMap.comparator > [class=org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator] <- > field that is not serializable > at > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:349) > at > org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618) > at > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541) > at > org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618) > at > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541) > at > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:395) > at > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:395) > at > org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618) > at > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541) > at > org.apache.wicket.util.io.SerializableChecker.writeObjectOverride(SerializableChecker.java:687) > at java.io.ObjectOutputStream.writeObject(Unknown Source) > at > org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:127) > at java.io.ObjectOutputStream.writeObject(Unknown Source) > at > org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1100) > at > org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:200) > at > org.apache.wicket.protocol.http.pagestore.DiskPageStore.storePage(DiskPageStore.java:814) > at > org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.put(SecondLevelCacheSessionStore.java:327) > at org.apache.wicket.Session.requestDetached(Session.java:1391) > at org.apache.wicket.RequestCycle.detach(RequestCycle.java:1113) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1384) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:499) > at > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387) > at > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:199) > at > org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334) > at > org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:174) > at > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77) > at > org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:286) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1714) > at > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:507) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1664) > at org.mortbay.http.HttpServer.service(HttpServer.java:863) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:775) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:939) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:792) > at > org.mortbay.http.Sock
ValueMap, NullSafeKeyComparator and WicketNotSerializableException
I'm getting a WicketNotSerializableException on a couple of my pages. The field that seems to be not serializable appears to be a Wicket class, org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator. Any suggestions? I saw a posting on the list earlier today that I though may have something to do with it, but I cannot find the reference now. Here's the stacktrace for the exception I'm getting: ERROR Objects:1114 - Error serializing object class com.mycompany.MyPage[object=[Page class = com.mycompany.MyPage, id = 3, version = 0, ajax = 0]] org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException: Unable to serialize class: org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator Field hierarchy is: 3 [class=com.mycompany.MyPage, path=3] java.lang.Object org.apache.wicket.Component.data [class=[Ljava.lang.Object;] private org.apache.wicket.spring.ISpringContextLocator org.apache.wicket.spring.SpringBeanLocator.springContextLocator[1] [class=[Lorg.apache.wicket.MetaDataEntry;] private org.apache.wicket.spring.ISpringContextLocator org.apache.wicket.spring.SpringBeanLocator.springContextLocator[1][0] [class=org.apache.wicket.MetaDataEntry] java.lang.Object org.apache.wicket.MetaDataEntry.object [class=org.apache.wicket.PageParameters] private java.util.Comparator java.util.TreeMap.comparator [class=org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator] <- field that is not serializable at org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:349) at org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618) at org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541) at org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618) at org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541) at org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:395) at org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:395) at org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618) at org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541) at org.apache.wicket.util.io.SerializableChecker.writeObjectOverride(SerializableChecker.java:687) at java.io.ObjectOutputStream.writeObject(Unknown Source) at org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:127) at java.io.ObjectOutputStream.writeObject(Unknown Source) at org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1100) at org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:200) at org.apache.wicket.protocol.http.pagestore.DiskPageStore.storePage(DiskPageStore.java:814) at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.put(SecondLevelCacheSessionStore.java:327) at org.apache.wicket.Session.requestDetached(Session.java:1391) at org.apache.wicket.RequestCycle.detach(RequestCycle.java:1113) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1384) at org.apache.wicket.RequestCycle.request(RequestCycle.java:499) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:199) at org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334) at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:174) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77) at org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:286) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558) at org.mortbay.http.HttpContext.handle(HttpContext.java:1714) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:507) at org.mortbay.http.HttpContext.handle(HttpContext.java:1664) at org.mortbay.http.HttpServer.service(HttpServer.java:863) at org.mortbay.http.HttpConnection.service(HttpConnection.java:775) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:939) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:792) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:455) Caused by: java.io.NotSerializableException: org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator at java.io.ObjectOutputStr
Re: Making Component easier to Generify
Some useful design patterns like Decorator don't work with final methods. Wicket components sometimes have overridable factory methods for child components. The decorator pattern could be very useful here, because you'd be able to decorate the original component with some extra functionality (Link.onClick for example). Unfortunately this doesn't work because some methods are final. Matthijs Igor Vaynberg wrote: i mean generally, for methods, fields, and func args :) most of this stuff can stay final, but people dont bother doing it because its extra typing. -igor On Thu, Jun 12, 2008 at 8:38 AM, James Carman <[EMAIL PROTECTED]> wrote: You mean like C++? On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: indeed. i wouldnt mind if final was the default in java :) -igor On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: Without the use of final wicket would not have made it this far. Martijn On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: I understand the reasoning, however I think "best practice" can be debated. To use your example Swing allows the user to override quite a bit, and it doesn't make any (or very few) assumptions on what should and should not be done. I don't like API's that assume I'm an idiot and prevent me from manipulating them how I see fit. If I cause a bug that I have to deal with, thats *my* problem to resolve. In my book (and I'm not the only one) excessive use of final is an anti-pattern. - Brill Pappin On 12-Jun-08, at 10:01 AM, cowwoc wrote: Brill, This is actually an API "best practice". Classes fall into two categories: ones designed for subclassing, and ones designed to be final. The same goes for methods. Swing is full of examples of what goes wrong when people override methods in classes that haven't been designed with subclassing in mind. Gili Brill Pappin wrote: on removing the finals The final members are the worst thing I've had to deal with in Wicket so far. Although I understand that there may be a reason for them, they are more a hinderance than anything else and seem to be trying to "protect users from themselves". - Brill Pappin On 12-Jun-08, at 1:03 AM, cowwoc wrote: Have you considered moving from subclassing to composition in Wicket using Callable? Currently it is quite common for developers to subclass a component in order to override isVisible() and other properties. I am proposing that instead the component classes become final and properties may only be set using setter methods. The setter methods would take Callable instead of T, so for example setVisible(boolean) would become setVisible(Callable) The benefit of this approach is that you could introduce static factory methods to the Wicket components which would make them much easier to use in their Generic form. You could then introduce various helper classes to create Callable for constant values, such as Callable.valueOf(true) would return a Callable that always returns true. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html 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/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html 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] -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - 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: Making Component easier to Generify
Could I dig this one back up then ;) http://www.nabble.com/Creating-Custom-Form-Components-td16159841.html#a1 6159841 Basically my request was to remove final from FormComponent.add(IValidator...) to aid in creating custom form component subclasses based on precedent with Component.add(IBehavior...) -Original Message- From: Eelco Hillenius [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 12:51 PM To: users@wicket.apache.org Subject: Re: Making Component easier to Generify > However, I am *in no way asking* the developers to reverse the "final" > policy. We actually relaxed that way more as we felt more confident about Wicket's API and as motivated requests came in. Personally, I think using final or not should be a deliberate choice (not automatic). If you never use it, you can arrive to that evolutionary dead-end pretty quickly (or indeed will have to break clients all the time), but if you over-use it, your framework will lack flexibility. Anyway, IF you stumble upon a final in a place where you'd like to see it go, you can always send a motivated request for that. We've typically been willing to remove finals when a good motivation was given. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AjaxSubmitLink refreshing problem
On Thu, 12 Jun 2008, alesp wrote: > Panel >| > --> Form > | > --> WebMarkupContainer (setOutputMarkupId(true)) > || > |--> ListView (with a > LoadableDetachableModel) > | | > | --> { populateItem { > AjaxSubmitLink (to "delete" an element. Updates the WebMarkupContainer) } } > --> AutoCompleteTextField > | > --> AjaxSubmitLink (to "add" an element) > > The problem is that the "add" link (the AjaxSubmitLink at the bottom of the > diagram) is working fine, but the "delete" is not, and the code is pretty What a cool diagram :) Have you called setReuseItems(true) for the ListView by any change? (If you have, I understand you should call removeAll to get the model changes to show: http://www.nabble.com/Re%3A-ListViews-in-a-form-question-p17786806.html ) Have you checked that the stuff that the LoadableDetachableModel returns for the ListView is correct after the delete? Have you checked that the ListView reads the contents from the model on rendering for the ajax update? Putting a Thread.dumpStack() in the load implementation of your LoadableDetachableModel will probably show easily when the ListView refreshes its contents. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations Oyhttp://www.ri.fi/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to add a TextField in a Dynamically created DefaultDataTable
your textfield doesnt have a model -igor On Thu, Jun 12, 2008 at 11:06 AM, galbelli <[EMAIL PROTECTED]> wrote: > > Thanks, the Fragment example did help in that I have the table rendering > properly. When I attempt to submit the form I get the following error: > > WicketMessage: Method onFormSubmitted of interface > org.apache.wicket.markup.html.form.IFormSubmitListener targeted at component > [MarkupContainer [Component id = form, page = > com.apollo.pricing.ui.HomePage, path = > 0:tabs:panel:form.PricingBySourcePanel$1, isVisible = true, isVersioned = > true]] threw an exception > > Root cause: > > java.lang.IllegalStateException: Attempt to set model object on null model > of component: tabs:panel:form:table:rows:4:cells:11:cell:edit > at org.apache.wicket.Component.setModelObject(Component.java:2510) > at > org.apache.wicket.markup.html.form.FormComponent.updateModel(FormComponent.java:1002) > at org.apache.wicket.markup.html.form.Form$14.validate(Form.java:1642) > at > org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent(Form.java:160) > at > org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper(FormComponent.java:403) > > Any ideas? > > > > > > jwcarman wrote: >> >> The markup for the datatable uses (or maybe span) for each >> cell's item. So, you need to give it something that it can put on a >> span. That would be a panel or fragment (as suggested). Did you see >> my earlier post about a FragmentColumn class? It might be useful in >> your case. >> >> On Thu, Jun 12, 2008 at 12:50 PM, galbelli <[EMAIL PROTECTED]> >> wrote: >>> >>> Not sure I understand how to accomplish this. Even if I wrap it in a >>> panel >>> won't it be looking for markup? >>> >>> My current markup for the dynamic table is as follows: >>> >>> http://wicket.apache.org/";> >>> >>> >>>Prices by Source >>> >>> >>> >>> >>> >>>Portfolio: >> wicket:id="portfolioSelect"> >>> >>>>> wicket:id="table"> >>> >>> >>> >>> >>> >>> >>> >>> And the code" >>> >>> >>>List columns = new ArrayList(); >>> >>>columns.add(new PropertyColumn(new Model("CUSIP"), "cusip", >>> "cusip")); >>>columns.add(new PropertyColumn(new Model("Description"), >>> "description", "description")); >>> >>>PropertyColumn aPropertyColumn = new PropertyColumn(new >>> Model("Override"), "overridePrice", "overridePrice") >>>{ >>>public void populateItem(Item item, String componentId, IModel >>> model) >>>{ >>>TextField aTextField = new TextField(componentId); >>>item.add(aTextField ); >>>} >>> >>>}; >>>columns.add(aPropertyColumn); >>> >>> DefaultDataTable aDefaultDataTable = new DefaultDataTable("table", >>> columns, portfolioProvider, 8); >>> >>> >>> >>> >>> >>> >>> >>> >>> igor.vaynberg wrote: wrap the textfield in a fragment or a panel -igor On Wed, Jun 11, 2008 at 3:39 PM, galbelli <[EMAIL PROTECTED]> wrote: > > I am creating a DefaultDataTable dynamically as I only know the number > of > columns at runtime. All is working nicely but I now need to have one of > the > columns contain a TextField and not a Label. I am receiving the > following > error: > > WicketMessage: Component cell must be applied to a tag of type 'input', > not > '' (line 0, column 0) > > How can I control the markup so I may change the HTML from span to > input? > -- > View this message in context: > http://www.nabble.com/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17788822.html > 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/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17804562.html >>> 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/How-to-add-a-TextField-in
Re: How to add a TextField in a Dynamically created DefaultDataTable
Thanks, the Fragment example did help in that I have the table rendering properly. When I attempt to submit the form I get the following error: WicketMessage: Method onFormSubmitted of interface org.apache.wicket.markup.html.form.IFormSubmitListener targeted at component [MarkupContainer [Component id = form, page = com.apollo.pricing.ui.HomePage, path = 0:tabs:panel:form.PricingBySourcePanel$1, isVisible = true, isVersioned = true]] threw an exception Root cause: java.lang.IllegalStateException: Attempt to set model object on null model of component: tabs:panel:form:table:rows:4:cells:11:cell:edit at org.apache.wicket.Component.setModelObject(Component.java:2510) at org.apache.wicket.markup.html.form.FormComponent.updateModel(FormComponent.java:1002) at org.apache.wicket.markup.html.form.Form$14.validate(Form.java:1642) at org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent(Form.java:160) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper(FormComponent.java:403) Any ideas? jwcarman wrote: > > The markup for the datatable uses (or maybe span) for each > cell's item. So, you need to give it something that it can put on a > span. That would be a panel or fragment (as suggested). Did you see > my earlier post about a FragmentColumn class? It might be useful in > your case. > > On Thu, Jun 12, 2008 at 12:50 PM, galbelli <[EMAIL PROTECTED]> > wrote: >> >> Not sure I understand how to accomplish this. Even if I wrap it in a >> panel >> won't it be looking for markup? >> >> My current markup for the dynamic table is as follows: >> >> http://wicket.apache.org/";> >> >> >>Prices by Source >> >> >> >> >> >>Portfolio: > wicket:id="portfolioSelect"> >> >>> wicket:id="table"> >> >> >> >> >> >> >> >> And the code" >> >> >>List columns = new ArrayList(); >> >>columns.add(new PropertyColumn(new Model("CUSIP"), "cusip", >> "cusip")); >>columns.add(new PropertyColumn(new Model("Description"), >> "description", "description")); >> >>PropertyColumn aPropertyColumn = new PropertyColumn(new >> Model("Override"), "overridePrice", "overridePrice") >>{ >>public void populateItem(Item item, String componentId, IModel >> model) >>{ >>TextField aTextField = new TextField(componentId); >>item.add(aTextField ); >>} >> >>}; >>columns.add(aPropertyColumn); >> >> DefaultDataTable aDefaultDataTable = new DefaultDataTable("table", >> columns, portfolioProvider, 8); >> >> >> >> >> >> >> >> >> igor.vaynberg wrote: >>> >>> wrap the textfield in a fragment or a panel >>> >>> -igor >>> >>> On Wed, Jun 11, 2008 at 3:39 PM, galbelli <[EMAIL PROTECTED]> >>> wrote: I am creating a DefaultDataTable dynamically as I only know the number of columns at runtime. All is working nicely but I now need to have one of the columns contain a TextField and not a Label. I am receiving the following error: WicketMessage: Component cell must be applied to a tag of type 'input', not '' (line 0, column 0) How can I control the markup so I may change the HTML from span to input? -- View this message in context: http://www.nabble.com/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17788822.html 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/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17804562.html >> 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/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17806187.html 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: styling option tag in dropdownlist
use Select/SelectOption components rather then dropdownchoice -igor On Thu, Jun 12, 2008 at 9:57 AM, Mathias P.W Nilsson <[EMAIL PROTECTED]> wrote: > > Hi! > > How can I style a certain option in a select list? I want to provide > diffrent colors for main categories in a drop down list. > -- > View this message in context: > http://www.nabble.com/styling-option-tag-in-dropdownlist-tp17804741p17804741.html > 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: Making Component easier to Generify
On Thu, Jun 12, 2008 at 9:00 AM, Brill Pappin <[EMAIL PROTECTED]> wrote: > That is the most compelling argument I have ever heard (maintainability > going forward). > saying "i like this by default" as most have done is no argument at all :) i suppose whenever you write any method that is consumed by hundreds of other developers you put a lot of thought and analysis into all the usecases for which those hundreds of developers will override this method. you think of all the corner cases, and all the things that can go wrong. you do all this by default right? no, you dont? then it is much better to make the method final by default, and once you have done all of the above and made sure that it will all work then remove the final. -igor > > However I disagree "best" is final by default... it should be the other way > around, where things are only marked final if there is a good and immediate > reason to do so. > > Although the debate is long and about as convoluted as the debate of > hungarian notation was, personal experience suggests that everything final > causes more problems than it's worth (I consider the Quartz API to be poor > for that reason also). > > However, I am *in no way asking* the developers to reverse the "final" > policy. its working, and working fairly well. I think I may have started a > thread here that is less than productive and unless others feel that there > needs to be a debate on the issue, I'll let it drop. > > - Brill Pappin > > On 12-Jun-08, at 11:50 AM, Zappaterrini, Larry wrote: > >> It is not about assuming anyone is an idiot. It is about preserving >> maintainability and allowing an API to evolve without breaking client >> code. The best approach is to mark members as final unless there is a >> compelling reason not to. Final is a safeguard for APIs to know what >> behavior is guaranteed to persist as development and evolution of the >> API is carried out. Occasionally a user can come up with a good argument >> for removing the final restriction and makes their case, affecting a >> change. >> >> It is very easy to create an evolutionary dead end for an API by >> allowing everything to be overridden. So either deprecate and start over >> or risk breaking client code and have your users hate you for it :) >> >> -Original Message- >> From: Brill Pappin [mailto:[EMAIL PROTECTED] >> Sent: Thursday, June 12, 2008 11:09 AM >> To: users@wicket.apache.org >> Subject: Re: Making Component easier to Generify >> >> I understand the reasoning, however I think "best practice" can be >> debated. >> To use your example Swing allows the user to override quite a bit, and >> it doesn't make any (or very few) assumptions on what should and >> should not be done. >> >> I don't like API's that assume I'm an idiot and prevent me from >> manipulating them how I see fit. If I cause a bug that I have to deal >> with, thats *my* problem to resolve. >> >> In my book (and I'm not the only one) excessive use of final is an >> anti-pattern. >> >> - Brill Pappin >> >> On 12-Jun-08, at 10:01 AM, cowwoc wrote: >> >>> >>> Brill, >>> >>> This is actually an API "best practice". Classes fall into two >>> categories: >>> ones designed for subclassing, and ones designed to be final. The >>> same goes >>> for methods. Swing is full of examples of what goes wrong when people >>> override methods in classes that haven't been designed with >>> subclassing in >>> mind. >>> >>> Gili >>> >>> >>> Brill Pappin wrote: on removing the finals The final members are the worst thing I've had to deal with in Wicket so far. Although I understand that there may be a reason for them, they are more a hinderance than anything else and seem to be trying to "protect users from themselves". - Brill Pappin On 12-Jun-08, at 1:03 AM, cowwoc wrote: > > > Have you considered moving from subclassing to composition in Wicket > using > Callable? > > Currently it is quite common for developers to subclass a component > in order > to override isVisible() and other properties. I am proposing that > instead > the component classes become final and properties may only be set > using > setter methods. The setter methods would take Callable instead of > T, so > for example setVisible(boolean) would become > setVisible(Callable) > > The benefit of this approach is that you could introduce static > factory > methods to the Wicket components which would make them much easier > to use in > their Generic form. You could then introduce various helper > classes to > create Callable for constant values, such as > Callable.valueOf(true) would > return a Callable that always returns true. > -- > View this message in context: > >> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo >> ur-take-on-generics-with-Wicket-tp17589984p17792488.html >>>
RE: How to get context path
Done: https://issues.apache.org/jira/browse/WICKET-1700 -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 11:32 AM To: users@wicket.apache.org Subject: Re: How to get context path jira is your friend -igor On Thu, Jun 12, 2008 at 4:46 AM, Hoover, William <[EMAIL PROTECTED]> wrote: > It would be better if ContextImage was a behavior rather than an > actual component. For instance, if you have an html input of > type=image (or a link for that matter) you can still utilize the > behavior whereas a component you cannot ;o) > > -Original Message- > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 11, 2008 3:29 PM > To: users@wicket.apache.org > Subject: Re: How to get context path > > see ContextImage > > -igor > > On Wed, Jun 11, 2008 at 12:10 PM, Patel, Sanjay <[EMAIL PROTECTED]> > wrote: >> Hi, >> >> my images in the application are in webapp/image folder. How to get >> Context Path in wicket so I can prepend this path to display the > image. >> I am looking for something like this. >> >> getContextPath() + "image/icon.gif"; >> >> Please suggest how to do that. >> >> Thanks, >> Sanjay. >> >> >> - >> 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modifying QuickStart to serve static content in embedded Jetty (was: RE: Tomcat 5.5.9 isn't running Quickstart)
JIRA issue & mvn clean, I'd say... /Gwyn On Thu, Jun 12, 2008 at 5:28 PM, Frank Silbermann < [EMAIL PROTECTED]> wrote: > Well, I guess the only thing to do is try and minimally modify the > QuickStart project with code that exhibits the problem and let others > try it. Should I submit it as a JIRA issue (to be closed when it is > determined what I'm doing wrong), or should I attach the .zip to a > mailing list message? Should I "mvn clean" it before zipping it to save > space? > > -Original Message- > From: Martijn Dashorst [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 12, 2008 9:11 AM > To: users@wicket.apache.org > Subject: Re: Modifying QuickStart to serve static content in embedded > Jetty (was: RE: Tomcat 5.5.9 isn't running Quickstart) > > No, because the JSP servlet is needed to compile JSPs into servlet code. > An unmodified configuration generated by the Wicket quickstart on our > website serves static images perfectly well. You really are doing > something funky. > > Martijn > > On Thu, Jun 12, 2008 at 4:07 PM, Frank Silbermann > <[EMAIL PROTECTED]> wrote: > > Yes, the QuickStart itself works. As for your ability to serve > > images, it might depend whether these are images stored with the .html > > > and .java files for Wicket to pick up, versus images that are stored > > as static objects. I googled the INFO - log warning " - NO JSP > > Support for /, did not find org.apache.jasper.servlet.JspServlet" > > > > and found http://code.google.com/p/run-jetty-run/wiki/GettingStarted > > about running Wicket projects with Jetty in Eclipse. It contains the > > following comments: > > > > Comment by angelo.mariano, Jan 02, 2008 > > When I try to launch it, I get the following error: 2008-01-02 > > 10:11:55.191::INFO: Logging to STDERR > > via org.mortbay.log.StdErrLog? 2008-01-02 10:11:55.300::INFO: > > jetty-6.1.6 2008-01-02 > > 10:11:55.441::INFO: NO JSP Support for /, did not find > > org.apache.jasper.servlet.JspServlet? > > 2008-01-02 10:11:55.659:/:INFO: default: init 2008-01-02 > > 10:11:55.659:/:INFO: jsp: init 2008-01-02 > > 10:11:55.691::INFO: Started [EMAIL PROTECTED]:8080 > > > > and then I am not able to compile jsp. Do you know how to solve this > > > problem? Thank you > > > > Comment by eelco.hillenius, Jan 02, 2008 > > Ah, I probably have to include the appropriate libs to turn JSP > > support on. Could you please file a > > ticket? I'll get to it shortly. > > > > > > > > Eelco, could that discussion have anything to do with my problem? > > > > -Original Message- > > From: Martijn Dashorst [mailto:[EMAIL PROTECTED] > > Sent: Thursday, June 12, 2008 1:23 AM > > To: users@wicket.apache.org > > Subject: Re: Tomcat 5.5.9 isn't running Quickstart > > > > The quickstart works for me without modifications. It serves images, > > etc. out of the box, every time. > > > > Martijn > > > > On Thu, Jun 12, 2008 at 12:54 AM, Frank Silbermann > > <[EMAIL PROTECTED]> wrote: > >> Searching for some clue as to why my modification of the QuickStart > >> application is serving images when run in Tomcat but not when running > > >> in embedded Jetty via Eclipse, I found: > >> > >> http://osdir.com/ml/java.jetty.support/2003-03/msg00045.html -- > >> titled > >> "Re: Re: jetty can't find images: msg#00045" > >> > >> It says, "You need the webdefaults file because it sets up the > >> Default > > > >> servlet which is what serves static resources like images. You can > >> also manually add the Default servlet if you want to avoid a > >> webdefaults.xml file." > >> > >> I think this is a clue. Looking at the console log when running > >> Jetty > > > >> in Eclipse I see: > >> > >> INFO - log- NO JSP Support for /, did not > > find > >> org.apache.jasper.servlet.JspServlet > >> > >> So what do I need to do to make it set up the Default servlet? Is > >> there a line I need to insert into Start.java to make it read the > >> webdefaults.xml file? I don't even have a webdefaults.xml file -- > >> unless it's buried somewhere inside one of the Jetty jars. > >> > >> Here's the complete console log when debugging Start.java to bring up > > >> Jetty (as demonstrated in > >> http://herebebeasties.com/2007-10-07/wicket-quickstart/). > >> > >> INFO - log- Logging to > >> org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via > >> org.mortbay.log.Slf4jLog > > STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP > >> INFO - log- jetty-6.1.4 > >> INFO - log- NO JSP Support for /, did not > > find > >> org.apache.jasper.servlet.JspServlet > >> INFO - log- No Transaction manager found - > if > >> your webapp requires one, please configure one. > >> INFO - Application- [TestApplication] init: Wicket > > core > >> library initializer > >> INFO - RequestListenerInterface - registered listener interface > >> [RequestListenerInterface name=IBeha
styling option tag in dropdownlist
Hi! How can I style a certain option in a select list? I want to provide diffrent colors for main categories in a drop down list. -- View this message in context: http://www.nabble.com/styling-option-tag-in-dropdownlist-tp17804741p17804741.html 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 add a TextField in a Dynamically created DefaultDataTable
The markup for the datatable uses (or maybe span) for each cell's item. So, you need to give it something that it can put on a span. That would be a panel or fragment (as suggested). Did you see my earlier post about a FragmentColumn class? It might be useful in your case. On Thu, Jun 12, 2008 at 12:50 PM, galbelli <[EMAIL PROTECTED]> wrote: > > Not sure I understand how to accomplish this. Even if I wrap it in a panel > won't it be looking for markup? > > My current markup for the dynamic table is as follows: > > http://wicket.apache.org/";> > > >Prices by Source > > > > > >Portfolio: wicket:id="portfolioSelect"> > > > > > > > > > > And the code" > > >List columns = new ArrayList(); > >columns.add(new PropertyColumn(new Model("CUSIP"), "cusip", > "cusip")); >columns.add(new PropertyColumn(new Model("Description"), > "description", "description")); > >PropertyColumn aPropertyColumn = new PropertyColumn(new > Model("Override"), "overridePrice", "overridePrice") >{ >public void populateItem(Item item, String componentId, IModel > model) >{ >TextField aTextField = new TextField(componentId); >item.add(aTextField ); >} > >}; >columns.add(aPropertyColumn); > > DefaultDataTable aDefaultDataTable = new DefaultDataTable("table", > columns, portfolioProvider, 8); > > > > > > > > > igor.vaynberg wrote: >> >> wrap the textfield in a fragment or a panel >> >> -igor >> >> On Wed, Jun 11, 2008 at 3:39 PM, galbelli <[EMAIL PROTECTED]> >> wrote: >>> >>> I am creating a DefaultDataTable dynamically as I only know the number of >>> columns at runtime. All is working nicely but I now need to have one of >>> the >>> columns contain a TextField and not a Label. I am receiving the following >>> error: >>> >>> WicketMessage: Component cell must be applied to a tag of type 'input', >>> not >>> '' (line 0, column 0) >>> >>> How can I control the markup so I may change the HTML from span to input? >>> -- >>> View this message in context: >>> http://www.nabble.com/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17788822.html >>> 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/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17804562.html > 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: Making Component easier to Generify
> However, I am *in no way asking* the developers to reverse the "final" > policy. We actually relaxed that way more as we felt more confident about Wicket's API and as motivated requests came in. Personally, I think using final or not should be a deliberate choice (not automatic). If you never use it, you can arrive to that evolutionary dead-end pretty quickly (or indeed will have to break clients all the time), but if you over-use it, your framework will lack flexibility. Anyway, IF you stumble upon a final in a place where you'd like to see it go, you can always send a motivated request for that. We've typically been willing to remove finals when a good motivation was given. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to add a TextField in a Dynamically created DefaultDataTable
Not sure I understand how to accomplish this. Even if I wrap it in a panel won't it be looking for markup? My current markup for the dynamic table is as follows: http://wicket.apache.org/";> Prices by Source Portfolio: And the code" List columns = new ArrayList(); columns.add(new PropertyColumn(new Model("CUSIP"), "cusip", "cusip")); columns.add(new PropertyColumn(new Model("Description"), "description", "description")); PropertyColumn aPropertyColumn = new PropertyColumn(new Model("Override"), "overridePrice", "overridePrice") { public void populateItem(Item item, String componentId, IModel model) { TextField aTextField = new TextField(componentId); item.add(aTextField ); } }; columns.add(aPropertyColumn); DefaultDataTable aDefaultDataTable = new DefaultDataTable("table", columns, portfolioProvider, 8); igor.vaynberg wrote: > > wrap the textfield in a fragment or a panel > > -igor > > On Wed, Jun 11, 2008 at 3:39 PM, galbelli <[EMAIL PROTECTED]> > wrote: >> >> I am creating a DefaultDataTable dynamically as I only know the number of >> columns at runtime. All is working nicely but I now need to have one of >> the >> columns contain a TextField and not a Label. I am receiving the following >> error: >> >> WicketMessage: Component cell must be applied to a tag of type 'input', >> not >> '' (line 0, column 0) >> >> How can I control the markup so I may change the HTML from span to input? >> -- >> View this message in context: >> http://www.nabble.com/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17788822.html >> 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/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17804562.html 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: Replace a fragment with AjaxLink
> OK I figured out what the problem is. > If you want to replace one fragment with another over AJAX, then they must > have the same "markupId"s. Yep. Not just for Ajax though... this is true for all component replacement. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Modifying QuickStart to serve static content in embedded Jetty (was: RE: Tomcat 5.5.9 isn't running Quickstart)
Well, I guess the only thing to do is try and minimally modify the QuickStart project with code that exhibits the problem and let others try it. Should I submit it as a JIRA issue (to be closed when it is determined what I'm doing wrong), or should I attach the .zip to a mailing list message? Should I "mvn clean" it before zipping it to save space? -Original Message- From: Martijn Dashorst [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 9:11 AM To: users@wicket.apache.org Subject: Re: Modifying QuickStart to serve static content in embedded Jetty (was: RE: Tomcat 5.5.9 isn't running Quickstart) No, because the JSP servlet is needed to compile JSPs into servlet code. An unmodified configuration generated by the Wicket quickstart on our website serves static images perfectly well. You really are doing something funky. Martijn On Thu, Jun 12, 2008 at 4:07 PM, Frank Silbermann <[EMAIL PROTECTED]> wrote: > Yes, the QuickStart itself works. As for your ability to serve > images, it might depend whether these are images stored with the .html > and .java files for Wicket to pick up, versus images that are stored > as static objects. I googled the INFO - log warning " - NO JSP > Support for /, did not find org.apache.jasper.servlet.JspServlet" > > and found http://code.google.com/p/run-jetty-run/wiki/GettingStarted > about running Wicket projects with Jetty in Eclipse. It contains the > following comments: > > Comment by angelo.mariano, Jan 02, 2008 > When I try to launch it, I get the following error: 2008-01-02 > 10:11:55.191::INFO: Logging to STDERR > via org.mortbay.log.StdErrLog? 2008-01-02 10:11:55.300::INFO: > jetty-6.1.6 2008-01-02 > 10:11:55.441::INFO: NO JSP Support for /, did not find > org.apache.jasper.servlet.JspServlet? > 2008-01-02 10:11:55.659:/:INFO: default: init 2008-01-02 > 10:11:55.659:/:INFO: jsp: init 2008-01-02 > 10:11:55.691::INFO: Started [EMAIL PROTECTED]:8080 > > and then I am not able to compile jsp. Do you know how to solve this > problem? Thank you > > Comment by eelco.hillenius, Jan 02, 2008 > Ah, I probably have to include the appropriate libs to turn JSP > support on. Could you please file a > ticket? I'll get to it shortly. > > > > Eelco, could that discussion have anything to do with my problem? > > -Original Message- > From: Martijn Dashorst [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 12, 2008 1:23 AM > To: users@wicket.apache.org > Subject: Re: Tomcat 5.5.9 isn't running Quickstart > > The quickstart works for me without modifications. It serves images, > etc. out of the box, every time. > > Martijn > > On Thu, Jun 12, 2008 at 12:54 AM, Frank Silbermann > <[EMAIL PROTECTED]> wrote: >> Searching for some clue as to why my modification of the QuickStart >> application is serving images when run in Tomcat but not when running >> in embedded Jetty via Eclipse, I found: >> >> http://osdir.com/ml/java.jetty.support/2003-03/msg00045.html -- >> titled >> "Re: Re: jetty can't find images: msg#00045" >> >> It says, "You need the webdefaults file because it sets up the >> Default > >> servlet which is what serves static resources like images. You can >> also manually add the Default servlet if you want to avoid a >> webdefaults.xml file." >> >> I think this is a clue. Looking at the console log when running >> Jetty > >> in Eclipse I see: >> >> INFO - log- NO JSP Support for /, did not > find >> org.apache.jasper.servlet.JspServlet >> >> So what do I need to do to make it set up the Default servlet? Is >> there a line I need to insert into Start.java to make it read the >> webdefaults.xml file? I don't even have a webdefaults.xml file -- >> unless it's buried somewhere inside one of the Jetty jars. >> >> Here's the complete console log when debugging Start.java to bring up >> Jetty (as demonstrated in >> http://herebebeasties.com/2007-10-07/wicket-quickstart/). >> >> INFO - log- Logging to >> org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via >> org.mortbay.log.Slf4jLog > STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP >> INFO - log- jetty-6.1.4 >> INFO - log- NO JSP Support for /, did not > find >> org.apache.jasper.servlet.JspServlet >> INFO - log- No Transaction manager found - if >> your webapp requires one, please configure one. >> INFO - Application- [TestApplication] init: Wicket > core >> library initializer >> INFO - RequestListenerInterface - registered listener interface >> [RequestListenerInterface name=IBehaviorListener, method=public >> abstract void > org.apache.wicket.behavior.IBehaviorListener.onRequest()] >> INFO - RequestListenerInterface - registered listener interface >> [RequestListenerInterface name=IBehaviorListener, method=public >> abstract void > org.apache.wicket.behavior.IBehaviorListener.onRequest()] >> INFO - Reque
Re: Making Component easier to Generify
If you override a method and your implementation violates the Liskov Substitution Principle, then it's your fault! :) On Thu, Jun 12, 2008 at 11:54 AM, cowwoc <[EMAIL PROTECTED]> wrote: > > > Actually, it's the other way around. Authors make methods final not because > *you* might make a mistake but rather because *they* might. Using final > methods simplifies their design a lot because they don't have to do all the > work you mentioned. Secondly, it leaves the API open to extension (without > breaking backwards compatibility) in a way that would be lost if anyone > could override the methods. > > I personally agree with your approach with the following major caveat: if > developers are able to override any method then it must be understood that > any implementation making assumptions not guaranteed by the API > specification is liable to break in future releases. Keep in mind that very > few things ever are guaranteed by the specification, so practically speaking > this means that your code is very likely to break as new releases come out. > > To be honest, I personally prefer approach #2 over final methods for public > projects because (in my experience) even open-source projects take forever > to fix bugs or add features that you might need right away. I'm a strong > believer that implementations that make incorrect assumptions deserve to > break in subsequent releases. One final benefit of #1 worth mentioning, > however, is that incorrect assumptions end up in a compile-time error > (roughly speaking) and even smart developers make mistakes every once in a > while. Consider what happens if you override foo() and forget to invoke > super.foo() by mistake. Those kinds of mistakes happen all the time. I'm > toying with the idea that approach #1 makes sense for in-house projects > where you are a co-owner and can make changes very quickly while approach #2 > makes sense for public projects when developers can't afford to wait on the > project owner. Put another way, maybe #1 makes sense for mature APIs whereas > #2 makes sense for experimental APIs (used to flesh out the various > use-cases you need to support). > > Gili > > > Brill Pappin wrote: >> >> I understand the reasoning, however I think "best practice" can be >> debated. >> To use your example Swing allows the user to override quite a bit, and >> it doesn't make any (or very few) assumptions on what should and >> should not be done. >> >> I don't like API's that assume I'm an idiot and prevent me from >> manipulating them how I see fit. If I cause a bug that I have to deal >> with, thats *my* problem to resolve. >> >> In my book (and I'm not the only one) excessive use of final is an >> anti-pattern. >> >> - Brill Pappin >> >> On 12-Jun-08, at 10:01 AM, cowwoc wrote: >> >>> >>> Brill, >>> >>> This is actually an API "best practice". Classes fall into two >>> categories: >>> ones designed for subclassing, and ones designed to be final. The >>> same goes >>> for methods. Swing is full of examples of what goes wrong when people >>> override methods in classes that haven't been designed with >>> subclassing in >>> mind. >>> >>> Gili >>> >>> >>> Brill Pappin wrote: on removing the finals The final members are the worst thing I've had to deal with in Wicket so far. Although I understand that there may be a reason for them, they are more a hinderance than anything else and seem to be trying to "protect users from themselves". - Brill Pappin On 12-Jun-08, at 1:03 AM, cowwoc wrote: > > > Have you considered moving from subclassing to composition in Wicket > using > Callable? > > Currently it is quite common for developers to subclass a component > in order > to override isVisible() and other properties. I am proposing that > instead > the component classes become final and properties may only be set > using > setter methods. The setter methods would take Callable instead of > T, so > for example setVisible(boolean) would become > setVisible(Callable) > > The benefit of this approach is that you could introduce static > factory > methods to the Wicket components which would make them much easier > to use in > their Generic form. You could then introduce various helper > classes to > create Callable for constant values, such as > Callable.valueOf(true) would > return a Callable that always returns true. > -- > View this message in context: > http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html > 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: Making Component easier to Generify
Very thoughtful and some good points, I don't entirely disagree with that. - Brill On 12-Jun-08, at 11:54 AM, cowwoc wrote: [...] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Component easier to Generify
That is the most compelling argument I have ever heard (maintainability going forward). saying "i like this by default" as most have done is no argument at all :) However I disagree "best" is final by default... it should be the other way around, where things are only marked final if there is a good and immediate reason to do so. Although the debate is long and about as convoluted as the debate of hungarian notation was, personal experience suggests that everything final causes more problems than it's worth (I consider the Quartz API to be poor for that reason also). However, I am *in no way asking* the developers to reverse the "final" policy. its working, and working fairly well. I think I may have started a thread here that is less than productive and unless others feel that there needs to be a debate on the issue, I'll let it drop. - Brill Pappin On 12-Jun-08, at 11:50 AM, Zappaterrini, Larry wrote: It is not about assuming anyone is an idiot. It is about preserving maintainability and allowing an API to evolve without breaking client code. The best approach is to mark members as final unless there is a compelling reason not to. Final is a safeguard for APIs to know what behavior is guaranteed to persist as development and evolution of the API is carried out. Occasionally a user can come up with a good argument for removing the final restriction and makes their case, affecting a change. It is very easy to create an evolutionary dead end for an API by allowing everything to be overridden. So either deprecate and start over or risk breaking client code and have your users hate you for it :) -Original Message- From: Brill Pappin [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 11:09 AM To: users@wicket.apache.org Subject: Re: Making Component easier to Generify I understand the reasoning, however I think "best practice" can be debated. To use your example Swing allows the user to override quite a bit, and it doesn't make any (or very few) assumptions on what should and should not be done. I don't like API's that assume I'm an idiot and prevent me from manipulating them how I see fit. If I cause a bug that I have to deal with, thats *my* problem to resolve. In my book (and I'm not the only one) excessive use of final is an anti-pattern. - Brill Pappin On 12-Jun-08, at 10:01 AM, cowwoc wrote: Brill, This is actually an API "best practice". Classes fall into two categories: ones designed for subclassing, and ones designed to be final. The same goes for methods. Swing is full of examples of what goes wrong when people override methods in classes that haven't been designed with subclassing in mind. Gili Brill Pappin wrote: on removing the finals The final members are the worst thing I've had to deal with in Wicket so far. Although I understand that there may be a reason for them, they are more a hinderance than anything else and seem to be trying to "protect users from themselves". - Brill Pappin On 12-Jun-08, at 1:03 AM, cowwoc wrote: Have you considered moving from subclassing to composition in Wicket using Callable? Currently it is quite common for developers to subclass a component in order to override isVisible() and other properties. I am proposing that instead the component classes become final and properties may only be set using setter methods. The setter methods would take Callable instead of T, so for example setVisible(boolean) would become setVisible(Callable) The benefit of this approach is that you could introduce static factory methods to the Wicket components which would make them much easier to use in their Generic form. You could then introduce various helper classes to create Callable for constant values, such as Callable.valueOf(true) would return a Callable that always returns true. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo ur-take-on-generics-with-Wicket-tp17589984p17792488.html 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/users%2C-please-give-us-your-opinion%3A-what-is-yo ur-take-on-generics-with-Wicket-tp17589984p17800710.html 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] __
The component(s) below failed to render
Hi, i have a problem with some Components. I'm using Wicket Web beans. If tried to add an additional form to a beanFrom. Then I get The following Error: WicketMessage: The component(s) below failed to render. A common problem is that you have added a component in code but forgot to reference it in the markup (thus the component will never be rendered). 1. [MarkupContainer [Component id = beanRForm, page = metaWicket.EditPage, path = 2:beanForm:beanRForm.TkDataBeanEditPanel$TkbeanForm, isVisible = true, isVersioned = true]] 2. [MarkupContainer [Component id = beanDropDown, page = metaWicket.EditPage, path = 2:beanForm:beanRForm:beanDropDown.DropDownChoice, isVisible = true, isVersioned = false]] Root cause: org.apache.wicket.WicketRuntimeException: The component(s) below failed to render. A common problem is that you have added a component in code but forgot to reference it in the markup (thus the component will never be rendered). 1. [MarkupContainer [Component id = beanRForm, page = metaWicket.EditPage, path = 2:beanForm:beanRForm.TkDataBeanEditPanel$TkbeanForm, isVisible = true, isVersioned = true]] 2. [MarkupContainer [Component id = beanDropDown, page = metaWicket.EditPage, path = 2:beanForm:beanRForm:beanDropDown.DropDownChoice, isVisible = true, isVersioned = false]] at org.apache.wicket.Page.checkRendering(Page.java:1116) at org.apache.wicket.Page.renderPage(Page.java:914) at org.apache.wicket.protocol.http.WebRequestCycle.redirectTo(WebRequestCycle.java:163) at org.apache.wicket.request.target.component.PageRequestTarget.respond(PageRequestTarget.java:58) at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1243) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1330) at org.apache.wicket.RequestCycle.request(RequestCycle.java:493) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:358) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:194) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:295) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:503) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:827) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:511) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:210) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:379) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) What I want is an Additional Dropdownchoice in my beanFrom because the beanFrom gets its field from a Bean. I don't really know in what .html file I have to put this additional Bean chears Michael -- View this message in context: http://www.nabble.com/The-component%28s%29-below-failed-to-render-tp17803377p17803377.html 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: Making Component easier to Generify
Actually, it's the other way around. Authors make methods final not because *you* might make a mistake but rather because *they* might. Using final methods simplifies their design a lot because they don't have to do all the work you mentioned. Secondly, it leaves the API open to extension (without breaking backwards compatibility) in a way that would be lost if anyone could override the methods. I personally agree with your approach with the following major caveat: if developers are able to override any method then it must be understood that any implementation making assumptions not guaranteed by the API specification is liable to break in future releases. Keep in mind that very few things ever are guaranteed by the specification, so practically speaking this means that your code is very likely to break as new releases come out. To be honest, I personally prefer approach #2 over final methods for public projects because (in my experience) even open-source projects take forever to fix bugs or add features that you might need right away. I'm a strong believer that implementations that make incorrect assumptions deserve to break in subsequent releases. One final benefit of #1 worth mentioning, however, is that incorrect assumptions end up in a compile-time error (roughly speaking) and even smart developers make mistakes every once in a while. Consider what happens if you override foo() and forget to invoke super.foo() by mistake. Those kinds of mistakes happen all the time. I'm toying with the idea that approach #1 makes sense for in-house projects where you are a co-owner and can make changes very quickly while approach #2 makes sense for public projects when developers can't afford to wait on the project owner. Put another way, maybe #1 makes sense for mature APIs whereas #2 makes sense for experimental APIs (used to flesh out the various use-cases you need to support). Gili Brill Pappin wrote: > > I understand the reasoning, however I think "best practice" can be > debated. > To use your example Swing allows the user to override quite a bit, and > it doesn't make any (or very few) assumptions on what should and > should not be done. > > I don't like API's that assume I'm an idiot and prevent me from > manipulating them how I see fit. If I cause a bug that I have to deal > with, thats *my* problem to resolve. > > In my book (and I'm not the only one) excessive use of final is an > anti-pattern. > > - Brill Pappin > > On 12-Jun-08, at 10:01 AM, cowwoc wrote: > >> >> Brill, >> >> This is actually an API "best practice". Classes fall into two >> categories: >> ones designed for subclassing, and ones designed to be final. The >> same goes >> for methods. Swing is full of examples of what goes wrong when people >> override methods in classes that haven't been designed with >> subclassing in >> mind. >> >> Gili >> >> >> Brill Pappin wrote: >>> >>> on removing the finals >>> >>> The final members are the worst thing I've had to deal with in Wicket >>> so far. >>> Although I understand that there may be a reason for them, they are >>> more a hinderance than anything else and seem to be trying to >>> "protect >>> users from themselves". >>> >>> - Brill Pappin >>> >>> >>> On 12-Jun-08, at 1:03 AM, cowwoc wrote: >>> Have you considered moving from subclassing to composition in Wicket using Callable? Currently it is quite common for developers to subclass a component in order to override isVisible() and other properties. I am proposing that instead the component classes become final and properties may only be set using setter methods. The setter methods would take Callable instead of T, so for example setVisible(boolean) would become setVisible(Callable) The benefit of this approach is that you could introduce static factory methods to the Wicket components which would make them much easier to use in their Generic form. You could then introduce various helper classes to create Callable for constant values, such as Callable.valueOf(true) would return a Callable that always returns true. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html 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/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-t
RE: Making Component easier to Generify
It is not about assuming anyone is an idiot. It is about preserving maintainability and allowing an API to evolve without breaking client code. The best approach is to mark members as final unless there is a compelling reason not to. Final is a safeguard for APIs to know what behavior is guaranteed to persist as development and evolution of the API is carried out. Occasionally a user can come up with a good argument for removing the final restriction and makes their case, affecting a change. It is very easy to create an evolutionary dead end for an API by allowing everything to be overridden. So either deprecate and start over or risk breaking client code and have your users hate you for it :) -Original Message- From: Brill Pappin [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 11:09 AM To: users@wicket.apache.org Subject: Re: Making Component easier to Generify I understand the reasoning, however I think "best practice" can be debated. To use your example Swing allows the user to override quite a bit, and it doesn't make any (or very few) assumptions on what should and should not be done. I don't like API's that assume I'm an idiot and prevent me from manipulating them how I see fit. If I cause a bug that I have to deal with, thats *my* problem to resolve. In my book (and I'm not the only one) excessive use of final is an anti-pattern. - Brill Pappin On 12-Jun-08, at 10:01 AM, cowwoc wrote: > > Brill, > > This is actually an API "best practice". Classes fall into two > categories: > ones designed for subclassing, and ones designed to be final. The > same goes > for methods. Swing is full of examples of what goes wrong when people > override methods in classes that haven't been designed with > subclassing in > mind. > > Gili > > > Brill Pappin wrote: >> >> on removing the finals >> >> The final members are the worst thing I've had to deal with in Wicket >> so far. >> Although I understand that there may be a reason for them, they are >> more a hinderance than anything else and seem to be trying to >> "protect >> users from themselves". >> >> - Brill Pappin >> >> >> On 12-Jun-08, at 1:03 AM, cowwoc wrote: >> >>> >>> >>> Have you considered moving from subclassing to composition in Wicket >>> using >>> Callable? >>> >>> Currently it is quite common for developers to subclass a component >>> in order >>> to override isVisible() and other properties. I am proposing that >>> instead >>> the component classes become final and properties may only be set >>> using >>> setter methods. The setter methods would take Callable instead of >>> T, so >>> for example setVisible(boolean) would become >>> setVisible(Callable) >>> >>> The benefit of this approach is that you could introduce static >>> factory >>> methods to the Wicket components which would make them much easier >>> to use in >>> their Generic form. You could then introduce various helper >>> classes to >>> create Callable for constant values, such as >>> Callable.valueOf(true) would >>> return a Callable that always returns true. >>> -- >>> View this message in context: >>> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo ur-take-on-generics-with-Wicket-tp17589984p17792488.html >>> 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/users%2C-please-give-us-your-opinion%3A-what-is-yo ur-take-on-generics-with-Wicket-tp17589984p17800710.html > 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] __ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Component easier to Generify
That's funny. By default I make every local variable final if I can. I guess it's just out of habit. I usually do the same for method parameters, too (I'm less diligent about that one). For methods, I usually just leave them be until I know for sure that I need them to be final. On Thu, Jun 12, 2008 at 11:42 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > i mean generally, for methods, fields, and func args :) most of this > stuff can stay final, but people dont bother doing it because its > extra typing. > > -igor > > On Thu, Jun 12, 2008 at 8:38 AM, James Carman > <[EMAIL PROTECTED]> wrote: >> You mean like C++? >> >> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: >>> indeed. i wouldnt mind if final was the default in java :) >>> >>> -igor >>> >>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>> <[EMAIL PROTECTED]> wrote: Without the use of final wicket would not have made it this far. Martijn On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: > I understand the reasoning, however I think "best practice" can be > debated. > To use your example Swing allows the user to override quite a bit, and it > doesn't make any (or very few) assumptions on what should and should not > be > done. > > I don't like API's that assume I'm an idiot and prevent me from > manipulating > them how I see fit. If I cause a bug that I have to deal with, thats *my* > problem to resolve. > > In my book (and I'm not the only one) excessive use of final is an > anti-pattern. > > - Brill Pappin > > On 12-Jun-08, at 10:01 AM, cowwoc wrote: > >> >> Brill, >> >> This is actually an API "best practice". Classes fall into two >> categories: >> ones designed for subclassing, and ones designed to be final. The same >> goes >> for methods. Swing is full of examples of what goes wrong when people >> override methods in classes that haven't been designed with subclassing >> in >> mind. >> >> Gili >> >> >> Brill Pappin wrote: >>> >>> on removing the finals >>> >>> The final members are the worst thing I've had to deal with in Wicket >>> so far. >>> Although I understand that there may be a reason for them, they are >>> more a hinderance than anything else and seem to be trying to "protect >>> users from themselves". >>> >>> - Brill Pappin >>> >>> >>> On 12-Jun-08, at 1:03 AM, cowwoc wrote: >>> Have you considered moving from subclassing to composition in Wicket using Callable? Currently it is quite common for developers to subclass a component in order to override isVisible() and other properties. I am proposing that instead the component classes become final and properties may only be set using setter methods. The setter methods would take Callable instead of T, so for example setVisible(boolean) would become setVisible(Callable) The benefit of this approach is that you could introduce static factory methods to the Wicket components which would make them much easier to use in their Generic form. You could then introduce various helper classes to create Callable for constant values, such as Callable.valueOf(true) would return a Callable that always returns true. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html 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/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html >> 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: Making Component easier to Generify
i mean generally, for methods, fields, and func args :) most of this stuff can stay final, but people dont bother doing it because its extra typing. -igor On Thu, Jun 12, 2008 at 8:38 AM, James Carman <[EMAIL PROTECTED]> wrote: > You mean like C++? > > On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: >> indeed. i wouldnt mind if final was the default in java :) >> >> -igor >> >> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >> <[EMAIL PROTECTED]> wrote: >>> Without the use of final wicket would not have made it this far. >>> >>> Martijn >>> >>> On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: I understand the reasoning, however I think "best practice" can be debated. To use your example Swing allows the user to override quite a bit, and it doesn't make any (or very few) assumptions on what should and should not be done. I don't like API's that assume I'm an idiot and prevent me from manipulating them how I see fit. If I cause a bug that I have to deal with, thats *my* problem to resolve. In my book (and I'm not the only one) excessive use of final is an anti-pattern. - Brill Pappin On 12-Jun-08, at 10:01 AM, cowwoc wrote: > > Brill, > > This is actually an API "best practice". Classes fall into two categories: > ones designed for subclassing, and ones designed to be final. The same > goes > for methods. Swing is full of examples of what goes wrong when people > override methods in classes that haven't been designed with subclassing in > mind. > > Gili > > > Brill Pappin wrote: >> >> on removing the finals >> >> The final members are the worst thing I've had to deal with in Wicket >> so far. >> Although I understand that there may be a reason for them, they are >> more a hinderance than anything else and seem to be trying to "protect >> users from themselves". >> >> - Brill Pappin >> >> >> On 12-Jun-08, at 1:03 AM, cowwoc wrote: >> >>> >>> >>> Have you considered moving from subclassing to composition in Wicket >>> using >>> Callable? >>> >>> Currently it is quite common for developers to subclass a component >>> in order >>> to override isVisible() and other properties. I am proposing that >>> instead >>> the component classes become final and properties may only be set >>> using >>> setter methods. The setter methods would take Callable instead of >>> T, so >>> for example setVisible(boolean) would become >>> setVisible(Callable) >>> >>> The benefit of this approach is that you could introduce static >>> factory >>> methods to the Wicket components which would make them much easier >>> to use in >>> their Generic form. You could then introduce various helper classes to >>> create Callable for constant values, such as >>> Callable.valueOf(true) would >>> return a Callable that always returns true. >>> -- >>> View this message in context: >>> >>> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html >>> 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/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html > 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] >>> >>> >>> >>> -- >>> Become a Wicket expert, learn from the best: http://wicketinaction.com >>> Apache Wicket 1.3.3 is released >>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 >>> >>> - >>> 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 PR
Re: Making Component easier to Generify
You mean like C++? On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > indeed. i wouldnt mind if final was the default in java :) > > -igor > > On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst > <[EMAIL PROTECTED]> wrote: >> Without the use of final wicket would not have made it this far. >> >> Martijn >> >> On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: >>> I understand the reasoning, however I think "best practice" can be debated. >>> To use your example Swing allows the user to override quite a bit, and it >>> doesn't make any (or very few) assumptions on what should and should not be >>> done. >>> >>> I don't like API's that assume I'm an idiot and prevent me from manipulating >>> them how I see fit. If I cause a bug that I have to deal with, thats *my* >>> problem to resolve. >>> >>> In my book (and I'm not the only one) excessive use of final is an >>> anti-pattern. >>> >>> - Brill Pappin >>> >>> On 12-Jun-08, at 10:01 AM, cowwoc wrote: >>> Brill, This is actually an API "best practice". Classes fall into two categories: ones designed for subclassing, and ones designed to be final. The same goes for methods. Swing is full of examples of what goes wrong when people override methods in classes that haven't been designed with subclassing in mind. Gili Brill Pappin wrote: > > on removing the finals > > The final members are the worst thing I've had to deal with in Wicket > so far. > Although I understand that there may be a reason for them, they are > more a hinderance than anything else and seem to be trying to "protect > users from themselves". > > - Brill Pappin > > > On 12-Jun-08, at 1:03 AM, cowwoc wrote: > >> >> >> Have you considered moving from subclassing to composition in Wicket >> using >> Callable? >> >> Currently it is quite common for developers to subclass a component >> in order >> to override isVisible() and other properties. I am proposing that >> instead >> the component classes become final and properties may only be set >> using >> setter methods. The setter methods would take Callable instead of >> T, so >> for example setVisible(boolean) would become >> setVisible(Callable) >> >> The benefit of this approach is that you could introduce static >> factory >> methods to the Wicket components which would make them much easier >> to use in >> their Generic form. You could then introduce various helper classes to >> create Callable for constant values, such as >> Callable.valueOf(true) would >> return a Callable that always returns true. >> -- >> View this message in context: >> >> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html >> 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/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html 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] >>> >>> >> >> >> >> -- >> Become a Wicket expert, learn from the best: http://wicketinaction.com >> Apache Wicket 1.3.3 is released >> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 >> >> - >> 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: Making Component easier to Generify
indeed. i wouldnt mind if final was the default in java :) -igor On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > Without the use of final wicket would not have made it this far. > > Martijn > > On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: >> I understand the reasoning, however I think "best practice" can be debated. >> To use your example Swing allows the user to override quite a bit, and it >> doesn't make any (or very few) assumptions on what should and should not be >> done. >> >> I don't like API's that assume I'm an idiot and prevent me from manipulating >> them how I see fit. If I cause a bug that I have to deal with, thats *my* >> problem to resolve. >> >> In my book (and I'm not the only one) excessive use of final is an >> anti-pattern. >> >> - Brill Pappin >> >> On 12-Jun-08, at 10:01 AM, cowwoc wrote: >> >>> >>> Brill, >>> >>> This is actually an API "best practice". Classes fall into two categories: >>> ones designed for subclassing, and ones designed to be final. The same >>> goes >>> for methods. Swing is full of examples of what goes wrong when people >>> override methods in classes that haven't been designed with subclassing in >>> mind. >>> >>> Gili >>> >>> >>> Brill Pappin wrote: on removing the finals The final members are the worst thing I've had to deal with in Wicket so far. Although I understand that there may be a reason for them, they are more a hinderance than anything else and seem to be trying to "protect users from themselves". - Brill Pappin On 12-Jun-08, at 1:03 AM, cowwoc wrote: > > > Have you considered moving from subclassing to composition in Wicket > using > Callable? > > Currently it is quite common for developers to subclass a component > in order > to override isVisible() and other properties. I am proposing that > instead > the component classes become final and properties may only be set > using > setter methods. The setter methods would take Callable instead of > T, so > for example setVisible(boolean) would become > setVisible(Callable) > > The benefit of this approach is that you could introduce static > factory > methods to the Wicket components which would make them much easier > to use in > their Generic form. You could then introduce various helper classes to > create Callable for constant values, such as > Callable.valueOf(true) would > return a Callable that always returns true. > -- > View this message in context: > > http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html > 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/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html >>> 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] >> >> > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > Apache Wicket 1.3.3 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 > > - > 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: How to get context path
jira is your friend -igor On Thu, Jun 12, 2008 at 4:46 AM, Hoover, William <[EMAIL PROTECTED]> wrote: > It would be better if ContextImage was a behavior rather than an actual > component. For instance, if you have an html input of type=image (or a > link for that matter) you can still utilize the behavior whereas a > component you cannot ;o) > > -Original Message- > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 11, 2008 3:29 PM > To: users@wicket.apache.org > Subject: Re: How to get context path > > see ContextImage > > -igor > > On Wed, Jun 11, 2008 at 12:10 PM, Patel, Sanjay <[EMAIL PROTECTED]> > wrote: >> Hi, >> >> my images in the application are in webapp/image folder. How to get >> Context Path in wicket so I can prepend this path to display the > image. >> I am looking for something like this. >> >> getContextPath() + "image/icon.gif"; >> >> Please suggest how to do that. >> >> Thanks, >> Sanjay. >> >> >> - >> 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: AjaxSubmitLink refreshing problem
Hello jchappelle. Yes, I'm adding the WebMarkupContainer to the AjaxRequestTarget, but I'm going to look that method you mentioned, maybe the solution is there. Thanks. jchappelle wrote: > > The ListView class has a method called removeLink that returns a Link that > will remove the item from the list. I have never used it but I just > figured I would point it out to you. Maybe looking at the source code of > that method could help. > > Also, make sure you are adding your WebMarkupContainer to the > AjaxRequestTarget. Otherwise the Ajax call will not update that section of > your markup. > > Josh > > > alesp wrote: >> >> Hello! >> Ok, this is the problem: I have the following wicket hierarchy: >> >> Panel >>| >> --> Form >> | >> --> WebMarkupContainer (setOutputMarkupId(true)) >> || >> |--> ListView (with a >> LoadableDetachableModel) >> | | >> | --> { populateItem { >> AjaxSubmitLink (to "delete" an element. Updates the WebMarkupContainer) } >> } >> --> AutoCompleteTextField >> | >> --> AjaxSubmitLink (to "add" an element) >> >> The problem is that the "add" link (the AjaxSubmitLink at the bottom of >> the diagram) is working fine, but the "delete" is not, and the code is >> pretty the same (calling different methods). When I say it's not working >> I mean that I click the "delete" link and nothing happens (internally the >> element is removed properly but the page doesn't refresh the changes). >> The "add" link works, I press "add" and the list is refreshed with the >> new element. >> Trying to find out what's happening I copied the "onSubmit" method of the >> "delete" AjaxSubmitLink to the "add" link and again the list was properly >> refreshed, now with a delete action. So, I think that the problem is >> related to the location of the links in the hierarchy and something that >> I'm missing there. >> Any idea? >> > > -- View this message in context: http://www.nabble.com/AjaxSubmitLink-refreshing-problem-tp17801832p17802573.html 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: Making Component easier to Generify
Without the use of final wicket would not have made it this far. Martijn On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: > I understand the reasoning, however I think "best practice" can be debated. > To use your example Swing allows the user to override quite a bit, and it > doesn't make any (or very few) assumptions on what should and should not be > done. > > I don't like API's that assume I'm an idiot and prevent me from manipulating > them how I see fit. If I cause a bug that I have to deal with, thats *my* > problem to resolve. > > In my book (and I'm not the only one) excessive use of final is an > anti-pattern. > > - Brill Pappin > > On 12-Jun-08, at 10:01 AM, cowwoc wrote: > >> >> Brill, >> >> This is actually an API "best practice". Classes fall into two categories: >> ones designed for subclassing, and ones designed to be final. The same >> goes >> for methods. Swing is full of examples of what goes wrong when people >> override methods in classes that haven't been designed with subclassing in >> mind. >> >> Gili >> >> >> Brill Pappin wrote: >>> >>> on removing the finals >>> >>> The final members are the worst thing I've had to deal with in Wicket >>> so far. >>> Although I understand that there may be a reason for them, they are >>> more a hinderance than anything else and seem to be trying to "protect >>> users from themselves". >>> >>> - Brill Pappin >>> >>> >>> On 12-Jun-08, at 1:03 AM, cowwoc wrote: >>> Have you considered moving from subclassing to composition in Wicket using Callable? Currently it is quite common for developers to subclass a component in order to override isVisible() and other properties. I am proposing that instead the component classes become final and properties may only be set using setter methods. The setter methods would take Callable instead of T, so for example setVisible(boolean) would become setVisible(Callable) The benefit of this approach is that you could introduce static factory methods to the Wicket components which would make them much easier to use in their Generic form. You could then introduce various helper classes to create Callable for constant values, such as Callable.valueOf(true) would return a Callable that always returns true. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html 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/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html >> 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] > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Component easier to Generify
On Thu, Jun 12, 2008 at 11:08 AM, Brill Pappin <[EMAIL PROTECTED]> wrote: > I understand the reasoning, however I think "best practice" can be debated. > To use your example Swing allows the user to override quite a bit, and it > doesn't make any (or very few) assumptions on what should and should not be > done. > > I don't like API's that assume I'm an idiot and prevent me from manipulating > them how I see fit. If I cause a bug that I have to deal with, thats *my* > problem to resolve. > > In my book (and I'm not the only one) excessive use of final is an > anti-pattern. While I agree that using final all over the place is in general a bad idea, there are other reasons to use the final modifier on a method. It can also help performance (although these particular cases might not be good examples of where you'd want to squeeze every last bit of performance out at the cost of disallowing extensibility). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AjaxSubmitLink refreshing problem
The ListView class has a method called removeLink that returns a Link that will remove the item from the list. I have never used it but I just figured I would point it out to you. Maybe looking at the source code of that method could help. Also, make sure you are adding your WebMarkupContainer to the AjaxRequestTarget. Otherwise the Ajax call will not update that section of your markup. Josh alesp wrote: > > Hello! > Ok, this is the problem: I have the following wicket hierarchy: > > Panel >| > --> Form > | > --> WebMarkupContainer (setOutputMarkupId(true)) > || > |--> ListView (with a > LoadableDetachableModel) > | | > | --> { populateItem { > AjaxSubmitLink (to "delete" an element. Updates the WebMarkupContainer) } > } > --> AutoCompleteTextField > | > --> AjaxSubmitLink (to "add" an element) > > The problem is that the "add" link (the AjaxSubmitLink at the bottom of > the diagram) is working fine, but the "delete" is not, and the code is > pretty the same (calling different methods). When I say it's not working I > mean that I click the "delete" link and nothing happens (internally the > element is removed properly but the page doesn't refresh the changes). The > "add" link works, I press "add" and the list is refreshed with the new > element. > Trying to find out what's happening I copied the "onSubmit" method of the > "delete" AjaxSubmitLink to the "add" link and again the list was properly > refreshed, now with a delete action. So, I think that the problem is > related to the location of the links in the hierarchy and something that > I'm missing there. > Any idea? > -- View this message in context: http://www.nabble.com/AjaxSubmitLink-refreshing-problem-tp17801832p17802380.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
wicket-datetime's DatePicker uses a static SimpleDateFormat
wicket-datetimes DatePicker.java uses a static instance of SimpleDateFormat, but SimpleDateFormat is not tread safe. Should this be fixed ? -- View this message in context: http://www.nabble.com/wicket-datetime%27s-DatePicker-uses-a-static-SimpleDateFormat-tp17802346p17802346.html 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: Making Component easier to Generify
I understand the reasoning, however I think "best practice" can be debated. To use your example Swing allows the user to override quite a bit, and it doesn't make any (or very few) assumptions on what should and should not be done. I don't like API's that assume I'm an idiot and prevent me from manipulating them how I see fit. If I cause a bug that I have to deal with, thats *my* problem to resolve. In my book (and I'm not the only one) excessive use of final is an anti-pattern. - Brill Pappin On 12-Jun-08, at 10:01 AM, cowwoc wrote: Brill, This is actually an API "best practice". Classes fall into two categories: ones designed for subclassing, and ones designed to be final. The same goes for methods. Swing is full of examples of what goes wrong when people override methods in classes that haven't been designed with subclassing in mind. Gili Brill Pappin wrote: on removing the finals The final members are the worst thing I've had to deal with in Wicket so far. Although I understand that there may be a reason for them, they are more a hinderance than anything else and seem to be trying to "protect users from themselves". - Brill Pappin On 12-Jun-08, at 1:03 AM, cowwoc wrote: Have you considered moving from subclassing to composition in Wicket using Callable? Currently it is quite common for developers to subclass a component in order to override isVisible() and other properties. I am proposing that instead the component classes become final and properties may only be set using setter methods. The setter methods would take Callable instead of T, so for example setVisible(boolean) would become setVisible(Callable) The benefit of this approach is that you could introduce static factory methods to the Wicket components which would make them much easier to use in their Generic form. You could then introduce various helper classes to create Callable for constant values, such as Callable.valueOf(true) would return a Callable that always returns true. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html 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/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html 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: Modify model value before rendering
or just write your own model in an inner class... -igor On Thu, Jun 12, 2008 at 1:45 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > Either use a converter or create an adapter model that takes the > propertymodel and retrieves the nested model object, and returns the > appropriate string. > > Martijn > > On Thu, Jun 12, 2008 at 10:22 AM, danielepiras > <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> I've an object with a boolean properties. I have mapped this object with a >> wicket's label using a PropertyModel. >> All work's fine but I read in the label true/false. Instead of this value, I >> want to see another message (for example "User enabled" and "User not >> enabled". How can I do that? >> >> Thank you very much for any help.. >> Daniele >> -- >> View this message in context: >> http://www.nabble.com/Modify-model-value-before-rendering-tp17794855p17794855.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > Apache Wicket 1.3.3 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 > > - > 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]
AjaxSubmitLink refreshing problem
Hello! Ok, this is the problem: I have the following wicket hierarchy: Panel | --> Form | --> WebMarkupContainer (setOutputMarkupId(true)) || |--> ListView (with a LoadableDetachableModel) | | | --> { populateItem { AjaxSubmitLink (to "delete" an element. Updates the WebMarkupContainer) } } --> AutoCompleteTextField | --> AjaxSubmitLink (to "add" an element) The problem is that the "add" link (the AjaxSubmitLink at the bottom of the diagram) is working fine, but the "delete" is not, and the code is pretty the same (calling different methods). When I say it's not working I mean that I click the "delete" link and nothing happens (internally the element is removed properly but the page doesn't refresh the changes). The "add" link works, I press "add" and the list is refreshed with the new element. Trying to find out what's happening I copied the "onSubmit" method of the "delete" AjaxSubmitLink to the "add" link and again the list was properly refreshed, now with a delete action. So, I think that the problem is related to the location of the links in the hierarchy and something that I'm missing there. Any idea? -- View this message in context: http://www.nabble.com/AjaxSubmitLink-refreshing-problem-tp17801832p17801832.html 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: Modifying QuickStart to serve static content in embedded Jetty (was: RE: Tomcat 5.5.9 isn't running Quickstart)
No, because the JSP servlet is needed to compile JSPs into servlet code. An unmodified configuration generated by the Wicket quickstart on our website serves static images perfectly well. You really are doing something funky. Martijn On Thu, Jun 12, 2008 at 4:07 PM, Frank Silbermann <[EMAIL PROTECTED]> wrote: > Yes, the QuickStart itself works. As for your ability to serve images, > it might depend whether these are images stored with the .html and .java > files for Wicket to pick up, versus images that are stored as static > objects. I googled the INFO - log warning " - NO JSP Support for /, did > not find org.apache.jasper.servlet.JspServlet" > > and found http://code.google.com/p/run-jetty-run/wiki/GettingStarted > about running Wicket projects with Jetty in Eclipse. It contains the > following comments: > > Comment by angelo.mariano, Jan 02, 2008 > When I try to launch it, I get the following error: 2008-01-02 > 10:11:55.191::INFO: Logging to STDERR > via org.mortbay.log.StdErrLog? 2008-01-02 10:11:55.300::INFO: > jetty-6.1.6 2008-01-02 > 10:11:55.441::INFO: NO JSP Support for /, did not find > org.apache.jasper.servlet.JspServlet? > 2008-01-02 10:11:55.659:/:INFO: default: init 2008-01-02 > 10:11:55.659:/:INFO: jsp: init 2008-01-02 > 10:11:55.691::INFO: Started [EMAIL PROTECTED]:8080 > > and then I am not able to compile jsp. Do you know how to solve this > problem? Thank you > > Comment by eelco.hillenius, Jan 02, 2008 > Ah, I probably have to include the appropriate libs to turn JSP > support on. Could you please file a > ticket? I'll get to it shortly. > > > > Eelco, could that discussion have anything to do with my problem? > > -Original Message- > From: Martijn Dashorst [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 12, 2008 1:23 AM > To: users@wicket.apache.org > Subject: Re: Tomcat 5.5.9 isn't running Quickstart > > The quickstart works for me without modifications. It serves images, > etc. out of the box, every time. > > Martijn > > On Thu, Jun 12, 2008 at 12:54 AM, Frank Silbermann > <[EMAIL PROTECTED]> wrote: >> Searching for some clue as to why my modification of the QuickStart >> application is serving images when run in Tomcat but not when running >> in embedded Jetty via Eclipse, I found: >> >> http://osdir.com/ml/java.jetty.support/2003-03/msg00045.html -- titled >> "Re: Re: jetty can't find images: msg#00045" >> >> It says, "You need the webdefaults file because it sets up the Default > >> servlet which is what serves static resources like images. You can >> also manually add the Default servlet if you want to avoid a >> webdefaults.xml file." >> >> I think this is a clue. Looking at the console log when running Jetty > >> in Eclipse I see: >> >> INFO - log- NO JSP Support for /, did not > find >> org.apache.jasper.servlet.JspServlet >> >> So what do I need to do to make it set up the Default servlet? Is >> there a line I need to insert into Start.java to make it read the >> webdefaults.xml file? I don't even have a webdefaults.xml file -- >> unless it's buried somewhere inside one of the Jetty jars. >> >> Here's the complete console log when debugging Start.java to bring up >> Jetty (as demonstrated in >> http://herebebeasties.com/2007-10-07/wicket-quickstart/). >> >> INFO - log- Logging to >> org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via >> org.mortbay.log.Slf4jLog > STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP >> INFO - log- jetty-6.1.4 >> INFO - log- NO JSP Support for /, did not > find >> org.apache.jasper.servlet.JspServlet >> INFO - log- No Transaction manager found - if >> your webapp requires one, please configure one. >> INFO - Application- [TestApplication] init: Wicket > core >> library initializer >> INFO - RequestListenerInterface - registered listener interface >> [RequestListenerInterface name=IBehaviorListener, method=public >> abstract void > org.apache.wicket.behavior.IBehaviorListener.onRequest()] >> INFO - RequestListenerInterface - registered listener interface >> [RequestListenerInterface name=IBehaviorListener, method=public >> abstract void > org.apache.wicket.behavior.IBehaviorListener.onRequest()] >> INFO - RequestListenerInterface - registered listener interface >> [RequestListenerInterface name=IFormSubmitListener, method=public >> abstract void >> org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted >> () >> ] >> INFO - RequestListenerInterface - registered listener interface >> [RequestListenerInterface name=IFormSubmitListener, method=public >> abstract void >> org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted >> () >> ] >> INFO - RequestListenerInterface - registered listener interface >> [RequestListenerInterface name=ILinkListener, method=public abstract >> void org.apache.wicket.markup.html.link.ILinkL
Problem with checkgroup and tree
Hello, i have a tree and its works perfect, but when I load a gridview with the respective data from a item, the checkgroup all doesn´t work! when I click on the page 2 the on the navigation, checkgroup all works... why? the page: public class KeyPagingPanel extends Panel { /** * */ private static final long serialVersionUID = 7966985858739652043L; private static Logger logger = Logger.getLogger(KeyPagingPanel.class); private KeyServico keyServico; List list = new ArrayList(); /** * constructor * @param KeyServico */ public KeyPagingPanel(String id) { super(id); this.KeyServico = ((BidManagerWebApplication)getApplication()).getKeyServico(); DataView dataView = new DataView("pageable", new KeysDataProvider(KeyServico)) { /** * */ private static final long serialVersionUID = -6643643064845215738L; protected void populateItem(final Item item) { Key k = (Key)item.getModelObject(); item.add(new Check("checked",item.getModel())); list.add(new PropertyModel(item.getModel(),"checked")); item.add(new Label("nome",k.getNome().getClasse().toString())); //other attributes item.add(new AttributeModifier("class", true, new AbstractReadOnlyModel() { private static final long serialVersionUID = -708237272351206L; public Object getObject() { return (item.getIndex() % 2 == 1) ? "even" : "odd"; } })); } }; Form form = new Form("KeyFormList"); add(form); dataView.setItemsPerPage(40); CheckGroup checkGroup = new CheckGroup("checkgroup", list); form.add(checkGroup); checkGroup.add(new CheckGroupSelector("checkall")); checkGroup.add(dataView); form.add(new PagingNavigator("navigator", dataView)); } } help... thanks. -- View this message in context: http://www.nabble.com/Problem-with-checkgroup-and-tree-tp17800883p17800883.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Modifying QuickStart to serve static content in embedded Jetty (was: RE: Tomcat 5.5.9 isn't running Quickstart)
Yes, the QuickStart itself works. As for your ability to serve images, it might depend whether these are images stored with the .html and .java files for Wicket to pick up, versus images that are stored as static objects. I googled the INFO - log warning " - NO JSP Support for /, did not find org.apache.jasper.servlet.JspServlet" and found http://code.google.com/p/run-jetty-run/wiki/GettingStarted about running Wicket projects with Jetty in Eclipse. It contains the following comments: Comment by angelo.mariano, Jan 02, 2008 When I try to launch it, I get the following error: 2008-01-02 10:11:55.191::INFO: Logging to STDERR via org.mortbay.log.StdErrLog? 2008-01-02 10:11:55.300::INFO: jetty-6.1.6 2008-01-02 10:11:55.441::INFO: NO JSP Support for /, did not find org.apache.jasper.servlet.JspServlet? 2008-01-02 10:11:55.659:/:INFO: default: init 2008-01-02 10:11:55.659:/:INFO: jsp: init 2008-01-02 10:11:55.691::INFO: Started [EMAIL PROTECTED]:8080 and then I am not able to compile jsp. Do you know how to solve this problem? Thank you Comment by eelco.hillenius, Jan 02, 2008 Ah, I probably have to include the appropriate libs to turn JSP support on. Could you please file a ticket? I'll get to it shortly. Eelco, could that discussion have anything to do with my problem? -Original Message- From: Martijn Dashorst [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 1:23 AM To: users@wicket.apache.org Subject: Re: Tomcat 5.5.9 isn't running Quickstart The quickstart works for me without modifications. It serves images, etc. out of the box, every time. Martijn On Thu, Jun 12, 2008 at 12:54 AM, Frank Silbermann <[EMAIL PROTECTED]> wrote: > Searching for some clue as to why my modification of the QuickStart > application is serving images when run in Tomcat but not when running > in embedded Jetty via Eclipse, I found: > > http://osdir.com/ml/java.jetty.support/2003-03/msg00045.html -- titled > "Re: Re: jetty can't find images: msg#00045" > > It says, "You need the webdefaults file because it sets up the Default > servlet which is what serves static resources like images. You can > also manually add the Default servlet if you want to avoid a > webdefaults.xml file." > > I think this is a clue. Looking at the console log when running Jetty > in Eclipse I see: > > INFO - log- NO JSP Support for /, did not find > org.apache.jasper.servlet.JspServlet > > So what do I need to do to make it set up the Default servlet? Is > there a line I need to insert into Start.java to make it read the > webdefaults.xml file? I don't even have a webdefaults.xml file -- > unless it's buried somewhere inside one of the Jetty jars. > > Here's the complete console log when debugging Start.java to bring up > Jetty (as demonstrated in > http://herebebeasties.com/2007-10-07/wicket-quickstart/). > > INFO - log- Logging to > org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via > org.mortbay.log.Slf4jLog STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP > INFO - log- jetty-6.1.4 > INFO - log- NO JSP Support for /, did not find > org.apache.jasper.servlet.JspServlet > INFO - log- No Transaction manager found - if > your webapp requires one, please configure one. > INFO - Application- [TestApplication] init: Wicket core > library initializer > INFO - RequestListenerInterface - registered listener interface > [RequestListenerInterface name=IBehaviorListener, method=public > abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] > INFO - RequestListenerInterface - registered listener interface > [RequestListenerInterface name=IBehaviorListener, method=public > abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] > INFO - RequestListenerInterface - registered listener interface > [RequestListenerInterface name=IFormSubmitListener, method=public > abstract void > org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted > () > ] > INFO - RequestListenerInterface - registered listener interface > [RequestListenerInterface name=IFormSubmitListener, method=public > abstract void > org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted > () > ] > INFO - RequestListenerInterface - registered listener interface > [RequestListenerInterface name=ILinkListener, method=public abstract > void org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()] > INFO - RequestListenerInterface - registered listener interface > [RequestListenerInterface name=ILinkListener, method=public abstract > void org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()] > INFO - RequestListenerInterface - registered listener interface > [RequestListenerInterface name=IOnChangeListener, method=public > abstract void > org.apache.wicket.markup.html.fo
Re: Making Component easier to Generify
Brill, This is actually an API "best practice". Classes fall into two categories: ones designed for subclassing, and ones designed to be final. The same goes for methods. Swing is full of examples of what goes wrong when people override methods in classes that haven't been designed with subclassing in mind. Gili Brill Pappin wrote: > > on removing the finals > > The final members are the worst thing I've had to deal with in Wicket > so far. > Although I understand that there may be a reason for them, they are > more a hinderance than anything else and seem to be trying to "protect > users from themselves". > > - Brill Pappin > > > On 12-Jun-08, at 1:03 AM, cowwoc wrote: > >> >> >> Have you considered moving from subclassing to composition in Wicket >> using >> Callable? >> >> Currently it is quite common for developers to subclass a component >> in order >> to override isVisible() and other properties. I am proposing that >> instead >> the component classes become final and properties may only be set >> using >> setter methods. The setter methods would take Callable instead of >> T, so >> for example setVisible(boolean) would become >> setVisible(Callable) >> >> The benefit of this approach is that you could introduce static >> factory >> methods to the Wicket components which would make them much easier >> to use in >> their Generic form. You could then introduce various helper classes to >> create Callable for constant values, such as >> Callable.valueOf(true) would >> return a Callable that always returns true. >> -- >> View this message in context: >> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html >> 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/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html 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: Localizer cache with 150.000+ entries causing OutOfMemory
I think that should be already fixed in SVN. We didn't remove the entries on session expiration. -Matej On Thu, Jun 12, 2008 at 2:26 PM, Juha Alatalo <[EMAIL PROTECTED]> wrote: > We are now using patched version of 1.3.X in a production environment and > usage of memory seems to be much more stable. > > Is there still some bug in PageWindowManager? Seems that size of > idToWindowIndices increases every time WebPage is opened in a browser. > > I run jmeter test during last night. It was simulating 50 users which opens > a page once in a 0 - 60 seconds. Jprofiler was showing as many > IntHashMap$Entry instances as there were samples in jmeter. > > - Juha > > > > Igor Vaynberg wrote: >> >> if someone can confirm that the patch works in a production env i will >> be happy to commit it. i just havent had the time to test it myself >> yet. >> >> -igor >> >> On Tue, Jun 10, 2008 at 7:09 AM, Juha Alatalo >> <[EMAIL PROTECTED]> wrote: >>> >>> Hi All, >>> >>> I run our profiling tests (version 1.3.3) using Application.java and >>> Localizer.java patched by Stefan. Patch seems to be solving our memory >>> problems. >>> >>> Is this patch coming to 1.3.4 and do you have any idea when 1.3.4 will be >>> released? >>> >>> Best Regards >>> - Juha >>> >>> >>> Stefan Fußenegger wrote: Hi Daniel, I didn't put the patch into production yet, but I am quite confident, that it will help. As you can see in the example I attached to the JIRA issue (just attached a new version), the unpatched Localizer had 200 entries in his cache, the patched Localizer only four - which is a Good Thing (tm), as there are only 4 different cached values! Regards, Stefan Daniel Frisk wrote: > > So the patch did help? > > I too have observed this problem but it was at the moment less of a > problem than other heap eaters, now this is next in line. We have > added a > script which automatically restarts the server when repeated OOME > occurs > and are down to a couple of times per week without the patch. But > still, > who wouldn't want to see months of uptime... > > // Daniel > jalbum.net > > > On 2008-06-10, at 11:29, Stefan Fußenegger wrote: > >> Hi Igor, >> >> Thanks for your quick reply and the patch, sorry for not searching the >> mailinglist only but not JIRA. >> >> Your patch was for 1.4, I applied it to 1.3.3, created a quickstart >> including JUnit test and attached it to the JIRA issue. Hope this fix >> gets >> into the next maintenance release. I am to lazy to create a properly >> patched >> jar and a MVN repo for my team right now ;) >> >> Regards, Stefan >> >> >> >> igor.vaynberg wrote: >>> >>> try applying this patch and see if it helps >>> >>> https://issues.apache.org/jira/browse/WICKET-1667 >>> >>> -igor >>> >>> On Mon, Jun 9, 2008 at 8:11 AM, Stefan Fußenegger >>> <[EMAIL PROTECTED]> wrote: I am just analysing a heap dump (god bless the -XX:+HeapDumpOnOutOfMemoryError flag) of a recent application cache due to an OutOfMemoryError ("GC overhead limit exceeded" to be precise). Using jhat, the "175456 instances of class org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry" immediately got my attention. While looking through the 107 instance of ConcurrentHashMap, I found one *really* big one: Localizer.cache has a hash table length of 262144, each of its 32 segments with about 5300 entries, where a hash key is a string, sometimes longer than 500 charactes, similar to (see Localizer.getCacheKey(String,Component)): fooTitle.bar- org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink- org.apache.wicket.markup.html.panel.Fragment:track- org.apache.wicket.markup.html.list.ListItem:14- my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos- org.apache.wicket.markup.html.list.ListItem:0- my.company.BarListPanel$1:bars-my.company.FooListPanel:panel- my.company.boxes.BodyBox:2- org.apache.wicket.markup.repeater.RepeatingView:body- my.company.layout.Border:border-my.company.pages.music.FoobarPage: 43-de-null Those numbers pretty much convinced me: The localizer cache has blown away my application. Looking at this hash keys, I suspect the following problem: those strings are constructed from the "position" of a localized String on a page, which is quite a bad thing if you use nested list views or repeating views to construct your page. For i
Re: Replace a fragment with AjaxLink
OK I figured out what the problem is. If you want to replace one fragment with another over AJAX, then they must have the same "markupId"s. Otherwise it won't work. I solved the problem by making "orig" fragment "final". And after repl.setOutputMarkupId(true); I added repl.setMarkupId(orig.getMarkupId()); and then it works. May be something for the WIKI. Thomas Mäder wrote: > > What's the stack trace? > > On Thu, Jun 12, 2008 at 3:01 PM, vkbhaskar <[EMAIL PROTECTED]> wrote: > >> >> How do I replace a fragment with an AjaxLink ? >> >> I am trying something like this. >> >> Fragment orig = new Fragment("container","original",this); >> orig.setOutputMarkupId(true); >> add(orig); >> add(new AjaxLink("link") { >>public void onClick(AjaxTarget target) { >> Fragment repl = new Fragment("container","replace",MyPage.this); >> repl.setOutputMarkupId(true); >> MyPage.this.replace(repl); >> target.add(repl); >>} >> } >> ); >> >> But I am getting ArrayIndexOutofBoundsExceptions, when the link is >> clicked. >> -- >> View this message in context: >> http://www.nabble.com/Replace-a-fragment-with-AjaxLink-tp17799454p17799454.html >> 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/Replace-a-fragment-with-AjaxLink-tp17799454p17800094.html 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: Making Component easier to Generify
on removing the finals The final members are the worst thing I've had to deal with in Wicket so far. Although I understand that there may be a reason for them, they are more a hinderance than anything else and seem to be trying to "protect users from themselves". - Brill Pappin On 12-Jun-08, at 1:03 AM, cowwoc wrote: Have you considered moving from subclassing to composition in Wicket using Callable? Currently it is quite common for developers to subclass a component in order to override isVisible() and other properties. I am proposing that instead the component classes become final and properties may only be set using setter methods. The setter methods would take Callable instead of T, so for example setVisible(boolean) would become setVisible(Callable) The benefit of this approach is that you could introduce static factory methods to the Wicket components which would make them much easier to use in their Generic form. You could then introduce various helper classes to create Callable for constant values, such as Callable.valueOf(true) would return a Callable that always returns true. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html 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: Making Component easier to Generify
You could reduce the verbosity by combining all your dynamic content (anything you would normally add when subclassing a component) into a separate class. For example: class Images { Callable isVisible() { ... } Callable getItemsPerPage() { ... } } main() { DataView images = DataView.create(); // factory method Images imageState = new Images(); images.setItemsPerPage(imageState.getItemsPerPage()); images.setVisible(imageState.isVisible()); ... } Gili Matej Knopp-2 wrote: > > Apart from the fact that this would be even more verbose than current > generics approach this would probably also radically increase > component memory footprint. > > -Matej > > On Thu, Jun 12, 2008 at 7:03 AM, cowwoc <[EMAIL PROTECTED]> wrote: >> >> >> Have you considered moving from subclassing to composition in Wicket >> using >> Callable? >> >> Currently it is quite common for developers to subclass a component in >> order >> to override isVisible() and other properties. I am proposing that instead >> the component classes become final and properties may only be set using >> setter methods. The setter methods would take Callable instead of T, >> so >> for example setVisible(boolean) would become >> setVisible(Callable) >> >> The benefit of this approach is that you could introduce static factory >> methods to the Wicket components which would make them much easier to use >> in >> their Generic form. You could then introduce various helper classes to >> create Callable for constant values, such as Callable.valueOf(true) >> would >> return a Callable that always returns true. >> -- >> View this message in context: >> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html >> 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/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800015.html 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: Replace a fragment with AjaxLink
What's the stack trace? On Thu, Jun 12, 2008 at 3:01 PM, vkbhaskar <[EMAIL PROTECTED]> wrote: > > How do I replace a fragment with an AjaxLink ? > > I am trying something like this. > > Fragment orig = new Fragment("container","original",this); > orig.setOutputMarkupId(true); > add(orig); > add(new AjaxLink("link") { >public void onClick(AjaxTarget target) { > Fragment repl = new Fragment("container","replace",MyPage.this); > repl.setOutputMarkupId(true); > MyPage.this.replace(repl); > target.add(repl); >} > } > ); > > But I am getting ArrayIndexOutofBoundsExceptions, when the link is clicked. > -- > View this message in context: > http://www.nabble.com/Replace-a-fragment-with-AjaxLink-tp17799454p17799454.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Replace a fragment with AjaxLink
How do I replace a fragment with an AjaxLink ? I am trying something like this. Fragment orig = new Fragment("container","original",this); orig.setOutputMarkupId(true); add(orig); add(new AjaxLink("link") { public void onClick(AjaxTarget target) { Fragment repl = new Fragment("container","replace",MyPage.this); repl.setOutputMarkupId(true); MyPage.this.replace(repl); target.add(repl); } } ); But I am getting ArrayIndexOutofBoundsExceptions, when the link is clicked. -- View this message in context: http://www.nabble.com/Replace-a-fragment-with-AjaxLink-tp17799454p17799454.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wicket Datepicker javascript not loaded in portlet environment
Hi all, I'm trying to use an org.apache.wicket.datetime.markup.html.form.DateTextField component which contains a org.apache.wicket.extensions.yui.calendar.DatePicker in my portlet application. The field is contained in a panel with the markup like: and the panel is contained in a listview, which is also contained within a form. When I access the application directly, the date picker works fine. But when I access it as a portlet, the date picker is displayed correctly but it does not show the calendar when I click the icon. When I check with the javascript debugger, I see that wicket-event.js and yuiloader-beta.js files are loaded, but calendar.js and wicket-date.js are not loaded. I've included a related excerpt from the generated html page below. As far as I understand, these javascript files are dynamically included by YUI loader. But in a portlet environment they are not loaded, and I cannot use the venkman javascript debugger since this happens during page load. I'm using Wicket 1.3.3 and Firefox 2.0. Does anybody have any idea why these js files are not loaded? It would be great if anybody would tell me what could be wrong and give me some pointers on debugging this javascript code. Best regards, SerkanC ]]>*/ in the - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Localizer cache with 150.000+ entries causing OutOfMemory
We are now using patched version of 1.3.X in a production environment and usage of memory seems to be much more stable. Is there still some bug in PageWindowManager? Seems that size of idToWindowIndices increases every time WebPage is opened in a browser. I run jmeter test during last night. It was simulating 50 users which opens a page once in a 0 - 60 seconds. Jprofiler was showing as many IntHashMap$Entry instances as there were samples in jmeter. - Juha Igor Vaynberg wrote: if someone can confirm that the patch works in a production env i will be happy to commit it. i just havent had the time to test it myself yet. -igor On Tue, Jun 10, 2008 at 7:09 AM, Juha Alatalo <[EMAIL PROTECTED]> wrote: Hi All, I run our profiling tests (version 1.3.3) using Application.java and Localizer.java patched by Stefan. Patch seems to be solving our memory problems. Is this patch coming to 1.3.4 and do you have any idea when 1.3.4 will be released? Best Regards - Juha Stefan Fußenegger wrote: Hi Daniel, I didn't put the patch into production yet, but I am quite confident, that it will help. As you can see in the example I attached to the JIRA issue (just attached a new version), the unpatched Localizer had 200 entries in his cache, the patched Localizer only four - which is a Good Thing (tm), as there are only 4 different cached values! Regards, Stefan Daniel Frisk wrote: So the patch did help? I too have observed this problem but it was at the moment less of a problem than other heap eaters, now this is next in line. We have added a script which automatically restarts the server when repeated OOME occurs and are down to a couple of times per week without the patch. But still, who wouldn't want to see months of uptime... // Daniel jalbum.net On 2008-06-10, at 11:29, Stefan Fußenegger wrote: Hi Igor, Thanks for your quick reply and the patch, sorry for not searching the mailinglist only but not JIRA. Your patch was for 1.4, I applied it to 1.3.3, created a quickstart including JUnit test and attached it to the JIRA issue. Hope this fix gets into the next maintenance release. I am to lazy to create a properly patched jar and a MVN repo for my team right now ;) Regards, Stefan igor.vaynberg wrote: try applying this patch and see if it helps https://issues.apache.org/jira/browse/WICKET-1667 -igor On Mon, Jun 9, 2008 at 8:11 AM, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: I am just analysing a heap dump (god bless the -XX:+HeapDumpOnOutOfMemoryError flag) of a recent application cache due to an OutOfMemoryError ("GC overhead limit exceeded" to be precise). Using jhat, the "175456 instances of class org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry" immediately got my attention. While looking through the 107 instance of ConcurrentHashMap, I found one *really* big one: Localizer.cache has a hash table length of 262144, each of its 32 segments with about 5300 entries, where a hash key is a string, sometimes longer than 500 charactes, similar to (see Localizer.getCacheKey(String,Component)): fooTitle.bar- org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink- org.apache.wicket.markup.html.panel.Fragment:track- org.apache.wicket.markup.html.list.ListItem:14- my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos- org.apache.wicket.markup.html.list.ListItem:0- my.company.BarListPanel$1:bars-my.company.FooListPanel:panel- my.company.boxes.BodyBox:2- org.apache.wicket.markup.repeater.RepeatingView:body- my.company.layout.Border:border-my.company.pages.music.FoobarPage: 43-de-null Those numbers pretty much convinced me: The localizer cache has blown away my application. Looking at this hash keys, I suspect the following problem: those strings are constructed from the "position" of a localized String on a page, which is quite a bad thing if you use nested list views or repeating views to construct your page. For instance, I have a panel with a long (pageable) list of entries, might be > 5000 entries which might appear on various positions in a repeating view I use as a container for most of my pages. Let's say there are 5 possible positions, this would cause 2500 thousand cached entries, each with a key of 300+ characters plus some more characters for the cached message - feel free to do the maths. From a quick estimate I'd say: No wonder, this has blown away my app. As a quick fix, I'd suggest to regularly clear the localizer cache, use a more sophisticated cache (that expires old entries once in a while!!) or to disable the cache completely. However, don't try to overwrite Localizer.newCache() and clear the cache regularly: clearCache() will replace your cache with a ConcurrentHashMap (not using Localizer.newCache()). However, quite unlikely, that this will happen as newCache() is private anyway ;) I am going to add some code to clear the cache regularly. Best regards, Stefan PS: I'll also create a JIRA issue, but I am really short o
RE: How to get context path
It would be better if ContextImage was a behavior rather than an actual component. For instance, if you have an html input of type=image (or a link for that matter) you can still utilize the behavior whereas a component you cannot ;o) -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 3:29 PM To: users@wicket.apache.org Subject: Re: How to get context path see ContextImage -igor On Wed, Jun 11, 2008 at 12:10 PM, Patel, Sanjay <[EMAIL PROTECTED]> wrote: > Hi, > > my images in the application are in webapp/image folder. How to get > Context Path in wicket so I can prepend this path to display the image. > I am looking for something like this. > > getContextPath() + "image/icon.gif"; > > Please suggest how to do that. > > Thanks, > Sanjay. > > > - > 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: Refresh ModalWindow - Impossible??
Yeah, I also only updated the contents of the modal window.. Thats the idea with ajax only to update as little as possible... Milan K?ápek wrote: Well I have it. Thank you very very much. I give up the thing that I will refresh whole ModalWindow. I do not know why but I am not able to do. But I found another way how to do it. I do not update the whole modal window but only its content. I think this was the main problem. Best regards Milan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Refresh ModalWindow - Impossible??
Well I have it. Thank you very very much. I give up the thing that I will refresh whole ModalWindow. I do not know why but I am not able to do. But I found another way how to do it. I do not update the whole modal window but only its content. I think this was the main problem. Best regards Milan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Refresh ModalWindow - Impossible??
http://www.nabble.com/Modal-Window-not-opening-the-second-time-td16850180.html#a16955689 And you are not bothering me. If I were bothered I'd just not answered::) Milan K?ápek wrote: Thanks for that. It is great that ModalWindow is updateable. I am sorry for bothering you. I try to find any note how to do it on wicket forums and try to google it, but I was not able to find anything. Plase you said that you write something about it. Can you give me link? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: beginner question about models when having more than one component of the same type on the same page
Just to come back to your original question (as I was intrigued & dug into it), the reason why Wicket didn't find the properties as expected is that the ResourceModel is relative to the component, so it was looking for properties such as: vacancyForm.hrContactPanel.nameLabel.nameLabel=HR Contact: While that would have worked, a better solution would be to replace the ResourceModel call by a "new StringResourceModel("nameLabel", this, null)", where the 'this' would then be the parent ContactPanel. Having said that, in my opinion the even better solution is the one you did find... /Gwyn On Thu, Jun 12, 2008 at 6:53 AM, Peter Eriksson <[EMAIL PROTECTED]> wrote: > Thanks Timo for your very helpful suggestion! > > Best Regards, > /Peter > > 2008/6/11 Timo Rantalaiho <[EMAIL PROTECTED]>: > > > On Wed, 11 Jun 2008, Peter Eriksson wrote: > > > I will answer my own post, just in case somebody else is looking for a > > > solution to the same problem. I have found two ways to get the resource > > > loading to do exactly what I want (There are probably a lot more out > > there): > > > > Thanks for posting that, and cool that you found it out! > > > > > add(new Label("nameLabel", new StringResourceModel("nameLabel", > > > this, null))); > > > add(new Label("name")); > > > > These Label pairs smell like a custom component to me, e.g. > > > > public class LabeledText extends WebMarkupContainer { > > public LabeledText(String textId, MarkupContainer parent) { > > super(textId + "Container"); > > String labelId = textId + "Label"; > > add(new Label(labelId, new StringResourceModel(labelId, parent, > > null))); > > add(new Label(textId); > > } > > } > > > > Then in ContactPanel constructor you do > > > >add(new LabeledText("userName", this)); > >add(new LabeledText("phone", this)); > >add(new LabeledText("email", this)); > > > > and change the markup accordingly (to something like > > > > > > > > > > > > > > ... > > ) > > > > Best wishes, > > Timo > > > > -- > > Timo Rantalaiho > > Reaktor Innovations Oyhttp://www.ri.fi/ > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
Re: Refresh ModalWindow - Impossible??
Thanks for that. It is great that ModalWindow is updateable. I am sorry for bothering you. I try to find any note how to do it on wicket forums and try to google it, but I was not able to find anything. Plase you said that you write something about it. Can you give me link? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ajax Only application - ffeedback appriciated
One thing I find interesting in Wicket is that it makes it easy again to think about an application as a series of "places" where the user can be (+/- versioning). The back/forward buttons navigate between places. Actions manipulate what you see, you don't necessarily go anywhere else. Thomas On Sat, Jun 7, 2008 at 5:03 AM, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > Ive been developing an ajax only application in wicket for a little more > > than 3 months. Users can open "windows" in a multidocument desktop-style > > fashion for various entities and in these "windows/tabs" perform > different > > actions and apply different views. Further they can change views forth > and > > back, close views, rearrange views. I almost NEVER do a page level > GET/POST. > > The fun part is that its working really well. But Ive never seen > something > > like this out on the web really (gmail/gcalendar ok.. but those are quite > > simple apps + they prolly got a big staff to tune every possible metric). > > > > Has anyone done something similar? > > Sure. We (Teachscape) are doing something like that. Not all Ajax > (though we use that regularly as well), but we pretty much do > everything in one page and implement navigation through panel swapping > etc. > > When using Wicket like this, it is best to use the > SecondLevelCacheSessionStore (the default in Wicket 1.3). Wicket 1.2 > and the HttpSessionStore keep recording deltas - which are smaller > than serialized pages, but have enough versions and it adds up - as > long as you stay on one page. At least, that's how it used to be (and > one of the big refactorings of 1.3). > > Eelco > > > > Is this a dangerous track? What is most likely to stop me? How can I > monitor > > the amout o memory a user session consumes? If I find the > > average-request-cpu-cycles * > > average_requests_per_user_during_some_duration.. is it straight forward > to > > see how many simultaneous users I can accomodate? > > > > /Kalle > > -- > > View this message in context: > http://www.nabble.com/Ajax-Only-application---ffeedback-appriciated-tp17694786p17694786.html > > 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: Modify model value before rendering
something like this might work (untested) PropertyModel pm = new PropertyModel(this,""){ @Override public Object getObject() { return (Boolean) super.getObject() ? "User enabled" : "User not enabled"; } }; danielepiras wrote: > > Hi, > > I've an object with a boolean properties. I have mapped this object with a > wicket's label using a PropertyModel. > All work's fine but I read in the label true/false. Instead of this value, > I want to see another message (for example "User enabled" and "User not > enabled". How can I do that? > > Thank you very much for any help.. > Daniele > -- View this message in context: http://www.nabble.com/Modify-model-value-before-rendering-tp17794855p17795114.html 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: Modify model value before rendering
Either use a converter or create an adapter model that takes the propertymodel and retrieves the nested model object, and returns the appropriate string. Martijn On Thu, Jun 12, 2008 at 10:22 AM, danielepiras <[EMAIL PROTECTED]> wrote: > > Hi, > > I've an object with a boolean properties. I have mapped this object with a > wicket's label using a PropertyModel. > All work's fine but I read in the label true/false. Instead of this value, I > want to see another message (for example "User enabled" and "User not > enabled". How can I do that? > > Thank you very much for any help.. > Daniele > -- > View this message in context: > http://www.nabble.com/Modify-model-value-before-rendering-tp17794855p17794855.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Component easier to Generify
Apart from the fact that this would be even more verbose than current generics approach this would probably also radically increase component memory footprint. -Matej On Thu, Jun 12, 2008 at 7:03 AM, cowwoc <[EMAIL PROTECTED]> wrote: > > > Have you considered moving from subclassing to composition in Wicket using > Callable? > > Currently it is quite common for developers to subclass a component in order > to override isVisible() and other properties. I am proposing that instead > the component classes become final and properties may only be set using > setter methods. The setter methods would take Callable instead of T, so > for example setVisible(boolean) would become setVisible(Callable) > > The benefit of this approach is that you could introduce static factory > methods to the Wicket components which would make them much easier to use in > their Generic form. You could then introduce various helper classes to > create Callable for constant values, such as Callable.valueOf(true) would > return a Callable that always returns true. > -- > View this message in context: > http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html > 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]
Modify model value before rendering
Hi, I've an object with a boolean properties. I have mapped this object with a wicket's label using a PropertyModel. All work's fine but I read in the label true/false. Instead of this value, I want to see another message (for example "User enabled" and "User not enabled". How can I do that? Thank you very much for any help.. Daniele -- View this message in context: http://www.nabble.com/Modify-model-value-before-rendering-tp17794855p17794855.html 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: Refresh ModalWindow - Impossible??
Hi Milan That assumption are not correct. Modal window are fully updateable however you want it to be. Under certain circumstances you do have to set it up correctly (allowing for the modal window to be refreshed in ajax operations). I dont have sniplet ready, but you can search the list for modalwindow , and I have pasted something about this earlier... Milan K?ápek wrote: Hi, I think this is not my problem. I forgot mention it, but I pass to Panel that I show in modal window just one parameter. And it it the parent operation. When I render the modal window I allways read all operations form database. So I thing my model is allways up-to-date. I thing problem is that the ModalWindow can change values of its obejets, but cannot remove or add these objects. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]