5 Replies Latest reply on Nov 10, 2017 1:53 PM by rskdbl Branched from an earlier discussion.

    Namespace issues when publishing HTML5 Canvas

    trieutruong Level 1

      Hi, I am developing an HTML/Canvas application with AnimateCC and JS libraries. We had the issue with one namespace value (i.e.: publish with Symbols as 'movie') for publishing in different .fla files. Probably it is what you mentioned on this thread.

       

      The problem was 'movie' namespace is on global scope and it was overridden (or, concatenated) every time the browser finished loading  a new 'movie' into memory, so it causes that the different methods are not being called to the corresponding reference in these sections. The solution is to reset the namespace 'movie' to null whenever you load in a new section.

       

      For example:

      queue.on('fileload', function(event) {

        //Take a deep copy of movie and add it to content var

        var content = $.extend(true, {}, movie);

        // store exported 'movie/lib' namespaces in their section

        _root.sections.namespace = content;

        movie = null; // remove movie for next section

      }

       

      A note with recent update of Animate version 2017.5, Build 16.5.0.100, it seems to be a bug or an intention that the namespace was not exported at all. But you can get it from the global AdobeAn object.

        var keys = Object.keys(AdobeAn.compositions);

        var adobeCompositionId = keys[0];

        var namespace = AdobeAn.compositions[adobeCompositionId].getLibrary();

        console.log('AdobeAn namespace: ', namespace);

       

      Hope it helps.

       

      Cheers

        • 1. Re: Namespace issues when publishing HTML5 Canvas
          Colin Holgate MVP & Adobe Community Professional

          I feel sure this is going to be a different issue, so I will branch it out into its own topic, titled "Namespace issues when publishing HTML5 Canvas".

           

          If I'm wrong, and it turns out to be exactly the same issue, feel free to laugh at me!

          • 2. Re: Namespace issues when publishing HTML5 Canvas
            ClayUUID Adobe Community Professional

            This is another reason to just use iframes. New page? Clear the iframe. All globals automatically wiped.

            • 3. Re: Namespace issues when publishing HTML5 Canvas
              rskdbl Level 1

              This is a real problem for my team, and does not seem to be fixed in Animate CC 2018.  To articulate the symptom we see, if you look at the end of the published js file, we expect to see something like this:

               

              })(assets_ui_components_MyComponent = assets_ui_components_MyComponent||{}, images = images||{}, createjs = createjs||{}, ss = ss||{}, AdobeAn = AdobeAn||{});
              var assets_ui_components_MyComponent, images, createjs, ss, AdobeAn;

               

              When publishing with 16.5.1 (2017.5) and 18 (2018), this is not present.

              • 4. Re: Namespace issues when publishing HTML5 Canvas
                ClayUUID Adobe Community Professional

                The code you posted is just declaring a bunch of variables. What is the actual problem you're having?

                • 5. Re: Namespace issues when publishing HTML5 Canvas
                  rskdbl Level 1

                  I realize that's not a very good code sample -- it's just a quick indicator of what exists, or doesn't, depending on whether you have a version less than 16.5 or not.  In the context of the rest of the js file, it's not just declaring variables.  In the first line I pasted, the effect is that it specifies the objects in which to create all of the symbol definitions.  This is the mechanism we've assumed for defining assets in different namespaces, and one we've written logic around.

                   

                  With later versions of Animate, I can see that the namespace management all happens in javascript embedded in the published HTML, instead of right in the js file.  So, I retract the implication that this is a bug; but it does appear that way when the js artifact is all we're looking at. I don't know why Adobe changed this mechanism, esp. without the option to control the behavior, for backwards compatibility.  But, I think we've figured out how to adjust code on our end to be compatible with either format.