Tony, I just want to echo Erik's sentiments on this. As you can see, there has not been much activity in the TLF library after the donation to Apache. Whatever work you can do to improve it and bring more attention to it, that would be great. I will be glad to help you as well.
Thanks, Om On Fri, May 31, 2013 at 9:34 AM, Erik de Bruin <e...@ixsoftware.nl> wrote: > 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 >
