Tony, This is very cool. We seem to lack a contributor that knows TLF, so you if you can help, that would be awesome.
As Alex indicated, create a JIRA issue for each of your suggested changes/enhancements, describe in them the thing you're trying to solve and attach a patch to it that has the code needed to solve it. The process is described (to a point, we'd love to hear feedback from a new contributor like yourself) here: [1]. I'd love to work with you on this, thanks for offering. EdB 1: http://flex.apache.org/community-getinvolved.html On Fri, May 31, 2013 at 4:36 PM, 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 -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
