cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

The PTC Community email address has changed to community-mailer@ptc.com. Learn more.

Read-only attributes

ptc-953926
1-Newbie

Read-only attributes

Adepters:

We're using Arbortext Editor 5.2 patch 130 with a custom schema. I've had some queries about implementing a read-only attribute in the editor. Basically, our CMS is going to assign an "id" attribute to certain elements that we don't want the user to be able to edit. However, they will need to be able to see it and it would be desirable that they can copy and paste it for links and other references. I've dug through the documentation for the DCF file, but don't see any option that meets my needs. Any ideas?

Dave Hintz
Siemens
10 REPLIES 10

Even if attributes are both screen-hidden and dialog-hidden, you can
always use the "cumbersome brute-force method" and copy the source tag
and paste it into NotePad, then copy and paste the target tag similarly.
Then you can copy/paste the attribute from one tag to the other in
NotePad, and then copy/paste the entire target tag from NotePad back in
to Arbortext Editor, overwriting the existing one.
I don't have to do this often, so this method is no great burden on me.
If you need to do this frequently, then a better method would need to be
created.

There may be a more elegant solution available through the modify_tag
callback. Or possibly through the use of oid_modified() in conjunction
with the save callback (like capture the ID atts in an array along with
OIDs, and upon save, check the OIDs for modification, and replace the id
values with the values from the array). Seems like a lot of overhead,
but just browsing my online help and my forehand knowledge, this may be
your best route.

I know in the DCF (at least at 5.3) you can isolate changes to where
element content can be edited, but not the element itself (attributes).
Unfortunately, there's no way to lock down one att without locking them
all down (without custom code).

HIH,

-Jason

Hi David--

Did you try <attributeoption attribute="id" readonly="yes"/"> in the DCF?

If that doesn't do what you need it to, I'd probably pursue Jason's
suggestion of a modify_tag callback to suppress the attr change if it's one
of the ID attrs you want to protect.

--Clay

Clay Helberg
Senior Consultant
TerraXML

There is no "readOnly" attribute for <attributeoption>. At least not for 5.2 patch M130. Also, I don't find any mention of it in the documentation.

Oh, sorry, I'm using 5.3. I guess that feature must be something they added
between 5.2 and 5.3.

If you need to stay with 5.2, I guess you'll have to go with some custom
code to manage it.

--Clay

Clay Helberg
Senior Consultant
TerraXML

We added two new attributes to the AttributeOptions element in 5.3.
Besides readOnly there is also a profiling attribute. The description of
the AttributeOptions element in 5.3 in the DTD is:



dialogHidden %bool_no;
screenHidden %bool_no;
readOnly %bool_no;
profiling %bool_no;
configurationElementList %bool_no;>

David,

It may be worth exploring an upgrade to 5.3 rather than doing a
customization to add a feature that is there in 5.3.

John Dreystadt
Software Development Director
Arbortext - PTC
734-352-2835
-

We'd love to upgrade to 5.3. Unfortunately, our CMS version (Contenta 3.2) only works with Arbortext 5.2. We won't be upgrading to Contenta 4.0 -- which supports Arbortext 5.3 -- until sometime in the future. So, I plan to abandon this idea.
PLB
1-Newbie
1-Newbie
(To:ptc-953926)

David,

we are simply using in the DCF

<attributeoption attribute="xxx" dialoghidden="yes" screenhidden="no"/">

dialogHidden="yes" means the corresponding attribute is never shown in the Modify Attributes dialog so users have no way to modify it unless they hack via the "Edit selection as XML" or a text editor.

screenHidden="no" means it will be visible in the editing windows and they can use the "Insert Link" menu to create cross-references. However, the attribute value is not selectable thus copy and paste will not work. A workaround is to write some ACL code for the copy and hook that function to a menu or toolbar; alternative is to use a trick: first insert a cross-reference and then copy/paste the IDREF of the link rather than the ID of the target...

HTH,

Pascale

"Tout ce qui est impossible resteà accomplir" (Jules Verne)

Yes, I'm familiar with both of those, but neither is what I want. We need the attribute to show up in Modify Attributes (for copy and paste), but not be modifiable. Maybe it doesn't even work that way in 5.3.

If you want an attribute to show up in the Modify Attributes dialog, but you want the field to be read-only, you will probably want to use the modify_tag callback.



From the Help:

modify_tag is called before a Modify Attributes dialog box is opened to modify the attributes of a tag (including Arbortext Editor supplied tags). This allows an application to automatically set certain attributes before the dialog box is displayed or to prevent the dialog box from being displayed (by destroying it).



You can go through the dialog using the 'win' parameter to access the dialog box and look for the attribute name you wish to make read-only. Then you can use the attributes as you wish to make the attribute non-editable.



This sounds like what you want with the user being able to see the attribute, but not directly modify it.



I don't have sample code in front of me, but I could find some if you need more.



Thanks.



- Dave H. 🙂



Dave Helfinstine

-