5 Replies Latest reply on Jun 23, 2009 6:51 AM by Marc Speck

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

    Marc Speck

      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

        • 1. Re: RichEditableText: export().equals() and HTML export
          Marc Speck Level 1

          To answer my own 2. question: Create myOwnTextFlowFromHtml and set richEditableText.content=myOwnTextFlowFromHtml

          covers HTML import well enough.

          • 2. Re: RichEditableText: export().equals() and HTML export
            Abhishek.G Level 4

            Hi Marc,

             

            Regarding the first question, could you tell me what your use case is? I am also interested if that use case requires the following two text flows to be considered equal:

             

            <TextFlow>

                <p fontSize="14">

                    <span>Hello</span>

                </p>

            </TextFlow>     

             

            <TextFlow>

                <p>

                    <span fontSize="14">Hello</span>

                </p>

            </TextFlow> 

             

            Thanks,

            Abhishek

            (Adobe Systems Inc.)

            • 3. Re: RichEditableText: export().equals() and HTML export
              Marc Speck Level 1

              Hi Abhishek,

               

              Some controller in an app get several textFlows and they need to save

              any changes. Those textFlows come from unkown modules, the only contract

              is that it needs to be a textFlow. Hence, I need to compare the textFlow

              that was injected into the module to the newly fetched textFlow from the

              module. Your use case is exactly what I'm looking for.

               

              In fact, I'd prefer to handle HTML instead of textFlow as the textFlow

              format is not a standard, it's code is not open source and does not have

              any helper functions such as equals(). Unfortunately, the HTML

              import/export of TLF is not ready for prime time.

               

              Maybe those helper functions would fit into spark.utils.TextFlowUtil ?

              Though I don't really care where they are.

              Marc

              • 4. Re: RichEditableText: export().equals() and HTML export
                Abhishek.G Level 4

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

                • 5. Re: RichEditableText: export().equals() and HTML export
                  Marc Speck Level 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...