4 Replies Latest reply on Jan 24, 2013 1:16 PM by Malcolm

    Layout design frustration




      I've been having a one man brainstorming session for several months now and I'm down to the wire and could use some fresh ideas if any are to be had.


      I work for a magazine publisher. I develop custom solutions for my employer and I'm working on an upgraded version of a CRM solution with Sales Order module to create insertion contracts.


      We sell ad space across a few media now, Print, Online (web and email), Digital Enhancements (digital editions of our print magazines with items like links, videos, etc..


      Historically, our contracts have been separate for each media because they don't always contain the same columns of data as a rule. with this new CRM, I've been asked to see if I can bring all the media to one contract for ease of presentation and ability to sell as a package type deal.


      We could have up to 3 or 4 different insertion (ad) grids on a contract. I've mocked up what we currently use and I'm perplexed on how to impliment a similiar model using layouts using FMP 12.


      THE ad/order detail is stored in one table in CRM, classified by a type (Print,Online,Digital,Event) and I've been racking my brain trying to determine the best approach to designing a contract that won't require a page for each insertion grid type. So far, I've come up with 3 portals filtered by media type, that would display the detail. Sales staff however, in the older web based system they use, can choose to hide or display columns of data as needed for the contract and is a feature they feel very much needed in the new CRM's contract design functionality. the system is building web pages on the fly and it can to some degree, add print digital ad grds as needed to contract layout by building tables in the HTML code to display the ad lines.


      The attached mock up shows an example of what a contract may look like when more than one media type ad is sold. we could opt top move this area to the last page as an "attached schedule".


      My goal here would be to design a layout that that won't require a seperate page for each insertion grid type. Often times, 3 grids could physically fit one one page, rarely, would it break onto two pages.


      Any ideas by some layout pros, plug-ins or other advice, ideas or approaches would be greatly appreciated.


      thank you,


      David Roth

        • 1. Re: Layout design frustration

          David -


          I'm not 100% sure, but I think you're asking how to design a layout that will print a page like the one you have. It also seems you want the users to be able to add / omit columns from the various tables involved.


          Assuming that's correct, one approach you could take is to construct the report as an HTML document (just like the existing web-based tool does). You can then display it in a web viewer, export it to the desktop, etc. Such documents are pretty versatile and even print reasonably well from Excel.





          1 of 1 people found this helpful
          • 2. Re: Layout design frustration



            Thank you for your feedback.   Yes, I want to replicate the mockup as best I can.


            I'm familiar and fairly knowledgeable with both HTML and FM scripting but it seems a very tedious task indeed to make this happen by pure coding, generating HTML code manually inside filemaker then exporting it as HTML document.


            Could you perhaps share an approach you may take, or provide any advise or suggestions on plugin's that may take layouts and convert them to HTML to some degree?


            thanks again for looking at this.



            1 of 1 people found this helpful
            • 3. Re: Layout design frustration

              David -


              Well, in my case, I take the tedious approach.    


              Having done it many times, I have a library of scripts I use. So I do a lot of copy-and-paste. But basically, I build the HTML from the top down, using a series of sub-scripts to build the table rows. Where needed, I store chunks of HTML (like, for example, inline tags) in variables and just insert them into the document as needed.


              One approach you can take that will make the code more transportable is to store the field names you want (fully-qualified, with table names) in a variable and then use Evaluate to grab the values as you go. (You can use GetNthRecord to avoid switching contexts, which will speed things up and avoid screen flicker.) That way, you can use a single script to extract the values that belong in the table by just looping over the variable that contains the field names and sticking a </tr> tag at the end of the row when you're done. This is especially useful if you're not too concerned about inserting too many inline tags (although you can insert them in a second, parallel variable if you want).


              Another idea would be to use List ( ) to grab the values from each identified field, then loop over those as you move down the table. That requires more code, but is a little easier to understand.


              There aren't any plugins I'm aware of that will parse a layout into HTML code. (Someone else might know of something, because there are a lot of plugins out there.) The closest you might try would be to export the records as an HTML table and then suck that into a field. That might work okay if you're not too concerned about formatting (remember, in cases like this, you probably won't be able to use an embedded or separate stylesheet; you'll most likely need to use embedded styles).