I haven’t dug into it in depth yet, but this is looking pretty good. I think a
nice addition would be to allow specification of a default value. If a var is
defined in your FormBroker DDL-type specification, a default value isn’t
defined, and the value is not present in the response, the broker would raise
an error. Otherwise if the default value is provided but the value isn’t in
the response, the default would be provided.
Another thing… at work we have been leaning toward copying values as they are
checked and possibly transformed from the response array into a new array.
That way there’s no risk that a value in the response array gets used
downstream without having been explicitly called out. An alternative approach
would be to remove any value from the response array that isn’t in the broker
specification (and possibly treat the presence of something unexpected as a
fatal error). One way or another I think it is important that a response value
not be able to be used downstream without being explicitly called out in the
broker specification.
On 10/17/16, 10:29 AM, "Massimo Manghi" <mxman...@apache.org> wrote:
An initial prototype of the Rivet's FormBroker is now available from
trunk/rivet/packages/formbroker.tcl
The code is inspired by Karl's original code but it goes further ahead
trying to become a form definition repository. The overall style of the
package has an OOP flavor even though no one of the OOP environments
available for Tcl was used. It's just 'namespace ensemble' based. I will
henceforth use the word 'object' meaning any instance of form descriptor
created by the FormBroker package.
Forms definition objects are referenced through commands generated by
the FormBroker package with the 'create' call
set fbobj [::FormBroker create \
{var1 string bounds 10 constrain quote} \
{var2 email} \
{var3 integer bounds 10} \
{var4 unsigned bounds {10 100} constrain}]
which is quite similar to the original form broker: each element in
the argument list is a list in its own right in which the first and
second element must be the form variable name and type. At the moment
supported types are 'string', 'integer', 'unsigned', 'email'. Each of
them has its own validation procedure. The supported variable types can
be extended easily, but non portably: I mean that writing a validator
requires explicit manipulation of the dictionary that provides a form
variable internal representation. (As such it's a design flaw, at the
moment). The keyword 'constrain' means that, when possible, a value is
brought within its assigned bounds. For a 'string' it means the string
has to be truncated to be n characters when longer.
The namespace ensemble offers also a 'creategc' method that demands a
Tcl variable name as first argument. The command name is returned and
also stored in the named Tcl variable. When this Tcl variable is
destroyed the unset trace that ensues triggers the object destructor to
be called, causing the form internal representation to be garbage
collected...
A form response is then checked calling
$fbobj validate response
where 'response' is the usual array of variables made by
::rivet::load_response. This method returns 'true' if the array
validates. If the validation fails the method
$fbobj failing
returns a list of variable names with the validation error codes.
Variables can be quoted and the quoting function can be customized (the
internal function just puts a variable value between single quotes). A
custom function for quoting must have the very basic form
set quoted_string [<quoting-proc> $orig_string]
the need for quotation can be variable specific (in that case 'validate'
quotes in the 'response' array only the variables eligible to be
quoted). Overall quoting can be forced by calling
$fbobj validate -forcequote response
There is more to say but I don't want to bother you any further. I will
answer your questions with pleasure. The namespace ensemble API is open
to be amended if you have some strong idea on how to redesign it. I
won't set out writing the documentation any soon: I'm going to allow
more time to see if the design settle down using the package in regular
development (which I still have to do!). If you're interested to write a
specific data type validator I will show you how to (there's an example
in trunk/contrib/validate_mac.tcl which shows how to validate a mac
address)
-- Massimo
P.S. I will certainly remove the 'namespace export *' line from the
package in order to keep private all the methods not intended for
application level programming
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
