I might have run into the same issues with List numbering. I had to do the same types of work around to modify anything because all of the classes were internal or final. I don't know if I solved the issue you were mentioning. If you describe it in more detail I can see if it's the same and share what I have.
On Fri, May 31, 2013 at 9:36 AM, Compton, Tony <anthony.ste.comp...@hp.com>wrote: > 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 >
