Publishing a property 101 ? Namespaces uncovered

When working with composite applications the most difficult aspect when dealing with Properties and Actions is the namespace. Remember, this architecture came from portal and the idea when the PropertyBroker was defined was to use web services definition language (WSDL) files for the definition of the properties and actions. WSDL?s are all about namespaces! The runtime of the broker really does not care at all about namespaces. As a matter of fact, if you crack open a composite application XML file and look at how a wire is defined you will not see anything about namespaces in it. Here is a sample:

As you can see we really only care about the source and target entity id?s along with the source property (notice no namespace) and the target action (once again, no namespace). So, like in portal, the CAE wiring tool is what ?enforces? proper wiring between types ? otherwise the PropertyBrokerWire extension and the core runtime do no checks.

So now that we understand that, let?s look at a basic WSDL file and figure out what the namespace really means. If you notice in this basic WSDL section we define the property type as ?xsd:string?.

If you reference what ?xsd? is defined as at the top of the file you will see:

xmlns:xsd=http://www.w3.org/2001/XMLSchema

That is the namespace for that property type. Now that we got that out of the way, let?s look at how we would publish a property that uses that type. I try to make all of my WSDL?s use the same part name in the message element as is in the portlet:param section of the operation element. This way its not confusing and you can use the name (email_name) I in your code when publishing the property.

The PropertyBroker service has a lot of API?s around getting actions, types, and properties. The broker keeps a registry of all types, properties, and actions. The first method I am going to show you is creating your own Property object and publishing it.

	PropertyController pc = PropertyFactory.createProperty();
pc.setDirection(Direction.OUT);
pc.setName(?email_name?);
pc.setNamespace(?http://www.w3.org/2001/XMLSchema?);
pc.setOwnerId(getViewId());
pc.setTitle(?Email Name?);
pc.setType(?string?);
pc.setDescription("The email name of the person.");
pc.setTitle("Sets the email name?);

// Create the PropertyValue
// emailName is a class level property that has the currently selected email name

PropertyValue pv = PropertyFactory.createPropertyValue(prop, emailName);

// Publish the property to the broker
broker.changedProperties(new PropertyValue[] { pv }, getViewId());

That is one way to skin the cat. Another way is to look up the property by using the different API?s ? since the broker caches the property already you might as well use it. You can get at the property using the owner ID (which is usually the full view part id) or by using the alternate method and just passing in the namespace and the name of the property.

public Property getProperty(Object owner, String namespace, String propertyName) throws PropertyBrokerException;

public Property getProperty(String namespace, String propertyName) throws PropertyBrokerException;

From there on you create the PropertyValue and publish like the code above. I know I have gotten a lot of emails and conversations around this because for many Notes developers this is still the ?dark side? of the new Notes client. I hope this helps.

Tags: : :

Advertisements

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.