Live Reloading Content during Development

Web Connection 7.06 and later includes built in support for Live Reloading content when you make a code change to either Web client code or your source code.

You can think of Live Reload as WYSIWYG on steroids. It lets you see code changes you make almost instantly while you work. Just press save and the browser shows your change in almost real time.

When Live Reload is enabled, anytime you make a change to a Web file like a Web Connection Script, CSS, HTML or JavaScript , or make a change to a server side code file, Web Connection automatically refreshes the active page in the browser. This means you don't need to manually switch to the browser and hit refresh - it does it 'on its own'! It's a big time saver especially when working on HTML UI because of it twiddly nature.

As of Web Connection 7.06, Web Connection includes native support for Live Reload without requiring external tools like Browser Sync. This mechanism detects changes in common files in the \Web folder, as well as source code files in \Deploy folder.

Here's what Live Reload looks like in action:

Using an External Editor

Note that in the video I'm using an external editor - Visual Studio Code in this case. This allows me to make changes while the FoxPro server is running and keep the editor open. I can also use VS Code to edit both my FoxPro code as well as my HTML files all using proper syntax coloring. The FoxPro editor unfortunately locks files while the editor is open so it's not a good choice for 'live' editing because while a file is open the code cannot be compiled. You can use any editor you want although Visual Studio Code with the FoxPro Syntax Addin is a great choice.

Enabling Live Reload

By default Live Reload functionality is disabled in Web Connection, because it has some overhead when serving HTML content and static files it's not a good fit running applications in production. For development it's great, but you first need to enable it with configuration settings in both the Web folder in web.config and the your Deploy folder in yourApp.ini (project name instead yourApp):

In web.config:

  • Set LiveReloadEnabled configuration to True
  • Enable runAllManagedModulesForAllRequests
  • Uncomment Web Connection Live Reload Module hookup

In yourApp.ini:

  • Set LiveReloadEnabled to On

There's more detailed configuration information below for these steps.

Turn off Live Reload for Production!

Make sure that when you deploy your application you turn off Live Reload functionality. The Live Reload module routes all requests through the Web Connection including static files, which is much slower than natively letting IIS handle them. For this reason make sure when you deploy, you turn off the LiveReloadEnabled flag as well as the runAllManagedModulesForRequests flag.

Let's look at the configuration settings in more detail.

Web.Config Settings

The web.config settings configure the client side detection. There are two configuration settings that need to be made in web.config.

The first is in the main section where you have to enable Live Reload by setting LiveReloadEnabled to True:

<configuration>
  <webConnectionConfiguration>
    <add key="LiveReloadEnabled" value="True" />
    <add key="LiveReloadExtensions" value=".wwd,.blog,.wc,.wcs,.html,.htm,.css,.js" />
  </webConnectionConfiguration>
</configuration>  

The LiveReloadExtensions should include any of your script maps you have configured for your application. When a new project is generated your selected script map is automatically added. By default LiveReloadEnabled is False.

The second set of settings requires configuring the <modules> section in web.config:

<system.webServer>
    ...
    <modules runAllManagedModulesForAllRequests="true">
          <add name="Web Connection Live Reload Module" type="Westwind.WebConnection.LiveReloadModule,WebConnectionModule" />
    </modules>
</system.webServer>

By default this section is commented and you should uncomment it to use Live Reload.

For production make sure you re-comment the section or remove the module and set runAllManagedModuelsForAllRequest to False. This option channels all requests through the ASP.NET application rather than using native IIS static file handling. This is required

FoxPro Server Settings in YourApp.ini

In addition to client side browser reloading Web Connection can also detect changes to your FoxPro source code when you run in File mode. It includes LiveServerReload.prg module which sets up a file watcher in the Deploy folder to monitor for file changes to code files. When a file is changed the Web Connection server is shut down and restarted also triggering a browser refresh.

Works only in the IDE in File Mode

Live Server Reload only works in File Mode and then only when the application is running inside of Visual FoxPro environment as it needs to restart from within itself.

Requires Web Connection 7.05 and Later

This feature was introduced in Web Connection 7.05 and it requires some additional configuration in the AppMain.prg file. The new templates automatically add support but existing applications have to add small bit of additional code to the AppMain.prg file to enable this functionality.

Enabling LiveReloadEnabled

This option is disabled by default and has to be turned on explicitly via the LiveReloadServer configuration switch in your AppMain.ini file for your application.

LiveReloadEnabled=On

Once enabled any change to a .prg, .vcx, '.app','.exe' or .ini file in the deploy folder structure causes the Web Connection server to be recycled.

Automatic Configuration in new Projects

If you're using Web Connection 7.06 or later Web Connection automatically creates new projects that pre-configure all the settings in your new project. Both the web.config and yourApp.ini plus the server startup code are pre-configured and ready to go.

All you have to do is enable the functionality via configuration settings as described above.

Hooking up in AppMain.prg

If you have an older version that you are upgrading to 7.06+ you can add the following bits of code to your AppMain.prg (ie. your customized version for your app).

After goWcServer has been declared add the following:

*** Load the server - wc3DemoServer class below
goWCServer = CREATEOBJECT("wcDemoServer")

IF !goWCServer.lDebugMode
     ...
ENDIF

*** Auto-Restart Server if files are changed on disk   
IF goWCServer.oConfig.lLiveReloadEnabled AND Application.StartMode = 0
  DO LiveReloadServer
ENDIF

This hooks up the file watcher and starts watching files. If the file watcher detects a change to files that are watched, the watcher fires a request to CLEAR EVENTS and sets the goWcServer.lAutoRestart = .T. flag.

Immediately following the READ EVENTS change the code to the following:

READ EVENTS

*** ADD THIS LINE
llAutoRestart = goWcServer.lAutoRestart

ON ERROR
...

*** CHANGE THIS BLOCK OF CODE
RELEASE ALL EXCEPT llAutoRestart

IF llAutoRestart
   LiveReloadShutdown("DO MyAppMain.prg")
ELSE
   *** USE THIS FOR DEBUGGING OBJECT HANGING - fires all outstanding DESTROY()
   *** and you should see which objects are hanging
   *SET STEP ON  
   CLEAR ALL   
ENDIF

This code sets a preserved local variable, the restarts the server. It clears out the application's memory and state, and then stuffs a restart command into the keyboard buffer to relaunch the application. This is hacky but the only reliable way I've found to be able to completely release and restart the application. You can specify a command that is used to restart the server typically DO MyAppMain.prg. The parameter is optional - if not provided the initial startup program is used without parameters.

Using an EXE instead of a PRG to Launch

If you'd rather run your compiled project's EXE file than the PRG you can change the KEYBOARD command to include project compilation and then run the EXE instead (using wcDemo as the app name here):

lcCmd =  [BUILD EXE wcDemo from wcDemo RECOMPILE{ENTER}] + ;
         [DO wcDemo.exe]
DO LiveReloadShutdown(lcCmd)

This takes a little longer, but it's just as efficient.


© West Wind Technologies, 1996-2019 • Updated: 05/23/19
Comment or report problem with topic