A search filter will usually search for things in relations of the actual
search target. A search for sales orders may be filtered by the name of the
-customer. L<Rose::DB::Object> alloes you to search for these by filtering them prefixed with their table:
+customer. L<Rose::DB::Object> allows you to search for these by filtering them prefixed with their table:
query => [
'customer.name' => 'John Doe',
'orddate' => [ lt => DateTime->today ],
]
-Unfortunately, if you specify them in you form as these strings, the form
+Unfortunately, if you specify them in your form as these strings, the form
parser will convert them into nested structures like this:
$::form = bless {
[% L.select_tag('filter.salesman.id', ...) %]
-Additionally you can add modifier to the name to set a certain method:
+Additionally you can add a modifier to the name to set a certain method:
[% L.input_tag('filter.department.description:substr::ilike', ...) %]
=head1 LAUNDERING
Unfortunately Template cannot parse the postfixes if you want to
-rerender the filter. For this reason all colons filter keys are by
+rerender the filter. For this reason all colon filter keys are by
default laundered into underscores, so you can use them like this:
[% L.input_tag('filter.price:number::lt', filter.price_number__lt) %]
All of your original entries will stay intact. If you don't want this to
happen pass C<< no_launder => 1 >> as a parameter. Additionally you can pass a
different target for the laundered values with the C<launder_to> parameter. It
-takes an hashref and will deep copy all values in your filter to the target. So
+takes a hashref and will deep copy all values in your filter to the target. So
if you have a filter that looks like this:
$filter = {
]
]
-For more abuot custom filters, see L<SL::DB::Helper::Filtered>.
+For more about custom filters, see L<SL::DB::Helper::Filtered>.
=head1 FILTERS (leading with :)
L.input_tag('customer.name:substr::ilike', ...)
L.input_tag('invoice.customer.name:substr::ilike', ...)
-This will sarch for orders whose invoice has the _same_ customer, which matches
+This will search for orders whose invoice has the _same_ customer, which matches
both inputs. This is because tables are aliased by their name and not by their
position in with_objects.
=item *
-Additional filters shoud be pluggable.
+Additional filters should be pluggable.
=back
=head1 NAME
-SL::DBUTils.pm: All about Databaseconections in Lx
+SL::DBUTils.pm: All about database connections in kivitendo
=head1 SYNOPSIS
DBUtils relies heavily on two parameters which have to be passed to almost every function: $form and $dbh.
- $form is used for error handling only. It can be omitted in theory, but should not.
- - $dbh is a handle to the databe, as returned by the DBI::connect routine. If you don't have an active connectiong, you can query $form->get_standard_dbh() to get a generic no_auto connection. Don't forget to commit in this case!
+ - $dbh is a handle to the database, as returned by the DBI::connect routine. If you don't have an active connection, you can query $form->get_standard_dbh() to get a generic no_auto connection. Don't forget to commit in this case!
Every function here should accomplish the follwing things:
0,
0]) unless $info_ok;
- # If header is given, there need to be a header for each profile
+ # If header is given, there needs to be a header for each profile
# and no empty headers.
if ($info_ok && $self->header) {
my @header = @{ $self->header };
# people insist that case sensitivity doesn't exist and try to enter all
# sorts of stuff. at this point we've got a profile (with keys that represent
# valid methods), and a header full of strings. if two of them match, the user
- # mopst likely meant that field, so rewrite the header
+ # most likely meant that field, so rewrite the header
if ($self->case_insensitive_header) {
die 'case_insensitive_header is only possible with profile' unless $self->profile;
if ($header) {
sub _check_multiplex_datatype_position {
my ($self) = @_;
- return 1 if !$self->is_multiplexed; # ok if if not multiplexed
+ return 1 if !$self->is_multiplexed; # ok if not multiplexed
my @positions = map { firstidx { 'datatype' eq lc($_) } @{ $_ } } @{ $self->header };
my $first_pos = $positions[0];
See Synopsis.
-Text::CSV offeres already good functions to get lines out of a csv file, but in
-most cases you will want those line to be parsed into hashes or even objects,
+Text::CSV already offers good functions to get lines out of a csv file, but in
+most cases you will want those lines to be parsed into hashes or even objects,
so this model just skips ahead and gives you objects.
Its basic assumptions are:
=item You do know what you expect to be in that csv file.
-This means first and foremost you have knowledge about encoding, number and
+This means first and foremost that you have knowledge about encoding, number and
date format, csv parameters such as quoting and separation characters. You also
know what content will be in that csv and what L<Rose::DB> is responsible for
it. You provide valid header columns and their mapping to the objects.
In this case C<listprice_as_number> will be used to read in values from the
C<listprice> column.
-In case of a One-To-One relationsship these can also be set over
-relationsships by sparating the steps with a dot (C<.>). This will work:
+In case of a One-To-One relationship these can also be set over
+relationships by separating the steps with a dot (C<.>). This will work:
[ {profile => { customer => 'customer.name' }} ]
projects / kivitendo-erp.git / commitdiff