You are not logged in Log in Join
You are here: Home » Members » Phillip J. Eby's Zope Center » My Wikis » ZPatterns Wiki » AttributeProviders » wikipage_view

Log in
Name

Password

 
 
DynamicDataObjects » DataManagers »

AttributeProviders

AttributeProviders are responsible for getting and/or setting the attributes of DynamicDataObjects. They register the attribute names they support with the DataManagers that contain them, indicating what names they read, and what names they write. Unlike SheetProviders, only one attribute provider is allowed per name/operation pair, and the right to handle a name is on a "first come, first served" basis. That is, if two providers register as getters for the same attribute, the first one listed on the Attribute Providers tab will be the getter. (NOTE: Version 0.4.0 removes this restriction!) Naturally, you can use the "First" button to select attribute providers and move them higher on the list. The diagnostic chart at the bottom of the Attribute Providers tab will always show what attributes are get or set by which providers.

Attribute providers can register the special attribute name "*", which means that they will be called whenever an attribute is get or set whose name is not specifically registered. As with other attribute names, only one provider can actually be registered as a setter or getter for the "*" attribute name.

Attribute providers are usually registered for more than one attribute name per provider, since most useful data sources are more efficiently queried for a variety of attributes at once. For example, a provider might be registered that reads all the attributes from an SQL table row. When asked for one attribute from the table, such providers will read the entire row, and then inject the fields not yet asked for into the requesting object's attribute cache, thus preventing the need for repeated requests to the attribute provider.

Similarly, attribute providers will usually want to have a cache for setting attributes as well, so that changes to an SQL row (for example) are not submitted to the database one field at a time. This is especially important where attributes are being added one at a time to a newly-created object, and data integrity rules in the target system require that all fields be present.