Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Is HTMLFlow#setContents() supposed to trigger ContentLoadedHandler#onContentLoaded()?

    With all SmartGWT 3.1 version we tested (last from 2013-01-29) we notice a behavior with HTMLFlow#setContents() that seems to be different than with 3.0.

    The below code causes infinite recursion because HTMLFlow#setContents() triggers ContentLoadedHandler#onContentLoaded() to be invoked again:

    Code:
    // htmlFlow uses ContentsType.FRAGMENT
    htmlFlow.addContentLoadedHandler(this);
    
    public void onContentLoaded(ContentLoadedEvent event) {
      //...some content processing
      htmlFlow.setContents(contents);
    }
    Is this intentional or a regression bug? We worked around the issue by introducing our own "break-infinite-recursion flag" that is evaluated before calling HTMLFlow#setContents().

    #2
    This is actually an intentional change.

    A call to setContents() will cause the contentLoaded handler to fire. The reason for this is that we now support evaluating script embedded within the content passed to setContents(), including <script src=...> tags which require that we asynchronously load the script in question from the server, and so a callback is required to allow developers to have their application recognize when an HTMLFlow has fully applied its content.

    Typically we wouldn't expect you to have a contentLoaded handler which ultimately calls setContent() but we don't know your exact use case. If your app really requires this, you can avoid the infinite loop by setting a flag to indicate that you've already loaded remote content and are now simply calling "setContent" directly with modified content (which it sounds like is what you're already doing).

    Regards
    Isomorphic Software

    Comment


      #3
      Thanks for the explanations. Correct, we're using a flag work-around as you outlined.

      We're loading content into an HTMLFlow fragment type from a shared external resource that is otherwise not used as a fragment (JSP page). Hence, we need to extract content from the full HTML page. This is done at the "//...some content processing" lines in the provided code snippet.

      Unless there are more appropriate options to achieve the same using the flag work-around is fine for us.

      Comment


        #4
        You could always issue an explicit RPCRequest to load the HTML fragment (a simple RPCManager.sendRequest() call or similar, then look at the response data string in the callback) - but your approach should work as well.

        Comment

        Working...
        X