Can you define
what the impl_name and impl_owner_name are in the following sql code?
The impl_owner_name is the package key of the package that provides the implementation (in our case
ecommerce). The impl_name should be the object_type of the items that you want to index/search. So, for example
ec_product, if you want to index/search ecommerce products. The sql code is:
select acs_sc_impl__new(
'FtsContentProvider', -- impl_contract_name
'ec_product', -- impl_name
'ecommerce' -- impl_owner_name
);
Note that for FtsContentProvider to work ok, you might need to write some triggers to update the search_observer_queue table. Unless, your content items are stored in the CR, you need to write the triggers. For examples look at
notes-sc-create.sql and
content-search.sql.
Eventually, I would like to get some information on how to write a service contract. Is there any code that I can look at to see how it should be written?
So far we have identified two kinds of contract:
-
impl_name is an object_type: We decide on which implementation to use by computing the type from an object_id using acs_object_util__get_object_type. FtsContentProvider is an example of this kind of contract.
-
impl_name is a package_key: We decide on which implementation to use by using the value of the parameter in the dependant package (the package that uses the contract). FtsEngineDriver is an example of this kind of contract.
If you want to write the PaymentGateway (pls, try to use this naming convention) contract, then the second case is probably what you'll need. Additionally, when writing a service contract you should try to foresee all possible implementations of the service contract. This involves two steps:
- Decide what the operations are.
- Decide on the message types (input/output). While message types are not being used extensively at this moment, they will soon be used to provide WSDL functionality.
- It is very important to note that once a contract is stabilized/released there is no turning back. At least it will be difficult to update all available implementations -- and probably we won't know all the implementations because people might have independantly developed their own implementations of a contract. Maybe, we should keep track of all implementations of a contract at a repository when the new openacs.org site is released so that we can inform people when something changes (I haven't thought of this very much, so if someone has a different POV please let us know).
Check search-sc-create.sql for the specification of FtsContentProvider and FtsEngineDriver. If you think your service contract doesn't fit in any of these categories please post more questions.
