Method Community

I have recently noticed that while in designer mode the response can sometimes be extremely slow when making even minor changes to fields.

I think some of this may be due to the fact that the designer programme  now appears to be doing publishing when changes are made to actions, but before one actually 'publishes' the changes.  Not only does this appreciably slow down the customization process, but also changes live screens (both for me and others) with unpublished actions. Even after closing a screen without publishing, the changes still occur on the live working screen. Furthermore, all this 'mini-publishing' doesn't speed anything up when I choose to actually publish my changes.

I know this sounds unlikely, so you can easily test this yourselves by inserting a show message action into some action set (for instance OnScreenAppearence) and watch it appear right away.

Automatically 'publishing'  unpublished changes in a working system is disasterous in my opinion.  Could someone please explain to me what's going on here, and when it might be fixed?

thanks,

Rolf

Rolf,

It sounds to me like you are making changes to a screen that is being used by users at the same time.  This is bad news.  Why?  Well if you're making changes while users are connected to that screen, they're going to get funky results because you're moving around actions, etc.  

You should either:

a) make changes while users aren’t using the screen OR
b) make a copy of the screen, when happy with the changes, make that version live to their users.  

Best practice from Method is option B.

Making changes to a screen in the designer will affect some parts of it, mainly actions, even before you publish.  The publish button means that you want to screen to be re-drawn with the latest objects based on their location and references.  This process also ensures that objects being called in actions are properly referenced based on their position on screen.  The screen is never in a “hibernate” state meaning if you start moving actions around, etc. it will affect the screen.  This is not a new issue, it's always been this way.  

You should always make a copy of the screen to avoid users accessing a screen in the middle of being altered.

FYI - some actions may work before you publish them but you'll get mixed results.  You should always publish before you test a screens action set out.  Why? It needs to generate the pages for the screen itself and it needs to update any relevant actions within calls being made to other fields/objects.  Publish is a complex process and needs to completely finish for your page to work correctly.

Moving forward this will become less of an issue as our codebase improves.  There are already plans for a new architecture which will lock all published pages so any edits will be on a totally different version to the screen (seamless to the user of course).

Follow our best practice above and you should never run into this problem.

~C

Chad,

You're quite right; I was making changes to a screen that was also open at the same time on my computer. I was under the impression any changes would not take effect on  a screen until it was published, much like one does when publishing a web page for instance. I never really thought about it much before, but I guess I just assumed unpublished changes would be stored in  temporary file copy of the screen, and publishing would then use that to replace the live version.

I got this impression from watching the webinars and reading the documentation such as the following from solution #94: