date:20080612

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?

2008-06-12 Thread Rod Good

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?

2008-06-12 Thread Rod Good

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

2008-06-12 Thread Matthijs Wensveen


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

2008-06-12 Thread Matthijs Wensveen

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]

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

2008-06-12 Thread igor . vaynberg

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

2008-06-12 Thread Jon Laidler




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?

2008-06-12 Thread Timo Rantalaiho

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

2008-06-12 Thread Frank Bille

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

2008-06-12 Thread greeklinux


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?

2008-06-12 Thread David Nedrow

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

2008-06-12 Thread Frank Bille

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?

2008-06-12 Thread Marcus Mattila

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

2008-06-12 Thread Matthew Hanlon

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

2008-06-12 Thread Matthew Hanlon

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

2008-06-12 Thread Matthijs Wensveen

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]

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

2008-06-12 Thread Zappaterrini, Larry

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

2008-06-12 Thread Timo Rantalaiho

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

2008-06-12 Thread galbelli


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

2008-06-12 Thread Hoover, William

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)

2008-06-12 Thread Gwyn Evans

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

2008-06-12 Thread Mathias P.W Nilsson


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

2008-06-12 Thread Eelco Hillenius

> 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

2008-06-12 Thread galbelli


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

2008-06-12 Thread Eelco Hillenius

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

2008-06-12 Thread Frank Silbermann

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

2008-06-12 Thread Michael_Bo


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

2008-06-12 Thread cowwoc

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

2008-06-12 Thread Zappaterrini, Larry

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

2008-06-12 Thread alesp


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

2008-06-12 Thread Martijn Dashorst

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

2008-06-12 Thread jchappelle


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

2008-06-12 Thread vkbhaskar


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)

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

2008-06-12 Thread alesp


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)

2008-06-12 Thread Martijn Dashorst

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

2008-06-12 Thread DLLongo


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)

2008-06-12 Thread Frank Silbermann

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

2008-06-12 Thread cowwoc


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

2008-06-12 Thread Matej Knopp

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

2008-06-12 Thread vkbhaskar


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