|Subject:||Progress plus PROBLEM
|Date:||Sat, 25 Aug 2018 06:42:37 +1000
|From:||Bernie van't Hof <firstname.lastname@example.org>
Am progressing well with forms:
- figured out some last details from SET files and am incorporating them
- displaying master and detail forms (single and multi-row) with data.
- repeating area text (not data) still to do, but shouldn't be too hard.
- calculated fields parsed and displayed.
- slowly rationalising display formatting.
However, calculated fields have finally forced me to consider an issue I placed in the too-hard-for-now
basket a long
time ago! Anyone willing to toss in some thoughts (please)?
pdox is loosely typed and uses the same operator (+) for string concatenation and arithmetic
addition, applying rules to
work out which process to invoke depending on data types involved.
Php uses different operators for string concatenation ('.'), and arithmetic add ('+').
The parser does its best to identify data types and translate to the appropriate operator, but
this fails if the data
type is not known until run-time.
1. Add one or more new operator(s) to PAL to force correct operation (easy), but this would
require modifying PAL source
code and it wouldn't work in pdox any more, and the pdox forms calculated fields editor won't
2. Ignore the problem at translate time, possibly producing an "issues" report, and manually
modify the produced php
code to taste. But this must be repeated every time the source PAL code is translated.
2a. Currently form files are converted, and calculated fields are parsed and converted, on-the-fly
at run-time, so 2.
2b. (Thinking aloud) Parsing and translating calculated fields could be done at the time a form
file is parsed. This
fits with the plan to store, cache and modify converted forms.
4. Add directives via pal comments to tell the translator what to do. This does require modifying
the src PAL code, but
survives repeated translate runs, but doesn't address the forms calculated field problem.
5. Ideally this could all be handled by code inserted into the generated php (like variable
scope management is done
currently), but that could make the generated php look very different to the original PAL, and
potentially a lot more
complex, which would make it harder to work with and maybe more fragile.
There will be a "best" solution somewhere, but am trying to keep with the core concept of running
PAL code, a target that is so far being largely achieved.
Welcome to my (crazy) world.