nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Read Extended Attributes w/ FormAPI

LeeCharlebois

I've searched and read posts regarding writing to EA's from FormAPI. I haven't been able to find however a whole lot on reading a DCR's extended attributes and setting fields in a DCR based on the values returned.

I walked into an implementation that was using the values in DCR fields to write to EAs using a callserver. A new requirement has users utilizing the tagUI to apply EAs to DCRs, and I have raised the concern of the EAs and it's corresponding DCR field being out-of-sync.

It's in the onSave event that a callserver is used to write values from DCR items (such as keywords for example) to the DCRs extended attribute. So, if a user then uses the tagUI to modify the DCRs extended attribute and then opens the DCR, edits any field and saves it, the value that they entered in the tagUI is now gone.

Not looking necessarily for a solution, although that would be wonderful Smiley Wink

Perhaps just ideas on the best way to handle this.

Thanks,
Lee

Find more posts tagged with

Comments

yanSi

How about, you add formapi code on form init to call the server to get the current values in the EA and set them in the DCR so that they are in sync?

LeeCharlebois

How about, you add formapi code on form init to call the server to get the current values in the EA and set them in the DCR so that they are in sync?

Do you have any suggestions as to how the callserver would set the values in the DCR? Now we're talking solution. Smiley Wink

nipper

I've searched and read posts regarding writing to EA's from FormAPI. I haven't been able to find however a whole lot on reading a DCR's extended attributes and setting fields in a DCR based on the values returned.

I walked into an implementation that was using the values in DCR fields to write to EAs using a callserver. A new requirement has users utilizing the tagUI to apply EAs to DCRs, and I have raised the concern of the EAs and it's corresponding DCR field being out-of-sync.

It's in the onSave event that a callserver is used to write values from DCR items (such as keywords for example) to the DCRs extended attribute. So, if a user then uses the tagUI to modify the DCRs extended attribute and then opens the DCR, edits any field and saves it, the value that they entered in the tagUI is now gone.

Not looking necessarily for a solution, although that would be wonderful Perhaps just ideas on the best way to handle this.

Thanks,
Lee

1 there is a serious fundamental issue that I do not like. You are keeping the same information in 2 places and will go though serious contoursions trying to keep them in sync. The first thing to consider is if you really need them in 2 places or you can work with one source.

If you do a callserver, a point ot consider is that iwextattr is *slow*. You would be be best getting all EAs (via call server) in XML mode and parsing the list yourself. 1 EA or 10 EAs takes the same 1 second or so.

pammi

Do you have any suggestions as to how the callserver would set the values in the DCR? Now we're talking solution.

you can methods like .setValue() in formAPI

LeeCharlebois

you can methods like .setValue() in formAPI

And how do you get said value that you will put in .setValue("WHATSTHEVALUE?")

LeeCharlebois

1 there is a serious fundamental issue that I do not like. You are keeping the same information in 2 places and will go though serious contoursions trying to keep them in sync. The first thing to consider is if you really need them in 2 places or you can work with one source.

If you do a callserver, a point ot consider is that iwextattr is *slow*. You would be be best getting all EAs (via call server) in XML mode and parsing the list yourself. 1 EA or 10 EAs takes the same 1 second or so.

I absolutely agree Andy. I've been suggesting that approach for some time now but have been getting hairy eyeballs back. For some reason the client is scared of TagUI (BTW - we're TS 6.7.1 SP1, hence, the new generation tagUI) and wants to be able to enter the "metadata" on the DCT itself. Can I print off your post and present that to my client as proof? That should be enough. Smiley Wink

yanSi

Since CallServer doesn't return anything, you'll have to write your own server side script that does return the value from the CLT. On your DCT, use ajax to call your server script.

nipper

I absolutely agree Andy. I've been suggesting that approach for some time now but have been getting hairy eyeballs back. For some reason the client is scared of TagUI (BTW - we're TS 6.7.1 SP1, hence, the new generation tagUI) and wants to be able to enter the "metadata" on the DCT itself. Can I print of your post and present that to my client as proof? That should be enough.

Even better, I will email you with my signature referencing the Devnet Hall of Fame. That should seal the deal. Smiley Very Happy

vpatel

... I've been suggesting that approach for some time now but have been getting hairy eyeballs back. For some reason the client is scared of TagUI (BTW - we're TS 6.7.1 SP1, hence, the new generation tagUI) and wants to be able to enter the "metadata" on the DCT itself ...

Even better, I will email you with my signature referencing the Devnet Hall of Fame. That should seal the deal.

In addition to using Andy's "Hall of Fame" signature :-), to make your customer feel a little bit more comfortable and introduce "TagUI" concept you can do any/some of following:
1. Integrate tagging step in your WFs (similar to PLC WF).
2. Have a "dummy callout button" within your DCT, that doesn't do anything but just pull up the OOTB Tag UI in a popup browser. It doesn't store any tagging info in the DCR; rather just set the EAs.

ISCBorisB

Since CallServer doesn't return anything, you'll have to write your own server side script that does return the value from the CLT. On your DCT, use ajax to call your server script.

True, callSever method itself does not return anything. callServer's script CGI output however renders into DC Form hidden Frame.
From there you (or rather JS code that you'd have to generate) can do what you want, set Items' value, call FormAPI Functions
and the like. There is no need for ajax in FormsPublisher

LeeCharlebois

In addition to using Andy's "Hall of Fame" signature :-), to make your customer feel a little bit more comfortable and introduce "TagUI" concept you can do any/some of following:
1. Integrate tagging step in your WFs (similar to PLC WF).
2. Have a "dummy callout button" within your DCT, that doesn't do anything but just pull up the OOTB Tag UI in a popup browser. It doesn't store any tagging info in the DCR; rather just set the EAs.

Wanna here something crazy? I have implemented suggestion #2 already. The client still feels the need to have some "metadata" in both the DCR and in EAs.

Thanks for the suggestions folks. I'm exploring using a datasource in the FormAPI that will use a java class to return the values of the EA's.

Thanks again,
Lee

LeeCharlebois

True, callSever method itself does not return anything. callServer's script CGI output however renders into DC Form hidden Frame.
From there you (or rather JS code that you'd have to generate) can do what you want, set Items' value, call FormAPI Functions
and the like. There is no need for ajax in FormsPublisher

I'm going to explore this one too Boris. Thanks again!

LC

LeeCharlebois

True, callSever method itself does not return anything. callServer's script CGI output however renders into DC Form hidden Frame.
From there you (or rather JS code that you'd have to generate) can do what you want, set Items' value, call FormAPI Functions
and the like. There is no need for ajax in FormsPublisher

Boris, could you give me a quick example of what the callserver would look like if I wanted to use formApi's .setValue?

ccprofessional

I'm not Boris, but here goes:

your server side script should print something like this:
[html]

<script language="JavaScript">
function onBodyLoad(){
parent.getScriptFrame().IWDatacapture.getItem().setValue();
return true;
}

</script>

[/html]

ISCBorisB

Boris, could you give me a quick example of what the callserver would look like if I wanted to use formApi's .setValue?

[post=103677]This[/post] post shows fairly standard technique that you may use to modify DCR using callServer generated JS.

[post=106459]Here[/post] I've illustrated the use of 'callback' function where instead of operating directly on DCR Items
callServer JS executes native FormAPI Functions. This is IMO the best way to do it. With this approach
JS processing is localized (Server Side Portion simply obtains parameters and makes a "Call Back"),
it's much easier to maintain and change, etc.

[post=83629]This[/post] one illustrates finer callServer points for relatively long execution, threads synchronization and the like

LeeCharlebois

Thanks everyone for your help. I definately have what I need to get started.