2 '?' the internals of ASP.net actually force a secondary internal request which causes BeginRequest to fire but doesn't follow the normal
chain of the module. It was a bug with our code having two query strings, however its pretty strange behavior on their part!
Have removed UmbracoContext.ClientUrl since it is not necessary to have. Have renamed UmbracoContext.UmbracoUrl = CleanedUmbracoUrl and UmbracoContext.RequextUrl = OriginalRequestUrl
Have moved the route processing logic to a static method on PublishedContentRequest which auto assigns the request back to the UmbracoContext, plus this is a cleaner
way to do the processing, including allowing us to unit test this one aspect.
Lastly, we are now rewriting the path back to the original URL in the RenderRouteHandler so that in MVC controllers the HttpContext.Request actually
reflects the URL that the client requested, not the rewritten URL (we do this in webforms too)
RenderViewPage to UmbracoTemplatePage which now inherits from UmbracoViewPage. Added NiceUrl and NiceUrlWithDomain as extension
methods to IPublishedContent.
that are on the DynamicPublishedContent object. Added more unit tests for all of these classes.
Moved some of the Dynamic objects into the web project which simplifies things quite a bit as some of these classes require access to the biz logic layer.
Now we have intellisense for all of the nice magical methods that were on DynamicPublishedContent on our strongly typed object!
Updated DynamicPublishedContent's methods to just proxy calls to the new extension methods so that all of the logic is contained in one place.
Added new GetRootDocuments to the IPublishedContentStore since we need this in order to get the root list of documents for many of these methods.
Fixed an issue with the DynamicNode to IPublishedContent converter.
Fixed many of the failing unit tests.
moves ResolveUrlsFromTextString to TemplateUtilities class and obsoletes other ones.
Fixes an issue if content cache is stored in codegen folder and not in med trust.
Updates the XmlDocument (IDocumentProperty) to always return a value with parsed {localLink} and resolved Urls and cache them so the parsing only happens once.
an UmbracoHelper property to the PluginController class which will expose any methods needed by devs to retreive media or content.
Have updated UmbracoHelper with loads of new helpful methods and moved the Wrap methods to HtmlHelper extensions because this is purely to
do with rendering html (have written unit tests for it too).
Updated some 'library' methods to proxy calls to UmbracoHelper so we only have to maintain one set of code.
Added a convenience property to UmbracoContext to return the current NiceUrlProvider so you don't have to go through the RoutingContext to get it.
BeginUmbracoForm working for both local and plugin SurfaceControllers. SurfaceController class now inherits from PluginController which exposes all things a dev would
need including making IPublishedContentStore and IPublishedMediaStore public which can be accessed simply by properties on the controller.
Updated web.config for views to include Umbraco.Web namespace for all of our helper methods.
BeginUmbracoForm now has many more overrides for which you can specify a type or a generic type (we no longer require GUIDs :)
Instead (because we still want areas), we have an attribute called PluginControllerAttribute which allows a dev to assign an area name as a string. A package developer should always ensure that all of their plugin controllers are assigned to the same
area. This also lets us get rid of the GUID id part of the plugin (hopefully we can leave it out, just need to run some tests). Since we have areas, package devs can then put their views into
their own folders and not clutter up the local devs ~/Views folder. Perhaps we use App_Plugins/[PackageName] for the views like we did in v5 but need to ask on the mail list. Otherwise it will be the standard MVC:
~/Areas/[AreaName]/Views which will still also clutter up the local devs view folder if they are using Areas.
I've also added this web.config file to the sln so it should output in the build by default though it will still be created automatically if
its not there.
all calles in RazorLibraryCore for Wrap to UmbracoHelper. Fixed up the HtmlTagWrapper classes so they have immutable properties and replaced
public fields with Properties.
Adds UmbracoHelper as a property to the RenderViewPage for MVC. Tested rendering Xslt and Razor macros with and
without parameters and works well.
Next we need to get the RTE rendering with macros embedded in MVC.
to need to support MVC and the old Template object is for webforms. I've added a lot of TODO's here
because we'll need to enable the lookups properly in each ILookup and also set the rendering engine (IsMvc)
in the ILookups too. This hasn't been enabled, yet, just a bunch of TODO's written.
Adds a few unit tests for DynamicDocument/DynamicNode and fixes both to properly support the 'Take' method
as this wasn't really working. Not sure how or why it was working previously. Have also allowed for extension
methods to be executed against either of these objects that accept IQueryable which was not supported before.
This allows us in the future to use any type of data source for the dictionary. Have obsoleted the old
ICultureDictionary in the macro engines project (where it doesn't belong anyways). The new one doesn't expose
the 'Language' property to the front-end because this is a business logic class which means designers can just delete
a whole language from the db by calling 'Delete' on the object !
and is poorly formatted, this now allows us to properly abstract an IDocument using the new IContentStore which now
returns IDocument instead of XmlNode so we now have an abstraction away from Xml for routing.
The DocumentSearcher now performs the searching and sets the properties on the DocumentRequest, this
simplifies the dependencies between the contexts. Updated the LookupByNiceUrlTests unit test, now all
initialization is working and the test runs which will be the basis for testing all of the IDocumentLookups.
from the initial concept. The module is not active as it currently will not work because of
contructor dependencies and classes marked as internal, will liase with Stephen regarding this.
