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
    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 
      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 
      -- 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

Reply via email to