Store One Value, Display Another

I'm working on a redesign of a document object model, a model with nearly 2 million objects stored, IMO, inefficiently. In looking at the various ways one can provide look-ups for users to enter a value I've come across Registered Tables, Custom Object with null supertype, even using dm_folder objects, but I've always had one issue with nearly all of these methods. I want the stored value to be dynamic. IOW, if someone changes the lookup object the change is reflected in the associated objects. To that end, I had planned on storing the r_object_id of the object or objects used as a lookup value but displaying whatever amounts to a "name" attribute. However, it doesn't look possible. I could just store the name value and be done with it but if it ever chagnes I have thousands of objects that no longer have the correct data stored in the attribute.

How have other people handled this problem? Is there a better way?

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

aflowers001

Look up Value Assistance and Mapping Information in the Fundamentals manual, and others.

These in combination with some of what you've already mentioned will achieve what you're after.

also have a search around this site for "Value Assistance"

All comments

aflowers001

Look up Value Assistance and Mapping Information in the Fundamentals manual, and others.

These in combination with some of what you've already mentioned will achieve what you're after.

also have a search around this site for "Value Assistance"

fainemr

Of course I've looked at it. I've looked at everything and I didn't see anything in the fundamentals manual that will help me achieve this, can you be more specific? Perhaps I've missed it, or maybe you misunderstood the question.

Thanks,

-Mark

aflowers001

Apoloies if I took your question as request for where to look.

Let's assume you have DAB for creating your DocApp. You have the ability in there to determine a direct lookup for a field, i.e. value assistance, or you can do mapping, i.e. store one value in the object but have a different value used in a UI that understand it. The help guide in DAB provides some further detail on this.

The lookups can be a DQL statement, or hard coded lists.

For hat you are describing a mapping would appear to suit. You need to have a list of some sort containing the lookup data (registered table, type etc) and you can say that the field takes it's values from a DQL statement and you can determine the amping for what is stored and what is displayed. The standard Documentum provided user interfaces understand this stuff and work with it as expected.

The same facility exists in composer but I haven't done a lot with that yet.

fainemr

I still think the functionality of attributes are a little less than to be desired. I do not believe that it is possible to provide attribute values dynamically. We have a taxonomy that is being developed at a higher organizational level and value assistance will allow me to store the value by looking it up in a registered table or object, however, when the powers that be decide to rename "Missions and Projects" to "Projects and Missions" then all of the objects that were set previously will be wrong. I want to store the row id but display a value attribute at that row index such that I store "42" but my UI always shows "Missions and Projects" if HQ changes the title to "Projects and Missions" all I need to do is change the value at row 42 and all of my objects will show the proper title value.

Do you understand what I'm going for? I don't think this is possible without manually (custom code) performing the query every time the UI displays this value. Also, I only want to store the values in the registered table or object and I only want to maintain a single custom attribute in my object model to record the location of the correct value.

I mean no disrespect and I only want to understand you clearly, are you saying this is possible OOTB?

-Mark

aflowers001

Ah, now you've explained a little more the answer is OOTB this isn't possible.

What you're after is a combination of the 2 facilities offered, value assistance and mapping.

Now value assistance has the capability to query a table/type for a value to store, but the value stored is the value displayed.

Mapping allows the value stored to bedisplayed using a mapping value. Unfortunately this has been implemented as coming from a static list.

Now you do have options.

First off you can customise the user interface to do what you require. Not ideal but it's often the only solution.

Second you could look into what using a TBO could provide. Could getString etc be modified? Never tried this so it's just a thought.

Third you could use value mapping and could regularly update the mapping from your source database, although that isn't an ideal solution as you have the data in 2 places and there will be a gap between an update in the master source populating the child. Take a look at support note https://solutions.emc.com/emcsolutionview.asp?id=esg18251. It talks about the underlying types, which lead to tables which leads to other possibilities.

fainemr

"Mapping allows the value stored to bedisplayed using a mapping value. Unfortunately this has been implemented as coming from a static list."

Hmm. Do you think this static list is a data dictionary attribute that can be updated via DQL? If so, there might be hope that we can get around this limitation.

----

Nevermind from the support note you posted I can see that the mapping is updatable via DQL but it looks like it might be more trouble than it is worth.

Thanks,

-Mark

Message was edited by: fainemr

BertMoons

We also implemented a solution like this. We had a key as value and saved to the repository and we wanted to display a label to ui depending on other attributes and on the users locale.

There is no very nice and straightforward solution for this. We had to customise the tag classes and the search tag classes.

In those classes we saw that WDK sometimes didn't made a difference between the display value and the actual value.

This solution worked fine, we only had to customise 2 classes. But still it should be nice for a feature request if something like this was supported.

Bert

Francois Dauberlieu

Hmm.  Do you think this static list is a data dictionary attribute that can be updated via DQL?  If so, there might be hope that we can get around this limitation.

Yes, I wrote a couple of years ago a simple DocBasic procedure that would read a registered table and populate the attribute mapping.

Have a look at the ALTER TYPE DQl statement in the appropriate documentation

fainemr

Yeah, I implemented this as a method yesterday but I have not yet tested it. I will probably do that today. Did you do a drop of all the value assistance and mapping data and recreate it every time it ran? I wrote the code to wipe it out and recreate it at every execution and I'm wondering if that was necessary. I'm thinking I will set it up as a job and run it as needed, maybe later I'll have it check the DB and run only if the DB has changed, though right now that seems like too much work.

-Mark

Francois Dauberlieu

yes I did drop it as the procedure didn't run very often, only when the table changed, so I didn't bother checking what was changed and applying the modifications, I just dropped it and reloaded it completely