TLF Modifications/Getting Involved

["Compton, Tony" <an...@hp.com>]

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

Re: TLF Modifications/Getting Involved

[jude <fl...@gmail.com>]

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
<an...@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
>

Re: TLF Modifications/Getting Involved

[OmPrakash Muppirala <bi...@gmail.com>]

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 <er...@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
> <an...@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
>

Re: TLF Modifications/Getting Involved

[Erik de Bruin <er...@ixsoftware.nl>]

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
<an...@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

Re: TLF Modifications/Getting Involved

[Jagan Langa Sami Durai <ja...@sybrant.com>]

Hi all,

IMHO. There are no much contributions to TLF only because of its closed
nature. I also used TLF in my past projects. I felt very hard to modify the
existing behavior, just because most of the classes are marked final,
private, Excluded, internal, marked with custom namespace.

I really welcomes Tony's interest. If we make the private/custom namespace
methods to protected or public, we can see a lot of
improvements/involvements in TLF also.

+++1 for Tony's proposal.


On Sat, Jun 1, 2013 at 5:05 AM, Justin Mclean <ju...@classsoftware.com>wrote:

> Hi,
>
> > 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.
>
> I've reopened the JIRA issues. Are there any other classes other than
> these?
>
> public final class TextFlow
> public final class ParagraphElement
> public final class LinkElement
>
> > 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.)
>
> All sound like good ideas to me.
>
> Thanks,
> Justin




-- 
*
Regards,
S. Jagan  Langa*

Re: TLF Modifications/Getting Involved

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> 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.

I've reopened the JIRA issues. Are there any other classes other than these?

public final class TextFlow
public final class ParagraphElement
public final class LinkElement

> 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.)

All sound like good ideas to me.

Thanks,
Justin

Re: TLF Modifications/Getting Involved

[Alex Harui <ah...@adobe.com>]

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" <an...@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