Relocating IContentHandler imlementations that power IContentXxxDriver interfaces
Giving them component role suffix Coordinator
Merging two handlers into one content part driver coordinator
--HG--
branch : dev
- includes changing settings from IDictionary<string, string> to SettingsDictionary : IDictionary<string, string> w/ GetModel<T>
- also cleaned up content type creation a little
--HG--
branch : dev
* Removed unused "ServiceLocator" class
* Added "OrchardHostContainerRegistry" class to enable Shim/HostContainer
registration for DI
* Refactored the BuildProvider for .csproj file to use the new
OrchardHostContainerRegistry class and enable proper DI for implementations.
--HG--
branch : dev
From the comment:
/// <summary>
/// We should be able to support reloading multiple version of a compiled module from
/// a ".csproj" file in the same AppDomain. However, we are currently running into a
/// limitation with NHibernate getting confused when a type name is present in
/// multiple assemblies loaded in an AppDomain. So, until a solution is found, any change
/// to a ".csproj" file of an active module requires an AppDomain restart.
/// The purpose of this class is to keep track of all .csproj files monitored until
/// an AppDomain restart.
/// </summary>
--HG--
branch : dev
When a WebForm view file is served through the WebFormVirtualPathProvider,
we override GetFileHash to include the virtual path of all the dependencies
used to compile the form. For example, if we had a "Assembly Name=..."
directive, we want to include the file hash of the assembly file, so that if the
assembly file is updated with a newer version, the file hash of the WebForm view
file will be different, which will tell ASP.NET the view file needs to be
recompiled.
--HG--
branch : dev
When a view is served from the "~/Themes" directory, we need to add
the assembly directives of all the modules dynamically compiled.
--HG--
branch : dev
We don't need this. Azure supports writing tp ~/App_Data. There is no
guarantee that the content will persist, but that's exactly the assumption
of the IAppDataFolder abstraction: it's a local cache, which persists
for _some_ time accross app restarts.
--HG--
branch : dev
- added a DisplayName to the ContentTypeDefinition
- added a CreateRouteValues rvd to go along with the existing display and edit
- set default display, edit and create route values for ContentItemMetadata (* should get fallback route values in a different manner. probably not good to refer to an area, even by string, in core from the fwk)
- starting to shape up the content type list into a more consistent UI
- added create type action, view, etc. for creating new content types
- supporting service has a few default parts hard-coded for now
--HG--
branch : dev
