Forum OpenACS Development: Validate Package

Collapse
1: Validate Package
Posted by Barry Books on 06/06/03 01:46 PM
I started a validate package for object_ids and attributes. The code is avaiable here. I'm working on bringing up a 4.6/postgres version of acs so I can produce openacs packages. The current version is only about 100 lines of code so porting should be easy.

Validate

Validate makes ad page contract filters for all acs_object_types and acs_attributes. This allows 

ad_page_contract {
} {
        user_id:user_id
        lastname:person_lastname
}
Future Versions

The current version supports acs 4.2 and Oracle. It should be easy to add Postgres. There is one query that uses the Oracle user_tab_columns table to find the field length.

The attribute validattion needs work. It would be nice to add more info to the metadata as well as have some kind of pluggable filters for new acs_datatypes. The good news is enhancments should be transparent to the user.

Currently valiate is global to the site. It should be subsite aware.

A filter which validates whole objects instead of ids might be nice also. This would allow 

ad_page_contract {
} {
        person:array,person
}
This would work similar to the address widget and set the value person(last_name), person(first_names) etc.

The current version may require two database hits to validate an object_id. Add a parameter to disable the database hits and only valildate for integer.

Collapse
2: Re: Validate Package (response to 1)
Posted by Don Baccus on 06/06/03 06:14 PM
You can cache the db info.

How do you determine which table/column to use?

Collapse
3: Re: Validate Package (response to 1)
Posted by Tom Jackson on 06/06/03 06:46 PM

Before I got to the bottom of your post, I was thinking of a whole object validation, cool. I might want to use this for my query-writer package, which has validation code for each input. Not nearly as fine grained as your idea. I also have the code for getting the postgres field length out of the db. One thing I do for all text input is check the length before trying the insert, something not supported directly by ad_page_contract filters.

Collapse
4: Re: Validate Package (response to 1)
Posted by Barry Books on 06/06/03 07:45 PM
The way it currently works is at webserver start time it reads the acs_object_types table and creates a function for each one. It writes the tcl proc on the fly and evals it. The function it creates checks that the value is a number then gets the object type of that id and compares it to the expected value. If that fails it checks the subtypes also. You could cache this if you assume objects do not change types.

The attribute function creates a function for each attribute type. It gets the table name from acs_attributes or if null acs_object_types. It uses column_name from attributes and if it's null it uses the attribute_name. The attribute check does not require database access (except at at startup).

It would be easy enough to add a parameter to bypass the database checks on object_id. The nice thing about that is you could turn it off if you don't want the performance hit. The page contract remains the same either way.

For example for Person you end up with 

set object_type person
	if { ![regexp {^[0-9]+$} $value] } {
		ad_complain "Value is not a Person id"
		return 0
	}
	set type [db_string t { select object_type from acs_objects where object_id = :value } -default ""]

	if { $type != "person" } {
		if { [db_string c { select count(*) 
					from acs_object_type_supertype_map
					where object_type = :type
					and ancestor_type = :object_type }] == 0 } {
            		ad_complain "Value is not a Person id"
            		return 0
		}
	} 

	return 1