Bric::SOAP::Preference - SOAP interface to Bricolage preferences
use SOAP::Lite; import SOAP::Data 'name'; # setup soap object to login with my $soap = new SOAP::Lite uri => 'http://bricolage.sourceforge.net/Bric/SOAP/Auth', readable => DEBUG; $soap->proxy('http://localhost/soap', cookie_jar => HTTP::Cookies->new(ignore_discard => 1)); # login $soap->login(name(username => USER), name(password => PASSWORD)); # set uri for Preference module $soap->uri('http://bricolage.sourceforge.net/Bric/SOAP/Preference'); # get a list of all preference IDs my $ids = $soap->list_ids()->result;
This module provides a SOAP interface to manipulating Bricolage preferences. Note that per-user preferences are not handled here (probably should be added to the User module).
This method queries the database for matching preferences and returns a list of ids. If none are found, an empty list will be returned.
This method can accept the following named parameters to specify the search. Some fields support matching and are marked with an (M). The value for these fields will be interpreted as an SQL match expression and will be matched case-insensitively. Other fields must specify an exact string to match. Match fields combine to narrow the search results (via ANDs in an SQL WHERE clause).
The preference's name.
The preference's description.
The preference's default value. Note: for values listed as "Off" or "On" in the UI, this will be "0" or "1".
The preference's value. Note: for values listed as "Off" or "On" in the UI, this will be "0" or "1". See
The name of the preference's value. This is what's displayed in the UI. See
Boolean indicating whether a value can be manually entered by the user, rather than selected from a list.
Boolean indicating whether or not users can override the global preference value.
The preference option type. Current possibilities are: select, radio, text. (I think (from displayFormElement.mc) in principle also: password, textarea, checkbox, single_rad, date; and codeselect could be easily added. No preferences currently have any of these types, however.)
Side Effects: NONE
The export method retrieves a set of assets from the database, serializes them and returns them as a single XML document. See Bric::SOAP for the schema of the returned document.
Accepted paramters are:
Specifies a single pref to be retrieved.
Specifies a list of pref_ids. The value for this option should be an array of integer "pref_id" assets.
Side Effects: NONE
This method is unavailable for preferences, since they aren't createable.
The update method updates an asset using the data in an XML document of the format created by export(). A common use of update() is to export() a selected object, make changes to one or more fields and then submit the changes with update().
Returns a list of new ids created in the order of the assets in the document.
Takes the following options:
The XML document where the objects to be updated can be found. The document must contain at least one asset and may contain any number of related asset objects.
A list of "pref_id" integers for the assets to be updated. These must match id attributes on asset elements in the document. If you include objects in the document that are not listed in update_ids then they will be treated as in create(). For that reason an update() with an empty update_ids list is equivalent to a create().
Side Effects: NONE
Notes: Most information output by
export will be ignored on update. For example, you can't change the list of possible values, or whether a preference is "manual". Those are things that are hardcoded into Bricolage. See the
register_fields call in Bric::Util::Pref for which fields are "RDWR" (currently
This method is unavailable for preferences, since they aren't deleteable.
Returns the module name, that is the first argument passed to bric_soap.
Returns true if $param is an allowed parameter to the $method method.
This method provides the meat of update().
Serializes a single pref object into a <pref> pref using the given writer and args.
Scott Lanning <email@example.com>