1 2 Previous Next 21 Replies Latest reply on Sep 24, 2012 8:03 AM by psijmons

    When is an FM11 layout *really* converted to a 'real' fmp12 layout?


      Hello all you super-developers (and FMI if you are listenening)!


      I've got some very important questions regarding conversion of layouts to fmp12 and their further development under fmp12. In short the question is:


      Q1. When is a converted FM11 layout a 'real' fmp12 layout and HOW should this be achieved?


      (Note: if you are in a hurry just answer Q3a below!)




      Having converted an FM11 solution to fmp12 there seems to be 4 major alternatives for developing fmp12 layouts:


      1. Leave the layouts as they are in Basic/Classic theme - for ever.
      2. Apply layout themes and/or object styles to the converted layout and its content.
      3. Rebuild the content of each layout from scratch.
      4. Create new fmp12 layouts from scratch.


      4 is not an option (for us), because it would not only be a monumental effort to create the layouts, it would additionally require every script reference to a layout to be corrected - in total around 14000 changes.

      3 is not an option (for us), because we have 1/4 Million layout objects in the solution. We may be able to rebuild certain repetitive standard layouts, but on the whole these are monstrous numbers of objects.


      Thus this discussion focuses on (the if, how, why and when of) the first two options.


      But first a little background info...


      About us/our software (Günther Business Solutions/Advanter)


      This layout issue is extremely important for us, seeing as our database solution, Advanter, has got thousands of layouts*.


      If we need to give them a workover in fmp12, WE ONLY WANT TO DO THIS ONCE! We have to get it exactly right the first time, because, if we flunk it the first time, nobody is gonna pay for the (tens of) thousands of man-hours to do it again.


      Just to make it absolutely clear the proportions we are talking about, here are the options we are looking at:


      ScenarioNumber of Layouts to edit (approx.)
      After conversion to fmp12 (and a little layout tweaking) no further (blanket) workover is required0 * 3936 = 0
      After conversion to fmp12 all layouts get a 'workover' to make them 'real' fmp12 layouts, i.e.'future-safe', e.g. (maybe a new design is applied,...)1 * 3936 = 3936
      The 'workover' turns out to be insufficient/the layouts are not 'real' FileMaker 12 layouts, and a further workover is required (e.g. all buttons need to be recreated)2 * 3936 = 7828
      FileMaker 13 (or 14, or...) appears, maybe with further new layouting requirements, ... and if that happens we shall begin to cry (and I don't just mean shed tears!)3 * 3936 = 11808


      So, maximum 1 workover possible.


      (* Yes, it is a long-living solution with a great deal of functionality, tables, etc. We *are* streamlining the product, but I would request you to keep on topic when replying and not nag about the 'proper' size of a database.)


      About converting to fmp12 and the Basic/Classic theme:


      We can convert FM11 (FP7) files to fmp12.

      Our layouts are converted and LOOK more or less the same as before - thanks to the Basic/Classic theme.

      With a bit of tweaking they also ACT more or less the same as before too (ignoring problems of full-page background printing, etc.)

      However, according to the documentation - and looking under the hood - Basic/Classic ARE NOT 'real' fmp12 layouts.


      For example, looking at their internal XML-structure of layout objects copied to the clipboard:

      • objects in the Classic style have the css attribute: -fm-override-with-classic: true;
      • converted buttons - although their attribute -fm-override-with-classic is changed to false they still retain the old internal structure of FM11 buttons, even when a new layout theme or object styles are applied.



      Questions about Alternative 1: keeping the Basic/Classic theme


      Q2a. Can Layouts retain the Basic/Classic theme - forever?


      Is this an option?

      Anybody planning to stay in "camp classic" permanently?


      Q2b Or is it (or will it be) neccessary to convert Layouts to 'real' fmp12 layouts (alternative theme to Basic/Classic)?


      I am aware, that it is *presently* necessary for IWP layouts to remain in Basic/Classic theme. Although this does not interest us directly - because we do not use IWP - I think it would be interesting to know if this is a permanent state-of-affairs?


      What is the liklihood that support for the Basic/Classic theme will be completely dropped in some future release of FM?


      Any other reasons to convert?


      Q2c. What are the particular advantages/disadvantages of leaving layouts in Basic/Classic theme (for the time being)?


      The main advantages that I see are:


      • it requires minimal effort at the present moment
      • it supports IWP
      • maybe a future version of FileMaker will be able to convert layouts more thoroughly and effortlessly?


      The main disadvantages that I see are:


      • effort required to change
      • no IWP
      • it's not possible to develop you own theme




      Questions about Alternative 2: Applying layout themes and/or object styles


      Q3a. : What needs to be done in order to make a converted FM11 layout a 'real' fmp12 layout?


      • Optionally design your own layout theme
      • Apply the layout theme of your choice
        • I notice that this does not affect the *look* of buttons.
      • Apply object formats from 'real' fmp12 objects (buttons) to objects (buttons) in your layout.
        • I notice that, while this gives a button the same LOOK as a native fmp12 button, it retains the old internal structure. (-> Q3b)
      • and anything else?


      Q3b. Does it (or will it) matter, that buttons retain their antiquated FM11 internal structure?


      I have no idea if this is important, but it is a key issue.


      (For those of you who don't know what this bit is about, I'll post a picture of the XML-Structure in my next post.)


      Q3c. At the end of this process of applying themes and formats, is the layout 100% 'real' fmp12?


      I mean, does the layout differ in any (important) way from an identical layout created in fmp12?


      Q4. Will it be (or might it possibly be, or what are the chances that...) necessary to give the layouts a workover AGAIN when FileMaker 13 arrives?


      Your comments, insiders and/or bets please!




      Q5. So, of the original 4 Alternatives, which is the right way to go?


      Is there a guru out there?




      Thanking you for your help, I would be very grateful for your shared wisdom, experience and knowledge.


      Here's wishing you a useful and profitable discussion for all, and to that end please keep on topic!


      Greetings, as ever, from Hamburg




      P.S. Q6. What is 'real'?

        • 1. Re: When is an FM11 layout *really* converted to a 'real' fmp12 layout?

          Here is a picture of the internal XML structure of buttons. (Click the attachment to see it properly) As you can see, the XML-structure of a converted FM11 button on the right (represented as Xpath to the nodes & attributes) is more complex than a native fmp12 button on the left.


          fmp12 internal button structure.png

          1 of 1 people found this helpful
          • 2. Re: When is an FM11 layout *really* converted to a 'real' fmp12 layout?

            Where did you get the "picture" ?   is it a copy / paste of the XML ?




            > Here is a picture of the internal XML structure of buttons

            • 3. Re: When is an FM11 layout *really* converted to a 'real' fmp12 layout?

              Good question!


              I made an fm11 DB.

              I converted it to fmp 12

              I copied the converted fm11 button onto the clipboard.

              I used my tool "FMCheckMate" (which uses the BaseElements Plugin) to convert the clipboard content into XML and open it in my favourite Text Editor "TextMate".

              I used Text Mate to tidy the XML, so I could read it.

              I used Text Mate to apply an XSLT transformation that I have written, which analyses the structure of any XML file and lists the Xpaths to each and every node and attribute.


              I created a new layout in fmp12 and created a (pretty much) identical button.

              I copied the button and repeated the steps as above.


              I edited the Xpath documents, so that the object groups are easier to see and placed them side by side on the screen.

              I took a screen shot and annotated it in Preview


              I then spent 10 minutes trying to upload it to this website


              (...and before you ask, my FMCheckMate tool is sadly not publicly available. ...yet... ...maybe... ... but that should be another thread...)

              • 4. Re: When is an FM11 layout *really* converted to a 'real' fmp12 layout?

                Mr. Watson -


                I'm not a "real" expert on this, but I did attend a couple of sessions at DevCon where they discussed the new layout engine, so maybe I can help - a little.


                The new layout engine, as I understand it, is based on a layering model. There are basically three layers:


                1) Default

                2) Theme

                3) Local


                The default layer is always based on the Classic theme. (So your observation about converted layouts being "based" on Classic is more or less correct.) If you apply a theme other than Classic, the styling information sits on top of that layer. Finally, if you apply a style to an object, then that becomes the local styling information for that object. Rendering is applied in that order: Default -> Theme -> Local.


                Special cases - like Conditional Formatting and States - are handled after the other layers are rendered.


                When you convert a solution from an earlier release to version 12, all styling information is applied at the local level. That means it sits on top of the stack - and will be rendered after the default and theme layers (if there is a theme layer; since Classic skips the theme layer, there probably won't be one).


                So, what happens when you "apply a theme" to a layout? It permanently removes all local styling and inserts the theme styling at the theme layer (which will replace any theme currently applied). (This is why, as some have noted, your carefully constructed interface from the .fp7 days is completely destroyed.) That will mean you now have an empty local styling layer, but all your theme styles have been set to the appropriate values according to the theme you select. However, while this might make the layout "totally FMP 12", it may not.


                When you have a non-native object - say, a button - on a version 12 layout, its rendering still has to be resolved. Any styles you apply to non-native objects will be applied after those objects are rendered as originally presented. It's like applying a gradient on top of an image in a photo editing program: the original image is still there. Hence, to make the layout fully "FMP 12 native", you would, as I understand it, need to remove all your old buttons and replace them with FMP 12 buttons. (This may apply only to buttons that are created from non-button objects, though; my notes aren't 100% clear, so if I'm wrong, someone please correct me.)


                So, to answer your basic question, leaving your layouts in Classic theme really has a couple of advantages:


                1) Performance. Since there is no actual theme layer to the layout, it's faster to render - assuming your existing layouts aren't too hard on the rendering engine.


                2) Preserving what you have. If you apply a theme, you blow away your existing formatting. (Unless that's what you want.)


                For my part, I haven't done a lot of converting of layouts - but we haven't done much moving to 12 from old solutions, either. Most of my work in 12 has been on new solutions. For those solutions I've converted, I've pretty much stayed in "Camp Classic", as you say.    


                I hope this has been helpful in some small way.



                2 of 2 people found this helpful
                • 5. Re: When is an FM11 layout *really* converted to a 'real' fmp12 layout?

                  Thanks, Mike! this needs to be in the Knowledge Base (if not already).


                  • 6. Re: When is an FM11 layout *really* converted to a 'real' fmp12 layout?

                    Very helpful thank you, Mike! And specifically, you say:


                    Hence, to make the layout fully "FMP 12 native", you would, as I understand it, need to remove all your old buttons and replace them with FMP 12 buttons.


                    Now, IFF this is true, then we have not only nearly 4000 Layouts that need to be themed, but also 30.000 buttons that need to be "fmp12 nativized".


                    AND IFF the only method provided by FMI of "nativizing" these old buttons is for the developer to do it himself - by hand - that is absolutely and by itself a show-stopper to further layout development in fmp12.


                    Let us not fall into the amateur belief, that "nativizing" a SINGLE button by hand is a quick or error free process - it is NOT!


                    The typical steps required for this are:


                    1. Create a native fmp12 button on the layout next to the old button
                    2. Label it - by typing or using copy/paste
                    3. Style the button using the format copying tool, if a button exists with the correct styles (maybe having to switch to another layout to copy the style from a button there) - otherwise set up all the relevant style properties by hand
                    4. Set up the anchors by hand
                    5. Set the tool tip by hand
                    6. Set the script call by hand (that is, choose "Perform Script", select the file, if external, locate and select the correct script) and...
                    7. Type - or prefereably copy and paste - the (sometimes very complex) script parameter by hand
                    8. Set the conditional formatting by hand
                    9. If there are any script-triggers, set these up by hand
                    10. Then, while the two buttons are both visible, visually check that the new button is identical to the old button and compare each property by eye. Correct as necessary.
                    11. Scale & position the new button by hand, so this is in exactly the same place and size as the old button. (I have created my own keyboard shortcuts for scaling in MAC OSX, but in the standard FileMaker there are none and you have to use the buttons in the inspector - and the icons for vertically scaling objects ARE WRONG - they are upside-down and one needs considerably longer to click the correct button)
                    12. Send the new button behind the old button
                    13. And finally delete the old button.


                    And these are only the steps to create the "fmp12 nativized" button. After that you need to - somehow - test that you made no errors.


                    Let's do some sums:


                    I just performed the above on a simple button - in a database that only had one script - and it took me 90 seconds. Maybe as a repetitive task you may get quicker, on the other hand real DBs are more complicated, but maybe you can replace groups of buttons at a time. I'm gonna use a very hopeful ballpark figure of 60 seconds/button (mainly because it makes the maths easy here).


                    So we have:


                    30000 buttons * 1 Minute/button = 30000 Minutes = 500 hours = ~63 8-hour workdays = 1 full-time employee for a quarter of year.


                    Let's hear that once again:


                    It will take ONE FULL-TIME EMPLOYEE - working on no other task than the task of converting buttons to fmp12 native format - A WHOLE QUARTER OF A YEAR - to complete the process.


                    But that is not the whole story, because that is just the time to convert the buttons. We still have to test and correct these changes!


                    So how many errors can we expect?


                    Coincidentally, I had the pleasure yesterday of correcting errors that had creeped into a new custom menu in our software. It was only one menu, with 24 menu items, but as you probably know, Custom Menus cannot be copied and pasted, and have to be laboriously recreated in every file. As we have 32 files in our solution that's 24*32=768 menu items. Thanks to the FileMaker Analysis tool Cross-Check from [x] cross solution I was able to rapidly locate 38 erroneous menu items containing disparate errors scattered across every file. That represents almost exactly a 5% error rate. My colleague who constructed the menus is very concientious and concentrated in his work, and so 5% is probably a lower-than-average error-rate, nevertheless it is a nice round number so we'll use it to predict the errors that we would expect from the manual "nativizing" of the buttons and see waht outcome we get:


                    30.000 buttons * 5% error rate = 1.500 erroneous buttons


                    Let's hear that once again:


                    We can expect to have one thousand five hundred erroneous buttons - any button - on any layout - any error (indeed any number of errors as the 1500 reflects only the number of erroneous buttons) - anywhere in any of the buttons properties


                    With the Custom Menu I could find the errors with Cross-Check relatively quickly, because each menu entry had to be exactly the same. However, with all kinds of different buttons doing all kinds of different things, in all kinds of looks, positions and sizes no easy discovery method is available. Indeed no certain discovery & correction method is available whatsoever, as I can see it.


                    (Even if we DID manage to find & fix the 1500 buttons by hand, we'd still create a further 1500*5%=75 erroneous buttons in the manual fixing process,...!)


                    So, what are we looking at in real costs? maybe up to a half a year development? considerable liklihood of errors being released into customer versions? unquantifiable damage caused by incorrectly manually-converted buttons?


                    In short:


                    • "nativizing" buttons in fmp12 by hand is a huge blockade against converting old layout to use 'real' fmp12 layouts with fmp12 themes.
                    • IT IS NOT A REASONABLE OPTION FOR US and
                    • IT IS NOT A REASONABLE OPTION FOR ANY SERIOUS PROESSIONAL FILEMAKER DEVELOPER with a moderate to substantial database.


                    Thus far this discussion has only considered converted FM11 buttons. Mike mentioned there may be other "non-native objects" that also need to undergo the same treatment.




                    I imagine the effort of developing a function in FileMaker to automatically and perfectly convert converted FM11 buttons to fmp12 native buttons (and other non-native fmp12 objects to native fmp12 objects) is not disproportionately large compared to the time that we and other prominent FileMaker Developers would need to invest to do the job correctly and perfectly by hand.


                    Maybe you would consider developing such a function?

                    Or at least advising us if/when such a function shall be available, so that we - and others -  can avoid unnecessary hand-work and plan a development strategy for our databases?


                    Thanking you again for your interest, attention and advice.


                    Evening greetings from Hamburg, far away



                    • 7. Re: When is an FM11 layout *really* converted to a 'real' fmp12 layout?



                      I think your assumption about the performance (below) may not be accurate. My understanding from DevCon sessions was that if you leave your layouts as is after the conversion, then it will apply all the underlying CSS for the theme PLUS a local top layer to preserve your look & feel - which could lead to performance issues due to all the CSS.


                      "1) Performance. Since there is no actual theme layer to the layout, it's faster to render - assuming your existing layouts aren't too hard on the rendering engine."



                      We are in the same boat as Dr Watson with our internal solution and exploring options, with performance being the main concern. I have another similar thread going which I am looking for an answer to as well, in case anyone here has time to check it:)


                      Looking forward to the results of this post and hopefully FM can jump in to clarify.

                      • 8. Re: When is an FM11 layout *really* converted to a 'real' fmp12 layout?

                        appdev -


                        I think you misunderstood what I was trying to get across. Sorry; I must not have made it clear.


                        If you leave the layout in the Classic theme, as opposed to applying a new theme, then, for example, pasting all your original .fp7 stuff on top, then you may see a performance increase. This is because the Classic theme will not have a theme layer to deal with. If you apply a theme, then layer a bunch of old stuff on top, you're giving the rendering engine one more additional layer to deal with - which, by definition, will be slower.


                        However, if your .fp7 layer - which, by definition, is the local layer - is substantially more complex to render than the FM-provided themes (and many will be), then you may likely see a performance boost by abandoning your old interface and going with a new theme-based one. I get the impression, though, that this is a distasteful option for many (just based on the traffic on this forum).


                        So, you are correct; applying the underlying CSS PLUS the leftover .fp7 elements may end up costing you more than scrapping your old stuff and going with a new interface. But it will definitely be faster to stick with the Classic theme than trying to apply a theme and then paste a bunch of your old .fp7 stuff on top to try to preserve it.


                        In my tests (on very simple layouts, for the most part), I have not seen a significant performance issue with version 12's layout rendering. However, there have been several folks on the forum (and at DevCon) who complained most enthusiastically. So I think experience has been varied, mostly, I think, due to the complexities of their original designs. The presenters I saw repeatedly mentioned not using "old school" methods like layering multiple objects to get a specific look for a button, but rather using a button object with appropriate styles instead, as a way to boost performance.



                        • 9. Re: When is an FM11 layout *really* converted to a 'real' fmp12 layout?



                          Thanks Mike -- I learned a lot from this post.



                          • 10. Re: When is an FM11 layout *really* converted to a 'real' fmp12 layout?

                            It will take ONE FULL-TIME EMPLOYEE - working on no other task than the task of converting buttons to fmp12 native format - A WHOLE QUARTER OF A YEAR - to complete the process.


                            The amount of  work involved is daunting, isn't it. I recently had to provide an estimate of time to move an solution forward. I did a DDR and put the results through a simple guesstimator program that I use and came up with a result of two years. I was told that a colleague had estimated the work involved at four to six weeks. (I hope they didn't give a fixed price quote!)


                            Ever since I switched from HyperCard to FileMaker I have missed the ability to control the layout using the program language. In Hypercard, every object was obedient to the commands of the language. Why can't we write a script which says:


                            Set variable ($lyt_count; number of layouts)


                                Exit Loop If ( $lyt ; $lyt + 1; $lyt > $lyt_count )

                                Go to Layout ( $lyt )

                                Set variable ($n ; number of buttons )


                                   Exit Loop If ( $i ; $i + 1; $i > $n )

                                   set variable

                                   create new button { $button }

                                   delete button $i

                                End Loop

                            End Loop




                            • 11. Re: When is an FM11 layout *really* converted to a 'real' fmp12 layout?
                              Stephen Huston

                              I think between you and Mike Mitchell, you have pretty well covered the issues. My thinking is that your questions re "What is a Real FMP12 layout?" begs for some clarification.


                              FMP12 uses CSS for layout rendering, and all converted layouts are Real CSS in 12, its just that converted layouts have more CSS styles applied than others. As with CSS in simple HTML files, if you go in and override the default stylesheet settings on some element, you get an added Style encoded into the local HTML file itself rather than in the external stylesheet which otherwise controls the rendering.


                              In FMP12, Classic is placing all of the CSS style as local "overrides" instead of applying a FM-prepared theme stylesheet, so it the CSS code is going to be bulkier than for a layout built from scratch in 12 using only a prepackaged theme.


                              All of these are fully FMP12 -- just as real. However, Classic relies on reading the info from the FP7-file layout, and adding individual CSS elements for each item on the layout to replicate that via an extra layer of CSS in the new file. If you start going into a brand-new 12-Theme-based layout and overriding defaults such as the corner-rounding settings, you are doing the same thing as Classic does -- adding CSS-overrides to the coding -- just on fewer elements.

                              • 12. Re: When is an FM11 layout *really* converted to a 'real' fmp12 layout?

                                Hello Mr Watson


                                I'm afraid I don't have specific answers (i'm no Sherlock .. groan ) but I picked up a couple of points at Devcon to add to the pot.  Was about to review my notes as just getting back to FM after a sabbatical in other worlds.


                                My General Understanding


                                With a conversion you ultimately get the *Classic CSS Theme applied to layout and a lot of 'Local' CSS styles applied to individual layout objects to try and match FM11 render engine in CSS.


                                *Believe 'Classic' theme is baked into client as fallback theme, just as browsers render html with a basic CSS if referenced CSS files not found.


                                Each FM layout object has a ton of potential attributes (in xml - object size, date, time, number formats, font size, ) and may or may not have Local CSS styles applied in the <LocalCSS> tag override layout Theme styles <FullCSS>.  Conditional Formatting trumps everything, thats also attached to local object in own tag.


                                A potential disadvantage of staying with FM11 converted layouts is its not optimised CSS code (i.e. lots of unique 'Local' CSS styles to evaluate rather than one shared Theme CSS style) but if not having obvious speed issues then its not a problem and should be fine for foreseeable as essentially same CSS/Layout render framework.   If you wanted to start adding rollovers, gradients etc you might wanna try and do it with a base Theme in place first. Be aware Conditional formatting adds fair chunk of code to each object too.


                                The basic message I've got is if want optimised render speed keep to theme styles, i.e. apply one theme to all layouts in file, draw objects and don't mess with individual object styles. Then less code needs to be evaluated which optimises render speed.  This isn't really practical as you'll want to tweak certain objects but if keep as a mantra then probably see you well. i.e. standard object styles throughout designs (how it should be anyway).


                                I'm playing the wait & see game to see when (hopefully rather than if) FM give blessings to mess with themes before I spend ton of time on layouts.  Applying a theme is gonna mean refining/tweaking/repositioning layouts even if roll your own.



                                Devcon Notes


                                Devcon session videos should be available soon. Underhood sessions were great, the layout session covered a lot of ground fast, unfortunately I was bit late + bit distracted by client issues at time but here's few points I noted down.  If i'm spreading any mis-information pls let me know.



                                - Conversion of most objects from FM11 to 12 are gonna have 'local' css applied to get same look as FM11. Use icon with red line in inspector to kill all styles from object (FM will apply Classic Theme styles to object until make changes), can apply current layout theme style to individual object with far right theme style paste style button. (Not sure about grouped objects here btw?)


                                - Best practice: Choose one base theme for solution and make customised objects only where necessary. For any objects you do customise keep consistent throughout solution  (I assume some css grouping optimisations & caching of rendered objects going on - t.b.c).  You can use a diff theme for different layout but DO NOT copy & paste objects between those layouts. See next point


                                -  Important: Avoid copy & pasting objects between layouts which have different themes applied. It will nest current 'Theme' CSS style as a 'Local' object style in the new layout meaning unnecessary CSS code bloat on that new layout. Esp if copy and paste load of objects. 


                                I tested this just now, the warning also extends to avoiding cross theme copy & paste via Inspector buttons AND copying from container (graphics object database) to layout. Copying from 'Classic' theme to another also cause same nesting issue.


                                Seems its safest to use just one base theme then can copy & paste custom objects as please OR recreate the object style in new layout if you want to copy the object style across themes. (e.g. a button).


                                - Avoid trying lots of themes in production file.  Applying theme to layout also injects at file level and cannot remove (yet).  Meaning if try 30 themes on one layout, file will be 30 x bigger that if tried just one theme.  (Quick test added approx. 100kb per theme, not huge deal, but worth knowing)


                                - Offscreen objects cost less in FM12, they are ignored by render engine unless in active screen area, e.g. right of active layout, think also said behind tabs also ignored (i.e. drag object off active space to right to act as primitive debug, can drag object back to see which objects causing slower render if have issues). 


                                - However, all layout objects have a WAN/LAN price even if hidden, FM client has to pull down all layout objects information (layout xml) on load even if don't get evaluated/rendered to screen.


                                - Refresh window: behaviour is different/better in 12. In 12 it refreshes NOW i.e. it evaluates layout no matter what.  FM11 sometimes would wait for refresh (not sure what made it wait pre 12 tho).   So now more power in devs hands but need to manage it. e.g. refresh inside a freeze window step may cause unnecessary screen redraws.  Related Freeze Windows/ Windows platform render improvements. (double buffer)


                                - iOS has no hover state so those are ignored in render process by FMGo, pretty sure said something else ignored on Go. I thought he said box-shadow property (blue highlight on fields) but not the case - i'll have to watch video.


                                - FM12.2 speed improvements via CSS caching evaluated layout objects, optimisation improvements.





                                Olly Groves

                                London, UK

                                • 13. Re: When is an FM11 layout *really* converted to a 'real' fmp12 layout?

                                  I wonder if I can shift the topic a little bit.


                                  I converted Seedcode Complete v1 solution (not the v2 which is leaner and quicker) to FMP12 format a few months ago. This application has a rich user interface. Without being judgemental, we can say it was built for comfort not for speed. If there is going to be a problem moving forward to 12 I'd expect to see it show up in this solution.


                                  I put it onto a remote server and it performs well. Layout switches are not immediate on the first load ( 3s ) but from that point on it is responsive to user interaction. When I run it locally I notice that it is faster but this is obviously related to network latency.


                                  The bottom line is that I'm not seeing any problems running this solution on the WAN. It is fully functional and fast enough for real business use. In the solution the contacts table has 15000 records. The calendar table has 6000 records.


                                  I can't see any problems with layout drawing. Screen rendering is fine on my Mac. It looks fine on the customers Win7 boxes. The extra overhead that comes with having legacy information isn't apparent.


                                  With this experience, I wonder whether you are chasing shadows. Sure, you can see that the underlying xml has a difference and there is a an extra node in the path. What real effect does that have on the function of your program? It must be a few kilobytes heavier but that doesn't make things break or go slow.



                                  • 14. Re: When is an FM11 layout *really* converted to a 'real' fmp12 layout?



                                    You mention the video  - are the videos up yet? We can not seem to locate them and we have been waiting to review/compare against our notes, as this session you are referring to was one of the most important of the conference we felt.



                                    1 2 Previous Next