ข้ามไปเนื้อหา

ผลต่างระหว่างรุ่นของ "CuneiForm"

เพิ่มขึ้น 1,171 ไบต์ ,  5 เมษายน 2567
บรรทัดที่ 30: บรรทัดที่ 30:
Reading through the CuneiFox code base, one is sure to notice the excessive use of StringFields where one would expect DateFields, TimeFields, FloatFields, and IntegerFields as supported by WTForms. This design choice stems was made to address a challenging browser behaviour. Modern browsers tend to enforce formatting of fields marked as certain types based on the user's locale setting, which can be tied to either the operating system or the browser itself. This automatic formatting can be difficult to override or reverse, leading to inconsistencies and confusion on the user's part especially when switching workstations.
Reading through the CuneiFox code base, one is sure to notice the excessive use of StringFields where one would expect DateFields, TimeFields, FloatFields, and IntegerFields as supported by WTForms. This design choice stems was made to address a challenging browser behaviour. Modern browsers tend to enforce formatting of fields marked as certain types based on the user's locale setting, which can be tied to either the operating system or the browser itself. This automatic formatting can be difficult to override or reverse, leading to inconsistencies and confusion on the user's part especially when switching workstations.


To address this issue, CuneiFox developed its own value typing. Our approach applies our custom-made JavaScript code on unformatted and untyped (as far as the browser is aware) fields. This way, the formatting rendered on the client-side perfectly obeys the company's specific preferences within the CuneiFox system.
To address this issue, CuneiFox developed its own value typing. Our approach applies custom-made JavaScript codes on unformatted and untyped (as far as the browser is aware) fields. This way, the formatting rendered on the client-side perfectly obeys the company's specific preferences within the CuneiFox system.
 
==== Current Incarnation ====
Form value types are specified in the variable {{code|MASTER_sp_type}} residing within form definition code. The variable is of format:
 
<syntaxhighlight lang="python">
MASTER_sptypes = [(str field_name0, str type0), (str field_name1, str type1), ...]
 
# Example from Accounting Journal's withholding tax form
MASTER_sptypes = [("taxdate", "date"), ("taxmonth", "month"),
                  ("rate", "pct"), ("amt", "acc"), ("tax", "acc"),
                  ("rate_2", "pct"), ("amt_2", "acc"), ("tax_2", "acc"),
                  ...]
</syntaxhighlight>
 
==== Available Types ====
Special types valid within CuneiFox system are shown below:
* '''Date types'''
** '''{{code|lang=python|'date'}}'''
** '''{{code|lang=python|'month'}}'''
* '''Time types'''
** '''{{code|lang=python|'time'}}'''
* '''Numeric types'''
** '''{{code|lang=python|'acc'}}'''
** '''{{code|lang=python|'pct'}}'''
** '''{{code|lang=python|'qty'}}'''
** '''{{code|lang=python|'amt'}}'''
** '''{{code|lang=python|'int'}}'''
* '''File types'''
** '''{{code|lang=python|'file'}}'''
** '''{{code|lang=python|'img'}}'''
* '''Other types'''
** '''{{code|lang=python|'color'}}'''


== Initiate ==
== Initiate ==