[
https://issues.apache.org/jira/browse/WICKET-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660752#action_12660752
]
Larry Zappaterrini commented on WICKET-1975:
--------------------------------------------
I have created a component that encapsulates a label/input pair in a form by
subclassing FormComponentPanel. It would be nice if calls to
add(IValidator) and setType(Class<?>) on instances of that object could be
delegated to its input member. My current workaround is to have two additional
methods addField(IValidator) and setFieldType(Class<?>) to accomplish this.
I also just realized that I referred to FormComponent#setFieldType(Class<?>) in
my original description when it should have been
FormComponent#setType(Class<?>). Sorry about that.
> Allow custom form components to be more easily created by removing final from
> certain methods.
> ----------------------------------------------------------------------------------------------
>
> Key: WICKET-1975
> URL: https://issues.apache.org/jira/browse/WICKET-1975
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Reporter: Larry Zappaterrini
> Priority: Minor
>
> I was perusing Wicket's Javadocs and I came across a link to an old thread:
> http://www.nabble.com/Why-add%28IBehavior%29-is-final--td7248198.html#a7248198
> The issue in that message thread was resolved by WICKET-94 with the final
> modifier being removed from from Component#add(IBehavior). I am currently
> trying to do something similar to the original author of the thread and I
> believe the same concession should be extended to
> FormComponent#add(IValidator) and FormComponent#setFieldType(Class<?>) due to
> similar arguments. In fact, might it make sense to look though the public
> final methods of FormComponent and only make final those that are absolutely
> necessary from an encapsulation standpoint?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
