Hello, everyone. My name is Tony Compton, a developer for HP Exstream, a division of Hewlett-Packard, Inc. I've spent the last year working on a product that relies on Flex and TLF. I'm writing today because I work with TLF almost daily and I would like to help contribute to the project, but before I spend the time making the kinds of changes that I think will make TLF an easier framework to extend and develop using I wanted to make sure that they were welcome changes.
There are a number of things about TLF that make it difficult to extend and otherwise alter its behavior. Please keep in mind that some of the changes I'm about to suggest stem from a personal design philosophy that if I, as a developer, attempt to extend via inheritance or otherwise alter the behavior of an object or class that works and it does not continue to work with my extensions then I am at fault-not the framework. Here are some improvements I would like to make: There are a few classes within TLF that are marked as "final." This creates a unnecessary barrier to extension. One example of this is the InlineGraphicElement class. I would like to extend this class, but I cannot, so in order to add any additional behaviors or features to the class I am forced to do something like extend SubParagraphGroupElementBase (SubParagraphGroupElement is also marked final, which I feel is unnecessary, although I wasn't especially inconvenienced by that). This seems to already by an issue in Apache's Jira (https://issues.apache.org/jira/browse/FLEX-21488) which is closed to be tracked by the Adobe Jira, but it seems the Adobe Jira has already been decommissioned. Perhaps we should open it back up-or maybe I'm missing something. There are many hidden classes sprinkled throughout TLF. Where I encountered particular hindrance is in attempting to extend TextFieldHtmlmporter to handle more advanced HTML pasting. While a the class is not marked final, there are still some areas I feel can be improved. For instance, if I wanted to inherit from TextFieldHtmlImporter and allow it to interpret a custom font-related attribute I can't simply inherit from the hidden FontImporter class and make my changes, then configure the TextFieldHtmlImporter to use my newly created class. I am forced to create a new class that does everything FontImporter does (plus my extra stuff) then create a class that extends TextFieldHtmlImporter and jump through the necessary hoops to make sure that my importer gets used instead of FontImporter (which, on its own is more difficult than I think it needs to be). I would like to see situations like this be more strategy-like pattern wherein I can supply the importer with a FontImporter to use and if I do not it will use the default, but make the default FontImporter publicly visible and therefore extendable. Similarly, I'd like to apply the same notion of using the strategy pattern to TLF's creation of TextLines/TextFlowLines and child TextLines for list numberings. Currently I've been unable to find a way to affect how TLF lays out its list markers. It's been a while since I looked at this problem, but if I recall correctly, somewhere in TLF it's calling a static factory method on a class by name, so there is no way for me to modify the behavior of TLF with regards to how it creates TextLines. It would be nice if there was a configurable property that I could set (that implements ITextFlowLineFactory or something like that) that TLF would then access and use to create TextFlowLines, thereby giving me at least some means of altering its behavior (although, as I said, it's been a while-so there may be some details of the current implementation that I'm not remembering quite right). (This type of customization may need to go in the Configuration class.) To summarize things, I'd like to make the following general categories of changes to TLF: Remove many final classes, giving developers the ability to extend them. Attempt to make many hidden classes publicly visible so that they can be extended and use in the type of configuration described below. Make TLF more configurable, so that in places where TLF would create an instance of a TLF-type class, it instead accesses a user-configured factory for creating that type of class so that developers can inject their extended classes into their text with ease. (Probably in the Configuration class.) I'd be interested in hearing your thoughts on these topics. Hopefully they are well received so that I can begin working on them. Thanks and best wishes, Tony Compton Developer HP Exstream
