Revision 66022cbd
Von Sven Schöling vor fast 15 Jahren hinzugefügt
SL/Form.pm | ||
---|---|---|
68 | 68 |
} |
69 | 69 |
} |
70 | 70 |
|
71 |
=item _store_value() |
|
72 |
|
|
73 |
parses a complex var name, and stores it in the form. |
|
74 |
|
|
75 |
syntax: |
|
76 |
$form->_store_value($key, $value); |
|
77 |
|
|
78 |
keys must start with a string, and can contain various tokens. |
|
79 |
supported key structures are: |
|
80 |
|
|
81 |
1. simple access |
|
82 |
simple key strings work as expected |
|
83 |
|
|
84 |
id => $form->{id} |
|
85 |
|
|
86 |
2. hash access. |
|
87 |
separating two keys by a dot (.) will result in a hash lookup for the inner value |
|
88 |
this is similar to the behaviour of java and templating mechanisms. |
|
89 |
|
|
90 |
filter.description => $form->{filter}->{description} |
|
91 |
|
|
92 |
3. array+hashref access |
|
93 |
|
|
94 |
adding brackets ([]) before the dot will cause the next hash to be put into an array. |
|
95 |
using [+] instead of [] will force a new array index. this is useful for recurring |
|
96 |
data structures like part lists. put a [+] into the first varname, and use [] on the |
|
97 |
following ones. |
|
98 |
|
|
99 |
repeating these names in your template: |
|
100 |
|
|
101 |
invoice.items[+].id |
|
102 |
invoice.items[].parts_id |
|
103 |
|
|
104 |
will result in: |
|
105 |
|
|
106 |
$form->{invoice}->{items}->[ |
|
107 |
{ |
|
108 |
id => ... |
|
109 |
parts_id => ... |
|
110 |
}, |
|
111 |
{ |
|
112 |
id => ... |
|
113 |
parts_id => ... |
|
114 |
} |
|
115 |
... |
|
116 |
] |
|
117 |
|
|
118 |
4. arrays |
|
119 |
|
|
120 |
using brackets at the end of a name will result in a pure array to be created. |
|
121 |
note that you mustn't use [+], which is reserved for array+hash access and will |
|
122 |
result in undefined behaviour in array context. |
|
123 |
|
|
124 |
filter.status[] => $form->{status}->[ val1, val2, ... ] |
|
125 |
|
|
126 |
=cut |
|
127 | 71 |
sub _store_value { |
128 | 72 |
$main::lxdebug->enter_sub(2); |
129 | 73 |
|
... | ... | |
3315 | 3259 |
return $var; |
3316 | 3260 |
} |
3317 | 3261 |
|
3318 |
=item update_business |
|
3319 |
|
|
3320 |
PARAMS (not named): |
|
3321 |
\%config, - config hashref |
|
3322 |
$business_id, - business id |
|
3323 |
$dbh - optional database handle |
|
3324 |
|
|
3325 |
handles business (thats customer/vendor types) sequences. |
|
3326 |
|
|
3327 |
special behaviour for empty strings in customerinitnumber field: |
|
3328 |
will in this case not increase the value, and return undef. |
|
3329 |
|
|
3330 |
=cut |
|
3331 | 3262 |
sub update_business { |
3332 | 3263 |
$main::lxdebug->enter_sub(); |
3333 | 3264 |
|
... | ... | |
3501 | 3432 |
} |
3502 | 3433 |
|
3503 | 3434 |
1; |
3435 |
|
|
3436 |
__END__ |
|
3437 |
|
|
3438 |
=head1 NAME |
|
3439 |
|
|
3440 |
SL::Form.pm - main data object. |
|
3441 |
|
|
3442 |
=head1 SYNOPSIS |
|
3443 |
|
|
3444 |
This is the main data object of Lx-Office. |
|
3445 |
Unfortunately it also acts as a god object for certain data retrieval procedures used in the entry points. |
|
3446 |
Points of interest for a beginner are: |
|
3447 |
|
|
3448 |
- $form->error - renders a generic error in html. accepts an error message |
|
3449 |
- $form->get_standard_dbh - returns a database connection for the |
|
3450 |
|
|
3451 |
=head1 SPECIAL FUNCTIONS |
|
3452 |
|
|
3453 |
=over 4 |
|
3454 |
|
|
3455 |
=item _store_value() |
|
3456 |
|
|
3457 |
parses a complex var name, and stores it in the form. |
|
3458 |
|
|
3459 |
syntax: |
|
3460 |
$form->_store_value($key, $value); |
|
3461 |
|
|
3462 |
keys must start with a string, and can contain various tokens. |
|
3463 |
supported key structures are: |
|
3464 |
|
|
3465 |
1. simple access |
|
3466 |
simple key strings work as expected |
|
3467 |
|
|
3468 |
id => $form->{id} |
|
3469 |
|
|
3470 |
2. hash access. |
|
3471 |
separating two keys by a dot (.) will result in a hash lookup for the inner value |
|
3472 |
this is similar to the behaviour of java and templating mechanisms. |
|
3473 |
|
|
3474 |
filter.description => $form->{filter}->{description} |
|
3475 |
|
|
3476 |
3. array+hashref access |
|
3477 |
|
|
3478 |
adding brackets ([]) before the dot will cause the next hash to be put into an array. |
|
3479 |
using [+] instead of [] will force a new array index. this is useful for recurring |
|
3480 |
data structures like part lists. put a [+] into the first varname, and use [] on the |
|
3481 |
following ones. |
|
3482 |
|
|
3483 |
repeating these names in your template: |
|
3484 |
|
|
3485 |
invoice.items[+].id |
|
3486 |
invoice.items[].parts_id |
|
3487 |
|
|
3488 |
will result in: |
|
3489 |
|
|
3490 |
$form->{invoice}->{items}->[ |
|
3491 |
{ |
|
3492 |
id => ... |
|
3493 |
parts_id => ... |
|
3494 |
}, |
|
3495 |
{ |
|
3496 |
id => ... |
|
3497 |
parts_id => ... |
|
3498 |
} |
|
3499 |
... |
|
3500 |
] |
|
3501 |
|
|
3502 |
4. arrays |
|
3503 |
|
|
3504 |
using brackets at the end of a name will result in a pure array to be created. |
|
3505 |
note that you mustn't use [+], which is reserved for array+hash access and will |
|
3506 |
result in undefined behaviour in array context. |
|
3507 |
|
|
3508 |
filter.status[] => $form->{status}->[ val1, val2, ... ] |
|
3509 |
|
|
3510 |
=item update_business PARAMS |
|
3511 |
|
|
3512 |
PARAMS (not named): |
|
3513 |
\%config, - config hashref |
|
3514 |
$business_id, - business id |
|
3515 |
$dbh - optional database handle |
|
3516 |
|
|
3517 |
handles business (thats customer/vendor types) sequences. |
|
3518 |
|
|
3519 |
special behaviour for empty strings in customerinitnumber field: |
|
3520 |
will in this case not increase the value, and return undef. |
|
3521 |
|
|
3522 |
=back |
|
3523 |
|
|
3524 |
=cut |
Auch abrufbar als: Unified diff
Dokumentation einheitlich in den Footer verschoben, Datei mit END abgeschlossen (beschleunigt parsen), und POD Fehler gefixt.