7 Replies Latest reply on Dec 29, 2016 7:01 AM by ryan.thompson

    Container fields in a web viewer best practice

    DavidZakary

      Looking to see if anyone has come up with a best-practice for putting container field-based images into a web viewer.

       

      Background... this database will likely be local computer-based only. No Server is going to be involved. The system is storing images which are eventually displayed in a web viewer. I'm working with about 20 images at the moment for development. The container data is stored externally. Each container image is anywhere from 200 kb to 1.8 mb.

       

      The system for displaying the images is a jquery lightbox. Lots of CSS involved. The HTML image block is built dynamically, based on searching and sorting. It is then inserted into the wrapper HTML, Javascript and CSS code.

       

      For the images being inserted into the code, I've tried two methods.

       

      First method - hard coding. Don't like that method as it'd be too easy to break.

       

      Second method - when an image is imported I store the base64 string. In the web viewer I use "data:image/jpg;base64," in the img src tag to decode the base64 string. This works relatively well and I think will be less fragile.

       

      The probelm with the second method is speed. When I generate the HTML for the 20 images it takes around 1.7 seconds. That's OK. However the rendering in the webviewer takes about 8-10 seconds. As more images get added to the database its only going to get worse.

       

      Wondering what others are doing and if you've come up with a system you're happy with.

       

      Dave Zakary

        • 1. Re: Container fields in a web viewer best practice
          DavidZakary

          Third option - take the original image, create a second container field that creates a much smaller thumbnail and then use that for display in the lightbox. Encode the thumbnail and things are much faster.

          • 2. Re: Container fields in a web viewer best practice
            steve_ssh

            Hello David,

             

            Here is an additional thought:

             

            In addition to using the thumbnail approach, I wonder this might also benefit from a hybrid approach where, as you dynamically build the HTML, you use the VerifyContainer function to determine whether or not you still have a correct file path to the externally stored image?

             

               If VerifiyContainer( thumbnail_container_field ) returns True, you could set the image src to the appropriate calculated/stored file path.

             

               If VerifiyContainer( thumbnail_container_field ) returns False, you could fall back to the stored base64 data of the encoded thumbnail.

             

            I really could not say whether the extra complexity that this would add would be worth any savings in overhead --  I wouldn't be surprised if, by using the thumbnail approach, you already have the problem solved.

             

            Very best,

             

            -steve

            • 3. Re: Container fields in a web viewer best practice
              steve_ssh

              p.s.

               

              It just occurred to me that using VerifyContainer may very well have more overhead than would be desireable, since it might be doing something like performing a hash on the externally stored data.

               

              Assuming that this idea has any practical use, it might be better to use a simple container attribute that returns a valid value if and only if the external data is still at its path.

               

              Perhaps filesize or filename?

               

              Apologies for not thinking it this far through earlier,

               

              -steve

              • 4. Re: Container fields in a web viewer best practice
                Mike Duncan

                It's possible that you might be able to automate getting a smaller thumbnail graphic to store with a little creative scripting. Then you don't necessarilly need to store the base64 but could be generated on the fly with calculations, but might be faster with stored text.

                 

                I imagine the generated html with arbitrarily large images as base64 could well be inefficient and actually increase the size of the page to be displayed, so I think your plan of storing thumbnails is probably a good one.

                • 5. Re: Container fields in a web viewer best practice
                  keywords

                  Forgive me if I'm on the wrong track here, but with the new ways FM handles containers in FM12/13, isn't use of a web viewer unnecessary? And also storing a thumbnail as well as a larger version of the same image? FM will generate whatever thumbnail is required for a given layout each time it is called for. If you haven't looked into this I suggest you do so.

                  • 6. Re: Container fields in a web viewer best practice
                    jormond

                    Having seen what he is using it for WebViewer is the best way to go. DZ is actually displaying multiple photos in a sort of collage, that is dynamic. It's actually very cool.

                    • 7. Re: Container fields in a web viewer best practice
                      ryan.thompson

                      Hello,

                      Of course I am very late to this party, and have the advantage of the latest and greatest version of Filemaker. But in case anyone is like me and is just now trying to do something similar to the OP:

                       

                      I found that, perhaps somewhat surprisingly, you can put GetThumbnail( ) inside FM's native Base64( sourceField ).. mine looks like this: Base64Encode ( GetThumbnail (  TableName::ContainerField ; 100 ; 100  ) ).. pretty sweet!