(How) can TLF recognize custom attributes/format/data?

The FlowElement class, which is the base class for all elements that make up a TextFlow in TLF, has the ability to store 'custom' data in at least three places:

1. The 'id' property.  The 'id' property is a simple string property on all FlowElement descendents.  You can set it directly on the flow elements or by using the ApplyElementIDOperation through the EditManager of the TextFlow containing the element.  There are some methods on TextFlow for locating elements by their ID (recursive iteration over the child elements).

2. The 'stylename' property.  The 'stylename' property can be utilized to implement named styles for text formats, etc., possibly in conjunction with a class that implements IFormatResolver.  Although it's intended for that type of behavior, it could be used for other purposes.  The TextFlow class has some utility methods to find elements by stylename, etc., so it can be a useful way to attach a 'category' or other designation to certain flow elements that you would like to locate as a group or things along those lines.  Similarly to the 'id' property, 'stylename' can be set directly on flow elements or via the ApplyElementStyleNameOperation.

3. User styles.  Every flow element has the capability to store key/value pair user data via getStyle()/setStyle() methods.  There is also a corresponding operation called ApplyElementUserStyleOperation for user styles.  This is the most flexible way to add additional data to flow elements.  You can put almost anything you like in here.

See ASDoc API Reference for the FlowElement class here:

http://help.adobe.com/en_US/FlashPlatform/beta/reference/actionscript/3/flashx/textLayout/elements/FlowElement.html

There are some notes (outdated, but still somewhat useful) from back when these capabilities were added to TLF in this blog post:

http://blogs.adobe.com/tlf/2009/02/tlf-api-changes-in-build-370-1.html

Keep in mind that if you set id/stylename/userstyles on a flow element directly (without using an operation via the edit manager), that causes a model change to be dispatched up through the TextFlow, which causes 'damage'.  This is not a big deal, but you would need to call compose/update methods on the flow composer manually to recompose the TextFlow after the 'model' changes.

One other thing to keep in mind is that if you are using an edit manager that has an undo manager assigned, any changes that are performed via operations are automatically undoable/redoable.  You can also avoid some of the headache that will result if you try to modify the flow elements directly, as mentioned in the previous paragraph.  The edit manager will automatically trigger composition after an operation is performed.

And another thing is inheritance.  Certain styles and properties are inherited down the text flow child tree.  I believe that includes user styles.  If you decide to use any of these methods for storing custom data, you'll probably want to understand how the inheritance is going to affect what you're trying to implement before you go too far.  I don't have a good enough grasp on inheritance rules to give you an understandable explanation.

Hope this helps.  My info may not be 100% accurate, but this is what things look like for custom data from my point of view.

Good luck,

Brent