Distributing custom builder components

After you create a custom page builder or form builder component in your MVC project, e.g. a widget or a form builder section, you might want to share the code of this component among other projects inside your company, or with the rest of the world. 

The most common way of distributing code in the .NET community is using NuGet packages. NuGet packages are code bundles containing compiled code along with other content needed in the projects for which they are created. Developers can share these packages with other developers directly or by publishing them to public or private hosts (such as nuget.org). Another possible way of distributing your code is simply by sharing the code packaged in ZIP files.

On this page, you can read best practices that we recommend when you wish to create distributable components. See the following sections for information about individual types of components:

• Widgets
• Inline property editors
• Page builder sections
• Page templates
• Form components
• Form builder sections
• Personalization condition types with a custom configuration dialog
• Single class components

Widgets

• Use a unique prefix in your widget identifiers to prevent conflicts when deploying the widgets to other projects. For example, the prefix can match your company’s name.
• Store all text displayed by the widgets using resource strings. Create a designated RESX file for the resource strings of each of your widgets in the ~/App_Data/Global/Resourcesdirectory.
• Place your custom MVC code into the designated directories:
  • Controllers into the ~/Controllers/Widgets directory.
  • Widget property and view models into the ~/Models/Widgets directory.
  • Views into the ~/Views/Shared/Widgets directory.
• Place your script and stylesheet files into the ~/Content/Widgets/<WidgetIdentifier> directory.

See Developing widgets in MVC for more information.

Inline property editors

• Use a unique prefix in your inline editor identifiers to prevent conflicts when deploying the editors to other projects. For example, the prefix can match your company’s name.

• Store all text displayed by the inline editors using resource strings. Create a designated RESX file for the resource strings of each of your inline editors in the ~/App_Data/Global/Resourcesdirectory.

• Place your custom MVC code into the designated directories:

  • Models into the ~/Models/InlineEditors* directory.
  • Views into the ~/Views/Shared/InlineEditors* directory.

• Place your script and stylesheet files into the ~/Content/InlineEditors/<InlineEditorIdentifier> directory.

See Creating inline editors for widget properties for more information.

Page builder sections

• Use a unique prefix in your section identifiers to prevent conflicts when deploying the sections to other projects. For example, the prefix can match your company’s name.
• Store all text displayed by the sections using resource strings. Create a designated RESX file for the resource strings of each of your sections in the ~/App_Data/Global/Resourcesdirectory.
• Place your custom MVC code into the designated directories:
  • Controllers into the ~/Controllers/Sections directory.
  • Views into the ~/Views/Shared/Sections* directory.
  • Optional models into the ~/Models/Sections* directory.
• Place your script and stylesheet files into the ~/Content/Sections/<SectionIdentifier> directory.

See Developing page builder sections for more information.

Page templates

• Use a unique prefix in your page template identifiers to prevent conflicts when deploying the page templates to other projects. For example, the prefix can match your company’s name.

• Store all text displayed by the page templates using resource strings. Create a designated RESX file for the resource strings of each of your page templates in the ~/App_Data/Global/Resourcesdirectory.

• Place your custom MVC code into the designated directories:

  • Views into the ~/Views/Shared/Templatesdirectory.
  • Optional models into the ~/Models/Templates directory.

• Place your script and stylesheet files into the ~/Content/Templates/<SectionIdentifier> directory.

• Place your page template filters into the ~/PageTemplateFilters directory.

See Developing page templates in MVC for more information.

Form components

• Use a unique prefix in your form component identifiers to prevent conflicts when deploying the components to other projects. For example, the prefix can match your company’s name.
• Store all text displayed by the form components using resource strings. Create a designated RESX file for the resource strings of each of your components in the ~/App_Data/Global/Resourcesdirectory.
• Place your custom MVC code into the designated directories:
  • Form component and properties classes into the ~/Models/FormComponents* directory.
  • Views into the ~/Views/Shared/FormComponents* directory. Use the _<FormComponentIdentifier>.cshtml format for the names of view files.
• Place your script and stylesheet files into the ~/Content/FormComponents/<FormComponentIdentifier> directory.

See Developing form components for more information.

Form builder sections

• Use a unique prefix in your form section identifiers to prevent conflicts when deploying the sections to other projects. For example, the prefix can match your company’s name.
• Store all text displayed by the form builder sections using resource strings. Create a designated RESX file for the resource strings of each of your sections in the ~/App_Data/Global/Resourcesdirectory.
• Place your custom MVC code into the designated directories:
  • Controllers into the ~/Controllers/FormSections directory.
  • Views into the ~/Views/Shared/FormSections* directory.
  • Optional models into the ~/Models/FormSections* directory.
• Place your script and stylesheet files into the ~/Content/FormSections/<FormSectionIdentifier> directory.

See Developing custom form layouts for more information.

Personalization condition types with a custom configuration dialog

• Use a unique prefix in your condition type identifiers to prevent conflicts when deploying the condition types to other projects. For example, the prefix can match your company’s name.
• Store all text displayed by the condition types using resource strings. Create a designated RESX file for the resource strings of each of your condition types in the ~/App_Data/Global/Resourcesdirectory.
• Place your custom MVC code into the designated directories:
  • Condition type classes into the ~/Personalization/ConditionTypes directory.
  • Dialog controllers into the ~/Controllers/Personalization/ConditionTypes directory.
  • Dialog models into the ~/Models/Personalization/ConditionTypes* directory.
  • Dialog views into the ~/Views/Shared/Personalization/ConditionTypes* directory.
• Place your custom CSS styles into the ~/Content/Personalization/ConditionTypes directory.

See Developing personalization condition types for more information.

Single class components

When distributing components consisting of a single class, such as personalization condition types, form visibility conditions, and form validation rules:

• Use a unique prefix in your component identifiers to prevent conflicts when deploying the components to other projects. For example, the prefix can match your company’s name.
• Store all text displayed by the components using resource strings. Create a designated RESX file for the resource strings of each of your components in the ~/App_Data/Global/Resourcesdirectory.