Optimal pattern for locating a specific Attribute amongst the Categories of a Node in order to manip

So, given the methods available today with CS10.5 what's the better way to do this? I sense what I should be doing is pulling an empty reference object based on the definition of the category of interest, 'locating' the matching object within the Category object(s) associated with the node, updating the attribute of interest through the reference object, and merging the resulting modified Category data back into the node.

Any suggestions would be most welcome (bonus karma for Java samples).

------------------------

// pull the Metadata associated with this Node Metadata thisNodeMetadata = docManClient.getNode(thisNode.getID()).getMetadata();// so long as there is something to look throughif ((thisNodeMetadata.getAttributeGroups()).size() > 0) {    List<AttributeGroup> thisNodeAttributeGroups = thisNodeMetadata.getAttributeGroups();    // walk the sets of Attributes        for (AttributeGroup thisNodeAttributeGroup : thisNodeAttributeGroups) {        // until we find the set of interest        if (thisNodeAttributeGroup.getDisplayName().equals("Legacy Document Info")) {            List<DataValue> thisNodeAttributeGroupDataValues = thisNodeAttributeGroup.getValues();            // then walk the attributes within the set of interest            for (DataValue thisNodeAttributeGroupDataValue : thisNodeAttributeGroupDataValues){                // until we find the attribute of interest                if (thisNodeAttributeGroupDataValue.getDescription().equals("Legacy Path")) {                        // only change it if it's not the same so we don't waste cycles                        if (!(((StringValue)thisNodeAttributeGroupDataValue).getValues()).toString().equals(targetPath)) {                            // clear out the attribute if it isn't already empty                            if (!((StringValue)thisNodeAttributeGroupDataValue).getValues().isEmpty())  ((StringValue)thisNodeAttributeGroupDataValue).getValues().clear();                            // and add in the new value                            ((StringValue)thisNodeAttributeGroupDataValue).getValues().add(targetPath);                            // now go and update the List of AttributeGroupDataValues with the modified AttributeGroupDataValue                            int indexOfAGDV = thisNodeAttributeGroupDataValues.indexOf(thisNodeAttributeGroupDataValue);                            thisNodeAttributeGroupDataValues.set(indexOfAGDV, thisNodeAttributeGroupDataValue);                            // finally go and update the List of AttributeGroups with the modified AttributeGroup                            int indexOfAG = thisNodeAttributeGroups.indexOf(thisNodeAttributeGroup);                            thisNodeMetadata.getAttributeGroups().set(indexOfAG, thisNodeAttributeGroup);                            // and commit the change back to the database                            docManClient.setNodeMetadata(thisNode.getID(), thisNodeMetadata);                        }                   }              }         }    }}

Find more posts tagged with

Comments

sıɹɥɔ

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

Hi Kris,

If I understand correctly you're looking to reduce the amount of code you're using to update a particular attribute value. (You may also be wanting to change the method by which metadata structures are stored/accessed but that's typically done in client libraries and not directly with the api.) I'll assume you're asking for some code critique too. :-)

There are a few things that stand out in your example as being a little excessive. First, you don't need to call getNode for a node that you already have. Next, you don't need to check whether the size of an attribute group is non-zero before getting it and iterating over it. Similarly you don't need to check whether a list is empty before clearing it. And most importantly, you don't need to update a structure with the same parts of that structure.

From a style perspective I'd suggest that you don't need to cast a variable multiple times. And finally, it's just me but I'm a little allergic to deeply nested code logic, and prefer to "bail out" when I can.

With all that said, here's my equivalent to your code:

Metadata metadata = thisNode.getMetadata();

        for (AttributeGroup attrGroup : metadata.getAttributeGroups()) {
            if (!attrGroup.getDisplayName().equals("Legacy Document Info"))
                continue;

            for (DataValue dataValue : attrGroup.getValues()) {
                if (!dataValue.getDescription().equals("Legacy Path"))
                    continue;

List<String> values = ((StringValue) dataValue).getValues();

if (values.size() > 0 && values.get(0).equals(targetPath))
continue;

values.clear();
values.add(targetPath);

                docMan.setNodeMetadata(thisNode.getID(), metadata);
            }
        }

Hope you find the criticism constructive!

Thanks,

-chris

From: eLink Entry: Content Web Services Forum [mailto:otdncontentwebservices971forum@elinkkc.opentext.com]
Sent: Tuesday, June 02, 2015 3:59 PM
To: eLink Recipient
Subject: Optimal pattern for locating a specific Attribute amongst the Categories of a Node in order to manipulate it, using Java?

Optimal pattern for locating a specific Attribute amongst the Categories of a Node in order to manipulate it, using Java?

Posted by kris.boutilier@scrd.ca (Boutilier, Kris) On 06/02/2015 06:55 PM

I'm doing some work with Node Categories through CWS - to locate the specific information I need to manipulate I'm currently iterating through all of the Category data until I arrive at the attribute of interest, which seems inelegant at best (see code fragment below).So, given the methods available today with CS10.5 what's the better way to do this? I sense what I should be doing is pulling an empty reference object based on the definition of the category of interest, 'locating' the matching object within the Category object(s) associated with the node, updating the attribute of interest through the reference object, and merging the resulting modified Category data back into the node.Any suggestions would be most welcome (bonus karma for Java samples).------------------------// pull the Metadata associated with this Node Metadata thisNodeMetadata = docManClient.getNode(thisNode.getID()).getMetadata();// so long as there is something to look throughif ((thisNodeMetadata.getAttributeGroups()).size() > 0) { List<AttributeGroup> thisNodeAttributeGroups = thisNodeMetadata.getAttributeGroups(); // walk the sets of Attributes for (AttributeGroup thisNodeAttributeGroup : thisNodeAttributeGroups) { // until we find the set of interest if (thisNodeAttributeGroup.getDisplayName().equals("Legacy Document Info")) { List<DataValue> thisNodeAttributeGroupDataValues = thisNodeAttributeGroup.getValues(); // then walk the attributes within the set of interest for (DataValue thisNodeAttributeGroupDataValue : thisNodeAttributeGroupDataValues){ // until we find the attribute of interest if (thisNodeAttributeGroupDataValue.getDescription().equals("Legacy Path")) { // only change it if it's not the same so we don't waste cycles if (!(((StringValue)thisNodeAttributeGroupDataValue).getValues()).toString().equals(targetPath)) { // clear out the attribute if it isn't already empty if (!((StringValue)thisNodeAttributeGroupDataValue).getValues().isEmpty()) ((StringValue)thisNodeAttributeGroupDataValue).getValues().clear(); // and add in the new value ((StringValue)thisNodeAttributeGroupDataValue).getValues().add(targetPath); // now go and update the List of AttributeGroupDataValues with the modified AttributeGroupDataValue int indexOfAGDV = thisNodeAttributeGroupDataValues.indexOf(thisNodeAttributeGroupDataValue); thisNodeAttributeGroupDataValues.set(indexOfAGDV, thisNodeAttributeGroupDataValue); // finally go and update the List of AttributeGroups with the modified AttributeGroup int indexOfAG = thisNodeAttributeGroups.indexOf(thisNodeAttributeGroup); thisNodeMetadata.getAttributeGroups().set(indexOfAG, thisNodeAttributeGroup); // and commit the change back to the database docManClient.setNodeMetadata(thisNode.getID(), thisNodeMetadata); } } } } }}

[To post a comment, use the normal reply function]
Forum:	Content Web Services Forum
Content Server:	Knowledge Center

Kris Boutilier

This is far cleaner approach to coding it, thanks for the tips. Critique is always a good thing!

I was re-fetching the node as the incoming thisNode object is sparse - it was produced by listNodes() with the partialData flag. That sparse object was pulled off a long queue of nodes pending work that is being serviced by a large pool of common worker threads (using parallelism to achieve throughput as the individual calls themselves seem to be terribly expensive).

This structure:

values.get(0)

may be an unsafe assumption in the sense that the zeroth position in that list is not guaranteed to contain the attribute of interest, especially as it seems the Category model does not require all instances of a Category be at a consistent schema version at all times (eg. a 'category upgrade' is not an atomic operation).

I was hoping that there might be a method along the lines of:

(metadata.getAttributeGroups()).findAttributeByLabel('Legacy Document Info::Legacy Path')

such that one could simply ignore the possible schema differences (the attribute would either exist or not, in what order would be irrelevant) and thereby eliminate the iteration entirely. Eg.:

try {
if( !((metadata.getAttributeGroups()).findAttributeByLabel('Legacy Document Info::Legacy Path')).getValues().equals(StringValueListToCompareTo)) {
((metadata.getAttributeGroups()).findAttributeByLabel('Legacy Document Info::Legacy Path')).setValues(StringValueListToCompareTo)
} catch (AttributeNotFound e) { ...

However, if it has to be nested iteration then your technique is superior to mine - the remainder of the logic was necessarily ugly and simplistic as I was trying to divine the correct sequence of operations mostly through trial and error, trying not to corrupt my test database as I progressed.

Quoted Chris Webster on 06/02/2015 07:14 PM:

Hi Kris,

With all that said, here's my equivalent to your code:

Kyle_Swidrovich

Hi Kris,

I was recently appointed as the Product Manager for Content Web Services here at OpenText.

I agree with your suggestion that pulling up an Attribute or AttributeGroup by name as opposed to ID would be much more user friendly (and would make client code a lot more readable).

One difficulty is that although Attributes are unique in their name/description within a given AttributeGroup (category), multiple AttributeGroups (categories) with the same name can currently be applied to a node, as long as they are different category templates.

This means that retrieval of an AttributeGroup simply by name would not guarantee uniqueness.

Although we’re focused this year on closing some gaps between APIs, I’ll definitely get something into my “wish list” to look into enhancing this.

Cheers,

Kyle

Kris Boutilier

Congratulations on your appointment Kyle. You'll need to get your tag changed on here from 'External Contributor' to 'Fount of All Knowledge'!

I can see your point that a multiple instances of a category with overlapping labels would be a problem - finding by label was perhaps an overly simplistic example. More realistic would be an attribute GUID stored with the template, or perhaps some sort of an XPath/Xpointer-ish query mechanism.

Regardless, iteration works fine - I just wanted to make sure I hadn't missed something more elegant & efficient.