RichEditableText: export().equals() and HTML export

Question

1. How can I find out that two richEditableText.export() are equal?
At least the order of the attributes in the TextFlow element is random which means that exported strings cannot be compared directly. Take for example the trunk.mxml from http://bugs.adobe.com/jira/browse/SDK-21836 and compile+run it several times and you see the different order of attributes. Is there a utility method somewhere to compare two exports? (BTW releasing the source of TLF would ease these kind of bug hunting...)
I know how to use richEditableText.textFlow.generation but this only indicates changes in the current component.
2. Is supporting html import/export on the roadmap?
(This question got burried in the information stream... http://forums.adobe.com/message/2042067#2042067)
Gordon Smith: TLF's TextFilter class supports importers and exporters for HTML_FORMAT, but I haven't tried them and don't know how robust they are.
I think the HTML export in TLF is not yet stable. The thing is that once
it is stable there is pretty much no way to insert the import
functionality into RichEditableText without rewriting most of the
component. In my opinion, it should be either integrated into
RichEditableText even at this early stage or RichEditableText should be
refactored to allow extending it in an easier way.
Thanks for any hints,
Marc

Answer 1

Hi Abhishek,
Nice conversation I do not expect that TLF covers the full HTML standard. After all, browsers are too good when it comes to HTML rendering...
with varying degrees of fidelity.
I remember reading in the TLF forum, that HTML import/export was experimental. That's why I wrote that HTML is not ready for prime time. Also your comment shows that HTML is a poor choice from a Flex perspective. Unfortunately, it's unclear what varying degrees of fidelity really means as I'm not aware of any precise documentation or code.
Concerning your idea about passing around a (mutable) instance of TextFlow, I'm not a great fan. The power of markup is besides others, that it is a comparable description of content and format. So I definitely prefer an equal function. If this function doesn't make it into the Flex 4 release, I  reluctantly add to each TLF markup a dirty flag which is based on TextFlow.generation.
As mentioned before, I prefer TLF could export all content and formatting into HTML compliant format. There are many reasons why HTML is a huge benefit over any new, widely undocumented format (this is not specific to TLF or FXG). A few reasons that come to my mind:
- Server side: Apache Lucene has a battle-proof extractor. With TLF or FXG, I had to write and configure my own.
- Server side: Extract and modify links in content. This is obviously very easy with HTML as there are age-old libs available.
- Flash Player: Compare two TLF markups. There might be also no actionscript lib for HTML available. But I'd happily start a project for HTML but not for a new format without underlining code and thorough doc.
- HTTP communication: what's the mime type of TLF or FXG?
- Every developer knows HTML, TLF/FXG must be learned. I regard this learning as a high barrier as TLF does not seem to be a big step forward compared to HTML.
Note that I don't prefer HTML because it is an "open standard". It's because the whole world knows HTML and that brings a much higher engineering efficiency (and that's maybe due to the open standard). If not all information of TLF can be export HTML, it's a pity but just document it.
Looking forward to your thoughts/comments,
Marc
abhishek.g wrote: Hi Marc,
Thanks for your reply.
TLF supports many different markup formats (TLF, FXG, Plain text, HTML) with varying degrees of fidelity. It would simply not do to compare HTML because there isn't a 1:1 correspondence between TLF and HTML capabilities. From that perspective, TLF format would be your best bet though I realize there is the problem of inconsistent attribute order.
Perhaps your scenario is better addressed by having utilities to compare TextFlow instances rather than comparing corresponding markup (this needs additional thought).
As for HTML import/export, it is obviously be beyond TLF's scope to implement the full HTML standard. The current implementation is loosely based on the HTML capabilities of flash.text.TextField (see htmlText property), which itself is a small subset of the standard, and deviates from it in some ways. When you say HTML support is not ready for prime time, are you referring to this limited scope, or have you encountered specific bugs in the implementation? If the former, I'd like to know what your expectations are. If the latter, please report them.
Thanks
Abhishek
(Adobe Systems Inc.)
This message was sent to: faindu
To post a reply to the thread message, either reply to this email or visit the message page:
http://forums.adobe.com/message/2059470#2059470
--end--
mail transfer stalled...