On Thu, Apr 23, 2009 at 4:29 PM, Hans Dieter Pearcey <[email protected]> wrote:
> It's hard to tell from your example whether there's really a meaningful set of
> behaviors encapsulated by this role (and "has some attributes that look like
> this, without consistent names" doesn't count). Depending on the number of
> possible values for 'boolean_filters', and their possible variance in
> definition, it could make more sense to make a role per filter. (stevan
> suggested this on irc.)
A valid concern, but not one that I believe applies in this case (if
you disagree, a discussion on why would be interesting)... To give a
bit more information on what I'm trying to do, it's for declaring
boolean attributes that eventually will be passed through to
DBIx::Class layer for search filtering. It's looking to replace the
following type of code, variants of which are scattered across our
codebase at-present (incomplete, slimmed down version, to make the
case):
==
sub list_xxx {
my $args = shift();
# parameter validation, all is_xxx fields amtch
qr/^(yes|no|all)$/, now being done as Moose types
my $search_args = {};
my @boolean_fields = ( qw( is_this is_that is_the_other
is_something_else_still ) );
foreach my $field ( @boolean_fields ) {
next if $args->{ $field } eq 'all';
$search_args->{ $field } eq $field eq 'yes' ? 1 : 0;
}
# handling of non-boolean search-terms
# return dbix results from query with above arguments
}
==
A very limited functionality, which won't be extended any further. It
seems to me the ideal candidate for handling as parameterized roles,
as described earlier in the thread, in order to get common behaviour
out of an oft-repeated idiom.
Mark.
