You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Charles A Deal <cd...@csc.com> on 2009/04/15 18:05:45 UTC
isRequired: Use function instead of boolean
I have a number of Form Components that have a conditional required
status. In the past, I've seen recommendations to override the component
and supply a custom implementation of the isRequired function to support
the proper check. So, in this case, it ignores the boolean that might be
set by the user. I understand and agree that that is a reasonable
solution.
In my environment, I have helper functions that, given some parameters,
build the appropriate components along with labels, validators, behaviors,
etc. In order to subclass the Form Components, I would have to give up
that function and, basically, code capture what it does for each instance
that needs a custom isRequired method. I also have a security
implementation that uses a Predicate instance (org.apache.commons.
collections) to control both the RENDER and ENABLED state of a component
and it seems natural (in my environment) to be able to use a Predicate for
the isRequired function, as well.
I am soliciting feedback on the idea. I don't want to have a completely
derivative set of FormComponents that support this feature, so I would
probably modify the main codebase to add the support to all
FormComponents. My thought is that I would add a
setRequiredFunction(Predicate) method that would store the predicate in
MetaData. The isRequired() method would be adjusted to be something like
public boolean isRequired() {
Predicate func = <get Predicate from MetaData>
if (func != null) {
return func.evaluate(this);
} else {
return getFlag(FLAG_REQUIRED);
}
}
Can anyone tell me why this WOULDN'T work? What might some shortcomings
be? Would Wicket core be interested in this? If not, why not (it might
offer insight as to why this is a bad idea)? Would this add too much
overhead to be worthwhile?
If you think this is a good idea, why? And would you do anything
differently to make this a stronger concept?
Thanks for your feedback, I appreciate your time.
Charles Deal
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.
Re: isRequired: Use function instead of boolean
Posted by James Carman <jc...@carmanconsulting.com>.
It can be.
On Wed, Apr 15, 2009 at 2:13 PM, Johan Compagner <jc...@gmail.com> wrote:
> is a Predicate serializable?
>
> On Wed, Apr 15, 2009 at 18:05, Charles A Deal <cd...@csc.com> wrote:
>
>> I have a number of Form Components that have a conditional required
>> status. In the past, I've seen recommendations to override the component
>> and supply a custom implementation of the isRequired function to support
>> the proper check. So, in this case, it ignores the boolean that might be
>> set by the user. I understand and agree that that is a reasonable
>> solution.
>>
>> In my environment, I have helper functions that, given some parameters,
>> build the appropriate components along with labels, validators, behaviors,
>> etc. In order to subclass the Form Components, I would have to give up
>> that function and, basically, code capture what it does for each instance
>> that needs a custom isRequired method. I also have a security
>> implementation that uses a Predicate instance (org.apache.commons.
>> collections) to control both the RENDER and ENABLED state of a component
>> and it seems natural (in my environment) to be able to use a Predicate for
>> the isRequired function, as well.
>>
>> I am soliciting feedback on the idea. I don't want to have a completely
>> derivative set of FormComponents that support this feature, so I would
>> probably modify the main codebase to add the support to all
>> FormComponents. My thought is that I would add a
>> setRequiredFunction(Predicate) method that would store the predicate in
>> MetaData. The isRequired() method would be adjusted to be something like
>>
>> public boolean isRequired() {
>> Predicate func = <get Predicate from MetaData>
>> if (func != null) {
>> return func.evaluate(this);
>> } else {
>> return getFlag(FLAG_REQUIRED);
>> }
>> }
>>
>> Can anyone tell me why this WOULDN'T work? What might some shortcomings
>> be? Would Wicket core be interested in this? If not, why not (it might
>> offer insight as to why this is a bad idea)? Would this add too much
>> overhead to be worthwhile?
>>
>> If you think this is a good idea, why? And would you do anything
>> differently to make this a stronger concept?
>>
>> Thanks for your feedback, I appreciate your time.
>>
>> Charles Deal
>>
>>
>>
>> This is a PRIVATE message. If you are not the intended recipient, please
>> delete without copying and kindly advise us by e-mail of the mistake in
>> delivery.
>> NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
>> any order or other contract unless pursuant to explicit written agreement
>> or government initiative expressly permitting the use of e-mail for such
>> purpose.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isRequired: Use function instead of boolean
Posted by ChuckDeal <cd...@csc.com>.
Ok, so I left out the detail that I have an AbstractPredicate in my
environment that implements Predicate and Serializable.
I honestly don't dare if it is Predicate or not, just that some Class is
able to execute the function. I chose Predicate in my environment because I
use commons-collections, it was already written, and it already had a number
of useful, standard Predicates defined. No need to re-invent the wheel.
Chuck
Johan Compagner wrote:
>
> is a Predicate serializable?
>
--
View this message in context: http://www.nabble.com/isRequired%3A-Use-function-instead-of-boolean-tp23062017p23065139.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isRequired: Use function instead of boolean
Posted by Johan Compagner <jc...@gmail.com>.
is a Predicate serializable?
On Wed, Apr 15, 2009 at 18:05, Charles A Deal <cd...@csc.com> wrote:
> I have a number of Form Components that have a conditional required
> status. In the past, I've seen recommendations to override the component
> and supply a custom implementation of the isRequired function to support
> the proper check. So, in this case, it ignores the boolean that might be
> set by the user. I understand and agree that that is a reasonable
> solution.
>
> In my environment, I have helper functions that, given some parameters,
> build the appropriate components along with labels, validators, behaviors,
> etc. In order to subclass the Form Components, I would have to give up
> that function and, basically, code capture what it does for each instance
> that needs a custom isRequired method. I also have a security
> implementation that uses a Predicate instance (org.apache.commons.
> collections) to control both the RENDER and ENABLED state of a component
> and it seems natural (in my environment) to be able to use a Predicate for
> the isRequired function, as well.
>
> I am soliciting feedback on the idea. I don't want to have a completely
> derivative set of FormComponents that support this feature, so I would
> probably modify the main codebase to add the support to all
> FormComponents. My thought is that I would add a
> setRequiredFunction(Predicate) method that would store the predicate in
> MetaData. The isRequired() method would be adjusted to be something like
>
> public boolean isRequired() {
> Predicate func = <get Predicate from MetaData>
> if (func != null) {
> return func.evaluate(this);
> } else {
> return getFlag(FLAG_REQUIRED);
> }
> }
>
> Can anyone tell me why this WOULDN'T work? What might some shortcomings
> be? Would Wicket core be interested in this? If not, why not (it might
> offer insight as to why this is a bad idea)? Would this add too much
> overhead to be worthwhile?
>
> If you think this is a good idea, why? And would you do anything
> differently to make this a stronger concept?
>
> Thanks for your feedback, I appreciate your time.
>
> Charles Deal
>
>
>
> This is a PRIVATE message. If you are not the intended recipient, please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery.
> NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
> any order or other contract unless pursuant to explicit written agreement
> or government initiative expressly permitting the use of e-mail for such
> purpose.