[Xotcl] -type of Attributes

Gustaf Neumann neumann at wu-wien.ac.at
Fri May 2 21:04:21 CEST 2008

Eckhard Lehmann schrieb:
> Hi,
> two questions on the -type field of the Attribute class:
> 1)
> There is obviously no documentation on the available types? I needed to 
> force an error on a wrong -type that told me all the available types
The type-checking is implemented in Tcl and is not hardcoded.
The logic is defined in the method mk_type_checker of the
class ::xotcl::Attribute and behaves as follows:

 a) if the specified "-type" of an ::xotcl::Attribute is an XOTcl class,
     the specified values have to be instances of the class

     In the example below, the attribute tasks of a Workflow
     has to be filled with instances of Task.

     xotcl::Class Task

     xotcl::Class create Workflow -slots {
       Attribute tasks -multivalued true -type Task
       Attribute name -default ""
     The full example is in 

 b) if the specified "-type" of an ::xotcl::Attribute consists of a 
single word,
    the single word is interpeted as a string-class of Tcl's
    "string is  STRING-CLASS value"

 c) "-type" of an ::xotcl::Attribute consists of a single word, it is
    interpreted as a method call in XOTcl.

    See for example:
     Class Person -slots {
       Attribute sex -type "my sex" -proc sex {value} {
         switch -glob $value {
           m* {my uplevel {$obj set $var m}; return 1}
           f* {my uplevel {$obj set $var f}; return 1}
           default {return 0}

  So, the potential range of permissable values is quite large, since it 
  all STRING-CLASSES from Tcl, all classes from XOTcl
  (::xotcl::Class info instances -closure) and potentially, all methods
  that can be defined in XOTcl.

> 2)
> Is there a -type that denotes a string? There is alnum and alpha, but I 
> mean ordinary strings that can contain arbitrary (utf-8, ISO-8859-1 
> etc.) characters? Or alternatively, are the types extensible?
   All types are extensible, actually in multiple dimensions: one can define
   different checking methods, and one can as well define new types
   of ::xotcl::Attributes via subclassing. The latter ensures reusability.
> Background of this question: The -type of an attribute seems to be a 
> useful invention for an automated persistency framework for databases. 
> The problem with that automation is currently that you can not really 
> generate SQL automatically for XOTcl attributes, because you don't know 
> their exact storage types from looking at the classes.
> If it was possible to assign the proper -type to attributes (e.g. 
> "text", "date", "bytea" ...), then I could see two cool possibilities 
> for a persistency framework:
  Sure. In the OpenACS framework, xotcl-core contains definitions for
  subclassing ::xotcl::Attribute with ::xo::db::Attribute, which are 
  attributes containing e.g. the column_name or the sql-type. Note that 
  types might be different depending on the used database m management 

  see for example slide 28ff in
> a) create XOTcl classes automatically using meta information of the 
> database, and -type as validator
> b) create CRUD and select statements automatically from XOTcl classes, 
> using -type for the proper quoting/format that the database expects
   This can be achieved in various ways.

   Certainly, one can keep the meta-data in XOTcl, and create just
   the tables in SQL (see e.g. slide 38ff), where the definitions
   are used to create the tables and the CRUD methods.

   In OpenACS exits already a rich meta-data catalog, stored in
   the database (e.g. acs_object_types, acs_attributes, ...).
   The xotcl-componets use there the pre-existing catalog and can generate
   on the fly XOTcl classes from this. The appropriate method is
   "get_class_from_db", see slide 45 above.

   It is certainly a question, whether the xotcl-type checker is the best
   instrument, since one would like to check e.g. referential integrity,
   or as some other value constraints. Furthermore, the database
   has sometimes other understanding of permissable values to
   certain types than tcl (e.g. for boolean values). In come cases,
   the xotcl-core layer provides value constraints for table definitions.

   The next major release of XOTcl will have several improvements
   in this area. For example, it will use the same type checking mechanisms
   for non-positional arguments and slot values and clean up some
   legacy stuff (i have this - and many more improvements - in my
   leading edge branch, not sure, how much of this will make it
   into the next release).

   best regards
-gustaf neumann

More information about the Xotcl mailing list