Sounds reasonable to me. Create a JIRA issue with a patch for the changes you want and we'll try to get a committer to review and commit it.
On 5/31/13 7: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
