flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: TLF Modifications/Getting Involved
Date Fri, 31 May 2013 16:22:21 GMT
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.compton@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
>HP Exstream

View raw message