3 Replies Latest reply on Jan 16, 2014 6:30 AM by Dhaupin

    Why not add a custom URL variable to publishing options?

    ARCWuLF

      This program is great to animate with, but EXTREMELY FREAKIN' FRUSTRATING to implement. A lot of this could be alleviated if the "publish" options let me specify an URL at the host level (or better yet an FTP protocol that I could upload my work with, while I'm dreaming).  This way, the code could reference the folder that I put it in on my existing website and save me the step of editing the javascript and declaring a variable and redirecting every asset to it EVERY SINGLE TIME I UPDATE the stupid thing, because in case you haven't been able to tell from MY ANGRY CAPITAL LETTERS I have been having issues with getting my Edge animations to display, and when they do they are HORRIBLY BROKEN (they work in the previews and no where else), and there doesn't seem to be a lot of support here for the problems I've been having.

        • 1. Re: Why not add a custom URL variable to publishing options?
          Dhaupin Level 1

          Unless im missing some setting somewhere, this is a major oversight on adobes part. There should be a "push URL" and "preview location" settings for projects. Push url would be the root for your medias location in the site, say something like "//www.yoursite.com/media/project1/" (notice double slash, no httpxxx) then the preview location would be using the same folder structure in something local like "C:\Users\YourAccount\Documents\edge\project1", or something on a dev server like "http://dev.yoursite.com/test/edge/project1". The difference would be the "preview location" variable would be used during construction (to preview) whereas the "push URL" variable would replace it in scripts upon publishing the media.

           

          Also to prevent source conflicts, and for speed, there should be CDN options for the edge library + use googles CDN for the extra jquery. No sense uploading multiple instances of libraries for every media project...this also doesnt take advantage of common client caching. Also prevent breaking sites and redundant calls, allow use of legacy jQuery.

           

          As found on http://www.adobe.com/devnet-docs/edgeanimate/api/current/index.html#CDN-Hosting here is the Edge library:

          <script type="text/javascript" charset="utf-8" src="http://download.adobe.com/pub/adobe/edge/animate/2.0.0/edge.2.0.0.min.js"></script>
          

           

          As found on https://developers.google.com/speed/libraries/ here is the jQuery library:

          <script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
          

           

          What would this prevent? Lots of things...but mostly manual fixes. For example lets say you have a media object/banner that resides on every page on the site. Under current "/" root mantra, it would function only on the homepage. As soon as you traverse to a new URL, it appends the media calls after that url. So it ends up looking for "https://www.yoursite.com/banannas-for-sale/project1" instead of "https://www.yoursite.com/media/project1/"

           

          Hopefully someone at Adobe actually reads this and answers the hundreds of folks who have ran into this issue. Thanks.

          • 2. Re: Why not add a custom URL variable to publishing options?
            elainecc Adobe Employee

            Hi, ARCWuLF and Dhaupin-

             

            We specifically stepped away from file and server management because we expected our users to use other products in conjunction with Animate.  For instance, Dreamweaver's file sync is fairly sophisticated and has taken a long time to develop.  Instead, we focused on providing features that would enable people to do what they couldn't already do with Dreamweaver and other tools: animate visually on a timeline.

             

            Regarding the second point that Dauphin makes, we do already provide a CDN feature for our web publish option, and it's on by default.  Go to File > Publish Settings and you'll see this option:

            publish-settings.png

            This selection runs the Edge Animate runtime off of the Adobe CDN (and we get a ton of traffic, so there's a fairly good chance that it's cached somewhere) and runs jQuery off of Google's CDN as suggested.

             

            While you can run the project files as your deployment files, you might want to consider publishing for web instead and using that content instead, as it does minify some of your project files as well.

             

            -Elaine

            1 person found this helpful
            • 3. Re: Why not add a custom URL variable to publishing options?
              Dhaupin Level 1

              Ah wow totally overlooked the CDN, that is awesome! Thanks.

               

              Not sure if you understood the "file management". We arent asking for a new method to upload files or build a site, we are looking for a variable to define a root path in edge media for when its live. How does dreamweaver or other tools mitigate making temporary edit > push variables in the edge jQuery stacks? I dont believe they do at all...that puts the logic of edge publishing full-circle back to manual js edits at a level beyond the common man. We had to manually make a new "rtdir" variable and edit the "im" variables, then manually add them to all paths to get this to work. Seems like native support for that is asking far too much from other tools, especially considering they have no part in "constructing" the files yet have to change them at a somewhat deep level. Also there is a large chance other tools hooking edge variables at this level would cause too many paths to corrupted files.

               

              Considering edge is constructing "im" and has potential to do the same for "rtdir", would it really be that hard to integrate an input box where you type in the push URL path....then that path is overwritten into XXXXX_edge.js and XXXXX_edgePreload.js when its published. The preview dir is already functional as the existing file structure. The issue is it leaves that in a non-specific preview state...example: /myfolder/project1. This breaks every URL its used on as its appending the /myfolder/project1 after any link whatsoever