NuGet package | Owin.Framework.Pages.Html |
GitHub source | OwinFramework.Pages.Html |
Package elements define a namespace for Css and Javascript assets to avoid name conflicts. When importing a 3rd party package into your application you can change the namespace name of the package and all of its assets will be renamed making it always possible to avoid naming conflicts.
You can define a package by decorating a class with the [IsPackage()] attribute. This defines a namespace for your Css and Javascript assets. You should do this within your website to seperate your application assets from any imported packages.
Below is an example of defining a package namespace and telling a Region to put its assets into this namespace. In this case I decided to create a base class with the [PartOf()] attribute and have my region inherit that, so that I don't need to remember to add the [PartOf()] attribute to each element that I define.
[IsPackage("my_website", "app")] internal class ApplicationPackage { } [PartOf("my_website")] internal class ApplicationElement { } [IsRegion("div")] internal class DivRegion : ApplicationElement { }
In this use case the [IsPackage()] attribute has properties that specify the default namespace to use for all Css and Javascript assets built by this package.
The other main user case for packages is to make a reusable package of elements that can be imported into a website to add features. For example the CMS piece of the Owin Framework has an editor for managing the pages of the website, and this editor is contained within a package. By adding the package to a website this editor UI can be dropped into any page within the website.
The most likely reasons for creating packages are either: a) providing some reusable functionallity as a NuGet package that website authors can install into their solution; or b) you have many web properties and want to share funtionallity accross them by compiling a shared assembly.
Below is the source code for the data package from the OwinFramework.Pages.Standard project. This is a fairly simple package that creates a single component, which deploys a Javascript library. The Javascript is compiled into the DLL in this case, so you only need to copy a single file to include the functionallity into a website.
using System.Reflection; using System.Text; using OwinFramework.Interfaces.Utility; using OwinFramework.MiddlewareHelpers.EmbeddedResources; using OwinFramework.Pages.Core.Enums; using OwinFramework.Pages.Core.Interfaces; using OwinFramework.Pages.Core.Interfaces.Builder; using OwinFramework.Pages.Core.Interfaces.Runtime; namespace OwinFramework.Pages.Standard { public class DataPackage: IPackage { private readonly ResourceManager _resourceManager; string IPackage.NamespaceName { get; set; } IModule IPackage.Module { get; set; } ElementType INamed.ElementType { get { return ElementType.Package; } } string INamed.Name { get; set; } public DataPackage(IHostingEnvironment hostingEnvironment) { var my = this as IPackage; my.Name = "data"; my.NamespaceName = "data"; _resourceManager = new ResourceManager(hostingEnvironment, new MimeTypeEvaluator()); } IPackage IPackage.Build(IFluentBuilder fluentBuilder) { var resource = _resourceManager.GetResource(Assembly.GetExecutingAssembly(), "dataModule.js"); if (resource.Content == null) return this; var javaScript = Encoding.UTF8.GetString(resource.Content); fluentBuilder.BuildUpComponent(null) .Name("data") .AssetDeployment(AssetDeployment.PerWebsite) .DeployScript(javaScript) .Build(); return this; } } }
In this example you can see that:
Some other things to note are