Inline Code - Introduction

Inline Code allows developers to manage code directly within Agility, removing the need to be familiar with Visual Studio, MVC architecture, and deployments.

Inline Code can be used to power the entire page render life-cycle including the Master page, Page Template, Module Template, shared Templates, JS and CSS.

How it Works

Inline Code files work in conjunction with your syncing .NET Agility MVC website. Inline Code files are synced just like regular content items, which allows you to preview your files in production before publishing.

Static files such as JS and CSS can be defined in Agility and loaded over a dynamic URL over our CDN. While, Templates, Page Templates, and Module Inline Codes files are dynamically rendered using MVC's razor engine.

In simple terms, Templates, Page Templates, and Module Inline Code files represent an alternative to using static .cshtml files within your MVC website. While, JS and CSS offer an alternative to having to using .js and .css files within your MVC website.

Inline Code Types

CSS – create, modify, or delete CSS inline and optionally enable minification

JavaScript – create, modify, or delete JavaScript files inline and optionally enable minification

Templates – create, modify, or delete HTML templates inline, these templates may also contain Razor or WebForms code

Module Definitions – modify Module Output code using HTML and Razor/WebForms code

Page Templates – modify Page Templates
 

Publishing and Staging

Inline Code items follow the same publishing workflow as Content Items. When you make a change and save the code, the code is now in Staging mode. You can then preview this code by navigating to a page which runs this code and previewing the page. When you are satisfied, you may Publish the changes.

Auto-Generated Code

Agility will automatically generate Markup for your Page Templates and Module Definitions based on your Page Template Module Zones and your Module Properties. This provides a good starting point and bypasses the “blank canvas”. You can also optionally revert back to auto-generated code by clicking the Regenerate Code button in the Action bar of the Page Template or Module Definition within Inline Code.

Version History

 As with Content Items in Agility, Inline Code also has Version History. Version History allows developers to optionally view and revert code to a previous state. To access the Version History for an Inline Code item, click the Version History tab.

Referencing Other Inline Code Files

It is a common requirement to be able to reference other inline code files dynamically within Templates, Page Templates, or Module inline code files. For example, you Page Template may reference a Template that represents your Header or Footer. Or, your Masterpage Template may reference JS and CSS files.

You may use the following HTML helpers to reference inline code files within any CSHTML template either within Inline Code or even in your MVC website code directly.

Reference a CSS file in Inline Code (renders a <link> tag):

@Html.AgilityCSS("skin")

Reference a Template file in Inline Code (renders the CSHTML in-line):

@Html.AgilityTemplate("Header")

Reference a Template file in Inline Code and Pass an Object as a ViewModel (renders the CSHTML in-line):

@Html.AgilityTemplate("Header", headerViewModel)

Reference a JS file in Inline Code (renders a <script> tag):

@Html.AgilityJavascript("defaultscript")

Inline Code vs MVC Website Code

Using Inline Code to manage your code-base over a traditional IDE such as Visual Studio has some distinct advantages and disadvantages. It's important to understand the difference, and follow best practices for managing Inline Code files.

Advantages

• Can be an effective way to expose front-end templates to developers or HTML/CSS savvy editors who are not comfortable using Visual Studio

• Without the requirement of running the Agility Website locally, the "ramp-up" time for a developer to get started on a project can be greatly reduced

• Deployments only require publishing, eliminating the need for deploying the entire application

• Module and Page Template inline code files generate boilerplate code making it easy to reference properties within CSHTML

• Agility supports 'mixing' Inline Code and traditional server-side code for extra-flexbility

Disadvantages

• No central repository of source code - your MVC website code and Inline Code are managed separately

• Website logic can be split between your MVC website code and Inline Code, which can affect code consistency and patterns 

• Developers who are familiar with .NET and Visual Studio and their various tools will likely prefer working in an IDE

• No compile-time error checking

• Limited intelli-sense within the online editor

• Limited use of the strongly-typed C# auto-generated classes that Agility provides for your Content and Module Definitions - If working exclusively in Inline Code, you have no way of updating your C# Agility classes

• Usually working in Inline Code requires you to access properties by their reference name (as a string) - i.e. Model["Title"] as opposed to Model.Title 
  
  

Inline Code Best Practices

While Inline Code has its pros and cons, there are certain steps you can take to better address the disadvantages of its usage.

1. Establish a development paradigm and stick to it - Have the Inline Code responsible for all front-end templates, and use MVC website code only for code-behind files such as Controllers. If you find yourself doing lots of business logic within Inline Code code files, this is better suited to be placed into the MVC website code as a Controller ActionResult or HTML Helper. 

2. Be mindful of permissions - If an editor has been added to the instance as an Administrator, that means they will be able to modify Inline Code. Ensure you restrict permissions so that only developers have access to Inline Code.

3. Test your code locally, or on a UAT/Stage server with Custom Errors turn "Off" - If testing in production, it is likely that Custom Errors is turned "On" and if an application error occurs then you won't be able to easily see the error and stack trace - instead having to rely on viewing the Web Logs in Agility (Settings > Web Logs). To increase efficiency during testing, test the code on your UAT/Stage server with Custom Errors turned "Off" and Compilation Debug equals "True" so you can see the stack trace.
   
   See more Information on Custom Errors
   
   
   

4. Always Preview your code changes on UAT/Stage before publishing to production - While you can preview inline code templates in production directly, this brings a risk of introducing adverse effects from testing your code. For example, you may have code in your CSHTML that introduces a stack overflow that could crash your production application pool - or you could have some inadvertent CPU intensive logic that affects the performance of your production web server. To resolve this risk, always preview and test your code updates on your UAT/Stage server. When ready to deploy to production, simply publish the code file.

5. Ensure two Developers aren't modifying the same file at the same time - Unlike MVC website code, there's no local file and a "check-in" process for checking in and merging the file into source control. Instead, an Inline Code file is saved to the cloud each time a change is made. This can result in developers overwriting each other's work if they are modifying the file at the same time.