8 Replies Latest reply on Sep 21, 2016 2:41 PM by bigtom

    CWP value list performance


      I am looking at a way to solve a problem with remote data entry in places that have very poor/slow internet connections. I am thinking that CWP is a great way to do this since the PHP is light weight and there is no need to load all records from a layout or even 25 of them. I do need conditional value lists and there is not a lot of information that I have found on using them in CWP and how costly it may be on the slow connection.

        • 1. Re: CWP value list performance
          Johan Hedman

          I would use either MirrorSync 3 or build a PHP API.



          Quite expensive but works great for just that problem since it is sync´s only data that needs to be synced


          PHP API:

          Will send and receive data quite fast, but it also depends on how much data you need to send back and forward


          It is all up to how much data you can store locally and how much that needs to be transfer for each table

          • 2. Re: CWP value list performance

            I get that. But conditional value lists in CWP?

            • 3. Re: CWP value list performance

              You can query against the value list assigned to a field (which captures conditional cases).



                foreach($layout->getField('yourField')->getValueList() as $yourField) {


              <option value="<?php echo $yourField; ?>"><?php echo $yourField; ?></option>

              <?php } ?>

              • 4. Re: CWP value list performance

                I will expound on my take on CWP which may or not align with Johan's.


                Web servers like to serve FILES. Throwing a database in is great. I use them all the time (FM and SQL dbs). But I keep in mind the premise of FILES...


                1) if what you need from DB server does not change much off load the data to a FILE as an include and provide places for the data that changes: the price of product for example may change, when the name, description and image are not changing for that product


                2) use values that may be in a value list and don't change frequently as FILE(s) that are created and called as includes where this prevents yet another trip to the database: a list of states/provinces and abbreviations that might be used multiple times and does not change, for example


                3) large sets of value should be set in ways that are not  "value lists" in the database AND on the web, as this can be problematic: a pick-list (called with AJAX, perhaps, and/or includes) and filtered to make rendering optimized


                4) conditional value lists on web are likely JavaScript for the fasted, including AJAX if necessary. If the list(s) are not changing and are not large, I may write out the JavaScript as an include FILE (using the database data). The browser is then doing the work, not the database and communication between the Web Server and DB


                5) images should be optimized for web serving, should rarely be pulled on the fly from a database, because they don't change that often. using case/if/switch different images can be swapped conditionally (AJAX helps here if needed)


                6) let the web server app (and/or JavaScript in the browser, even) do the calculations and summaries and scripting as much as possible (yes, it seems like double the work and can be) as this may often prevent trips with the database


                7) do NOT request so many records that browser rendering is slow due to the volume of elements to be rendered. Use more... or continue... or next x.... or something to take the user to the next group of records


                8) use CSS for conditional formatting. different CSS can be called based on the viewport and then you have a Responsive site.


                9) use CSS for changing the "theme" (with preparing the data properly, to do so), the browser does the work: * http://www.csszengarden.com


                10) less is better on the web design, KISS, etc.


                and more... so many ways to optimize for slow connections

                data you can store locally

                as Johan says.



                1 of 1 people found this helpful
                • 5. Re: CWP value list performance

                  Fantastic review, Bev. Thanks.



                  On Sep 21, 2016, at 7:50, beverly <noreply@filemaker.com> wrote


                  CWP value list performance

                  reply from beverly in Discussions - View the full discussion


                  I will expound on my take on CWP which may or not align with Johan's.




                  • 6. Re: CWP value list performance

                    Mike, thanks for the conditional example. If it is in the CWP guide I missed it.


                    Beverly,  thanks for your advice. The idea is that http is more reliable when it comes to spotty connections. Web direct kind of fits in there but you end up with a lot of extra stuff like related record loading for 25 records and I do not need that.


                    Even if the web page sends a request to the DB for a value list it will be less overall transfer. At least that is my understanding.


                    In this case something like a mining operation in the Yukon that has to use a small satellite link to just do data entry, they know it's not a great connection and they understand about waiting but minimizing the wait is the goal.


                    They will need some conditional values based on their location to minimize typed data entry, but the rest is just collecting a few bits of text and a few numbers and sending that off to the DB to create a new record.

                    • 7. Re: CWP value list performance

                      even WebDirect can be optimized.



                      • 8. Re: CWP value list performance

                        Client is happy about WD as the development time is  fast. The cost of connections is ok for them. The limit of 200 connections could be an issue in the future as they grow.


                        The number one complaint I always get about WD is the URL, which as far as I know still cannot be altered to their liking or set as a simple root subdomain of the company for internal use by employees. Playing with forwarding/redirects still wasn't acceptable.


                        Oddly for all the advantages of WD this has been a reason for clients to pass on paying for connections and opt for CWP, which is often more expensive. Not being primarily a web developer I would prefer the use of WD, but not my decision to make.