Skip to main content
leybniz
leybniz
Participating Frequently
October 12, 2009
Answered

public final class TextFlow

  • October 12, 2009
  • 2 replies
  • 1870 views

Does anybody inhere know the well grounded and objective reason why TextFlow class was marked as final?

This flow doesn't sounds to me like true extensible, they are promoting TLF as easy to extend framework

public finalclass TextFlow

public finalclass ParagraphElement
public finalclass LinkElement

??? nevertheless TLF is OpenSource, but why in a world they do that out of the box?

This topic has been closed for replies.
Correct answer rdermer

Alexander,

For your particular use case you may want to check out the inlineGraphicResolver that was recently added to the Configuration class.  I think this does what you want for your particular use case.

The general problem of enabling subclassing and extending the flowelements is a difficult one - what does it mean in the context of import, editing and cut/copy/paste between TextFlows?  Should/can we generalize the composer to support new custom composition features?  At the same time memory use and composition performance are huge issues.  Its a substantial set of collobarating features and one that's not easily specced or tested.

TextFlow is a simpler case than all the flow elements - I'll grant you that.

Hope that helps,

Richard

2 replies

leybniz
leybnizAuthor
Participating Frequently
October 13, 2009

Anybody willing to vote for removing final from TextFlow are welcome:

https://bugs.adobe.com/jira/browse/SDK-23668

I'm capable of doing that myself, I mean removing "final" from the class, BUT this way I'll have to ship my own version of

textLayout_4.0.0.10485.swz, which will not be signed by Adobe, and will not be cached by FP 10+

R
Adobe Employee
rdermerCorrect answer
Adobe Employee
October 19, 2009

Alexander,

For your particular use case you may want to check out the inlineGraphicResolver that was recently added to the Configuration class.  I think this does what you want for your particular use case.

The general problem of enabling subclassing and extending the flowelements is a difficult one - what does it mean in the context of import, editing and cut/copy/paste between TextFlows?  Should/can we generalize the composer to support new custom composition features?  At the same time memory use and composition performance are huge issues.  Its a substantial set of collobarating features and one that's not easily specced or tested.

TextFlow is a simpler case than all the flow elements - I'll grant you that.

Hope that helps,

Richard

leybniz
leybnizAuthor
Participating Frequently
October 19, 2009

Thank you Richard!

I see your point, well ok let it be as it is now. I've come out having TextFlowFactory class, for me it's a more elegant solution

for a present TLF conditions. And I'm instantiating all my TextFlow instances via .newInstance() method only, inside factory I have static instances list, which helps me to track them and listen for all the buzz coming out of them

Yeah, didn't know about that Configuration thing, thanks for the hint,

inlineGraphicResolver - is a good Idea, but again, requires some efforts to maintain setting of that callback onto Configuration and pass it to each TextFlow instance etc. I think I'll inject that Configuration feature to my factory.

Anyway having TextFlow non final is awesome! Thanks a ton

R
Adobe Employee
robin_briggs
Adobe Employee
October 12, 2009

What is it you are trying to do that requires deriving from TextFlow? Because TLF is dynamically creating and deleting flow elements during editing, providing a system that supports deriving flow elements is very tricky. But we have found that most reasons folks want to derive can be solved in other ways -- often by applying user attributes. What is it you are trying to do?

Thanks,

- robin

leybniz
leybnizAuthor
Participating Frequently
October 13, 2009

Thanks Robin,

I wanna put a global control over pending inlineGraphics elemets, say whenever I need TextFlow to render inlineGraphics I would like to resolve them from one centralized spot. And if I'll be able to subclass TextFlow, I'll put that functionality into the TextFlow descendant and use it over the system to build own components having myTextFlow incapsulated instead of standard one.

Generally speaking I wanna put repetitive code used to handle InlineGraphics in one class instead of doing that in all of them via copy-paste. Just for you to visualize for yourself, say you have 3 different custom classes incapsulated TextFlow, and you have 25 instances of that classes in the display list,

the text flow of each of them contains <img src="[class MyImageClassToBeFetchedLater]" />, so when they are rendered I have no Idea where to get that MyImageClassToBeFetchedLater, but once I got it I wanna scan all such img tags from all instances(25) of all classes(3) and put the correct source inplace, you see what I mean?

Any thoughts on how to implement that Idea without extending TextFlow are really Welcome

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices