There is a way to hide elements from the Structure View (one such method is offered by the free AXCM plug-in). What happens when you use AXCM (or other methods to hide elements) is that the elements get wrapped into hidden content. This might make the structure view less complex for your authors, but has a number of disadvantages and dangers.
1. The structure is normally invalidated, as the helper elements are usually required.
2. Accidentally deleting hidden content may make the invalidation permanent and render your documents useless.
It is NOT good practice to hide elements from authors in the structure view. Instead, you should either teach authors about the structure, or let them work in the Author View while adding sufficiently clear formatting to show them the underlying structure. In some cases, it might be better to create an authoring structure which is automatically transformed into the required full structure using an XSLT or other processing step. I have created a couple of such environments and they work fine. It just depends on the difference between the structure required for further processing and the structure that would be optimal for your authors (which in turn depends on the level at which your authors are experienced in working with structured content).
I hope this helps you solve your problem without having to tweak the structure view.
And, adding to what Jang said, there is no way to simply hide the element symbols. The Structure View will always follow exactly the content in the document. To hide something from the Structure View, you would have to hide it in the document as well. The only native feature for doing this is conditional text, but I suspect that is not what you are looking for.
Thanks for your answers.
I could not test the plug-in yet (unfortunately it is sometimes not so easy to install something in a completely safe network :-) ). However, if I understand Jang correctly, the plug-in will hide contents such as conditional texts. Therefore it will cause difficulties with the XML validation.
Regarding Jang's concerns about the author: in my particular case I want to hide something which is generated automatically like a header and not to be edited (my posting from yesterday concerned the non-edit option – which is working fine :-) ). However, this header has many elements and will result in a loss of the overview in the structure view.
I was hoping I could gain access to the structure view via the script and thus possibly getting an influence possibility there.
In principle this would mean that I had to create a nearly similar display on my own (simple tree element with some click events to jump to the contents). Thus a control of what gets in there would be possible.
There is no reason a header with lots of elements should lead to a loss of overview in Structure View. If you have a well-defined structure, all automatically generated elements will be inside a single element, possibly named <header> or <prolog> or whatever you choose it to be. That header can easily be collapsed in Structure View, so that the author does not get sidetracked when trying to find the editable portion of your content.
Another possible solution depends on the way your content is being published. If you push it out to pure XML before it gets rendered into the final output, you can use XSLT to add the automatically generated into after the editing is done.
In general, there are various ways to get stuff like this done. If you need help in scripting a solution, drop me an e-mail and I will see what I can do for you. I have created quite a large number of dedicated workflows based in Structured FrameMaker.
thank you for your answer.
Unfortunately, the relatively simple source XML is inflated with additional elements because of the requirements of FM (eg for getting certain content in table cells). This will be done with an XSLT pre process.
When the author is finished with editing the simple XML will created with an post XSLT prozess.
What I meant with header are mostly those FM constructs that have nothing to do with the actual content.
I understand the problem. Having XSLT at input and output, there might still be other options to handle this (getting around the inflated FM structure). I have created an API documentation systematic that allows the author to create a structure in FM which is then translated into a tabular rendering on web pages. I don't want to use the FM table as it would kill my productivity, but I do need the table structure in the output to increase user-friendliness in delivering the content to the user.
I am just trying to think out of the box here, but of course I do not know details of your content. It might or might not apply in your case. I hope you will get to where you want to be.
While, as has been discussed already, you cannot hide elements in the Structure View when they are shown in the document window, you can collapse them so that substructure that is generated by XSLT is not shown.
You might also consider naming conventions that distinguish such automatically created elements from user-created elements. For example, if the XSLT-generated elements all have names that start with ZInternalUseOnly, users should understand that they should avoid manually manipulating them. The initial 'Z' will move the names of these elements to the bottom of an alphabetical list (such as in the Element Catalog window).
Thanks for your answers. They helped me all.
Regarding the response from Lynne "you can collapse them so that substructure that is generated by XSLT is not shown":
Even at the risk that you will kill me because of my question regarding the scripting influence to the structure view :-) ... Is there a way to collapse something in the structure view by scripting?
Thank you Russ. Works perfect. So I can at least create some more overview in the structure view. Very simple actually.
But I'm also a little surprised that I can also set the value. According to the description I would assume that I can only read the status. But why not simply try what happens when you change the value :-).
ElementIsCollapsed int Returns True if the element is collapsed in Structure View. Returns False otherwise.
In the FDK documentation, all read-only properties are marked with a special symbol. That convention was not carried over to the ES documentation, which is an unfortunate omission. For this and other reasons, many ES developers find that they have to use the FDK documentation as well to get things figured out. That includes me. If you don't have the FDK Programmer's Reference, I'd recommend that you download it.