You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Massimo Manghi <mx...@apache.org> on 2016/10/17 15:29:23 UTC
Rivet's FormBroker package
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-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet's FormBroker package
Posted by Massimo Manghi <ma...@biol.unipr.it>.
I've just committed a new version of the form broker that handles also
default values (just adding 'default <value>' to the list)
method 'validate' now accept a third optional parameter as name of an
array where the filtered response is copied into. If this argument is
specified then the original 'response' array is (should be) untouched
$fbobj validate ?-forcequote? response ?filtered_response?
-- Massimo
On 10/17/2016 07:51 PM, Karl Lehenbauer wrote:
> I haven\u2019t 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\u2019t 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\u2019t in the response,
> the default would be provided.
>
> Another thing\u2026 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\u2019s 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\u2019t 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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet's FormBroker package
Posted by Massimo Manghi <mx...@apache.org>.
More commits to the formbroker package:
- the default values management has been improved
and simplified.
- new method 'response' fills an array with the last processed
response. If called before method 'validate' the array is filled with
only the defaults values assigned to the form variables. This makes
possible to always have a response array to pass to the form package creator
$fbobj response ?last_response?
populates the array 'last_response' with the processed response. If no
argument is given the default array name is 'response' following the
same convention of ::rivet::load_response
for completeness we also should add a 'reset' method that invalidates
the internal form representation and brings it to its initial status
-- Massimo
On 10/18/2016 09:49 PM, Massimo Manghi wrote:
> I'm sending this message to the list once again because I wrote it from
> a non subscribed address but apparently I tell elzm to accept it (maybe
> someone did moderate it out?)
>
> I've just committed a new version of the form broker that handles also
> default values (just adding 'default <value>' to the list)
>
> method 'validate' now accept a third optional parameter as name of an
> array where the filtered response is copied into. If this argument is
> specified then the original 'response' array is (should be) untouched
>
> $fbobj validate ?-forcequote? response ?filtered_response?
>
> -- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet's FormBroker package
Posted by Massimo Manghi <mx...@apache.org>.
I'm sending this message to the list once again because I wrote it from
a non subscribed address but apparently I tell elzm to accept it (maybe
someone did moderate it out?)
I've just committed a new version of the form broker that handles also
default values (just adding 'default <value>' to the list)
method 'validate' now accept a third optional parameter as name of an
array where the filtered response is copied into. If this argument is
specified then the original 'response' array is (should be) untouched
$fbobj validate ?-forcequote? response ?filtered_response?
-- Massimo
On 10/17/2016 07:51 PM, Karl Lehenbauer wrote:
> I haven\u2019t 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\u2019t 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\u2019t in the response,
> the default would be provided.
>
> Another thing\u2026 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\u2019s 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\u2019t 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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet's FormBroker package
Posted by Karl Lehenbauer <ka...@flightaware.com>.
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" <mx...@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-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org