[jira] Issue Comment Edited: (WICKET-1975) Allow custom form components to be more easily created by removing final from certain methods.
[ https://issues.apache.org/jira/browse/WICKET-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12660752#action_12660752 ] laz edited comment on WICKET-1975 at 1/5/09 5:48 AM: 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. This is workable but prevents this object from transparently being treated like a FormComponent. 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. was (Author: laz): 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.
[jira] Issue Comment Edited: (WICKET-1975) Allow custom form components to be more easily created by removing final from certain methods.
[ https://issues.apache.org/jira/browse/WICKET-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12660752#action_12660752 ] laz edited comment on WICKET-1975 at 1/5/09 5:47 AM: 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. was (Author: laz): 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.
[jira] Commented: (WICKET-1975) Allow custom form components to be more easily created by removing final from certain methods.
[ https://issues.apache.org/jira/browse/WICKET-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.
[jira] Created: (WICKET-1975) Allow custom form components to be more easily created by removing final from certain methods.
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.
