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 <jus...@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*
