At 02:01 PM 6/1/2005 -0700, Morgen Sagen wrote:
On May 31, 2005, at 8:27 PM, Phillip J. Eby wrote:
First, I noticed that in all cases where cloudAlias is used, it is
used on *all* of the "byCloud" endpoints in that cloud, and it
invariably matches the alias of that cloud. In other words, clouds
aliased as the "default" cloud always use a cloudAlias
value="default", if they hav any cloudAlias elements. My question:
is there ever a time that you would need to specify a *different*
cloud name?
I can't think of a situation when traversing and endpoint by cloud
should switch to a different cloud. So not being able to specify a
cloudAlias for an endpoint seems reasonable.
Second, I found that of a total of 32 endpoints defined as
"byCloud", 9 of these did not have a cloudAlias element specified.
Are these defaulting to the same meaning as an explicit cloudAlias
with the same name as the alias of the defining cloud, or does it
mean something else altogether?
I believe leaving the cloudAliases out of the endpoint definitions
means the various methods such as Cloud.getItems( ) will use the
cloudAlias that is passed to the method:
http://o11n.org/docs/current/api/repository.schema.Cloud.Cloud-
class.html#getItems
...which I think we always pass. As a test I removed all the
cloudAlias values on every byCloud endpoint and things still worked.
Unless I am missing something, I think we can get by without having
cloudAliases defined on byCloud endpoints, since when it comes time
to actually use them, we pass in a cloudAlias (such as "default", or
"sharing") anyway.
Thanks Morgen. Here's my proposed schema API for this, then:
class Contact(ContentItem):
contactName = schema.One(ContactName,
inverse = ContactName.contact,
initialValue=None
)
emailAddress = schema.One(schema.String,
displayName="Email Address",
initialValue=""
)
# ... more attributes here
schema.addClouds(
sharing = schema.Cloud(
byRef = [emailAddress], byCloud = [contactName]
)
)
In other words, you include a 'schema.addClouds()' call in the body of the
class for a kind, and use keyword arguments to define individual clouds
under their respective aliases. The keyword arguments to the Cloud
constructor define the inclusion policies, and each keyword takes a list of
endpoint objects that follow that policy. As a convenient shorthand, using
an attribute object in place of an endpoint creates an endpoint with that
name, for that attribute, since this is the most common kind of endpoint
definition.
I'm thinking that the 'byCloud' keyword should set the cloudAlias to None,
but if we need to be explicit about that later, we could add the cloud
alias to the keyword. For example:
schema.addClouds(
sharing = schema.Cloud(
byRef = [emailAddress], byCloud_sharing = [contactName]
)
)
This would set the cloudAlias for the contactName endpoint to "sharing". A
similar technique could also be used for byMethod, e.g.
"byMethod_someMethod=[someAttr]", if it turns out we need that.
Initially, however, I would just do the basic keywords with no dynamic
cloudAlias or method names.
Anybody have any comments?
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
