yv01p/Umbraco-CMS
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
dea22f22cbdd4bb487f0135fe06d75c77e26cf69
Umbraco-CMS/src/Umbraco.Web/Mvc/SurfaceController.cs

118 lines
3.2 KiB
C#
Raw Normal View History

Added all code to support auto-routing surface controllers and started implementing the code for BeginUmbracoForm.
2012-09-25 13:09:59 +07:00
using System;
using System.Collections.Concurrent;
using System.Web.Mvc;
using Umbraco.Core.Models;
using Umbraco.Core;
namespace Umbraco.Web.Mvc
{
comments out test surface controllers for now
2012-09-26 13:44:23 +07:00
//[PluginController("MyTestSurfaceController")]
//public class TestSurfaceController : SurfaceController
//{
// public ActionResult Index()
// {
// return View();
// //return Content("<html><body>hello</body></html>");
// }
Surface controllers now auto-routing, both locally declared and plugin types (which require a [PluginController] attribute and an Area Name assigned). 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 :)
2012-09-26 13:42:03 +07:00
comments out test surface controllers for now
2012-09-26 13:44:23 +07:00
// public ActionResult PostVals(string name)
// {
// ModelState.AddModelError("name", "bad name!");
// return CurrentUmbracoPage();
// }
//}
Surface controllers now auto-routing, both locally declared and plugin types (which require a [PluginController] attribute and an Area Name assigned). 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 :)
2012-09-26 13:42:03 +07:00
comments out test surface controllers for now
2012-09-26 13:44:23 +07:00
//public class LocalSurfaceController : SurfaceController
//{
// public ActionResult Index()
// {
// return View();
// }
Surface controllers now auto-routing, both locally declared and plugin types (which require a [PluginController] attribute and an Area Name assigned). 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 :)
2012-09-26 13:42:03 +07:00
comments out test surface controllers for now
2012-09-26 13:44:23 +07:00
// public ActionResult PostVals([Bind(Prefix = "blah")]string name)
// {
// ModelState.AddModelError("name", "you suck!");
// return this.RedirectToCurrentUmbracoPage();
// }
//}
Started adding tests for surface controller routing. They are working but not quite correctly yet.
2012-09-25 13:33:47 +07:00
Added all code to support auto-routing surface controllers and started implementing the code for BeginUmbracoForm.
2012-09-25 13:09:59 +07:00
/// <summary>
/// The base controller that all Presentation Add-in controllers should inherit from
/// </summary>
[MergeModelStateToChildAction]
Changed how surface controllers are routed: because we don't load plugins in via App_Plugins/[PackageName] like we did in v5 which meant that we can autoroute all plugin controllers with their own areas, in v4 we have to do something different. 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.
2012-09-26 11:04:07 +07:00
public abstract class SurfaceController : PluginController
{
Added all code to support auto-routing surface controllers and started implementing the code for BeginUmbracoForm.
2012-09-25 13:09:59 +07:00
/// <summary>
/// Default constructor
/// </summary>
/// <param name="umbracoContext"></param>
protected SurfaceController(UmbracoContext umbracoContext)
Changed how surface controllers are routed: because we don't load plugins in via App_Plugins/[PackageName] like we did in v5 which meant that we can autoroute all plugin controllers with their own areas, in v4 we have to do something different. 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.
2012-09-26 11:04:07 +07:00
: base(umbracoContext)
{
Added all code to support auto-routing surface controllers and started implementing the code for BeginUmbracoForm.
2012-09-25 13:09:59 +07:00
}
/// <summary>
/// Empty constructor, uses Singleton to resolve the UmbracoContext
/// </summary>
protected SurfaceController()
Changed how surface controllers are routed: because we don't load plugins in via App_Plugins/[PackageName] like we did in v5 which meant that we can autoroute all plugin controllers with their own areas, in v4 we have to do something different. 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.
2012-09-26 11:04:07 +07:00
: base(UmbracoContext.Current)
{
Added all code to support auto-routing surface controllers and started implementing the code for BeginUmbracoForm.
2012-09-25 13:09:59 +07:00
}
/// <summary>
/// Redirects to the Umbraco page with the given id
/// </summary>
/// <param name="pageId"></param>
/// <returns></returns>
protected RedirectToUmbracoPageResult RedirectToUmbracoPage(int pageId)
{
return new RedirectToUmbracoPageResult(pageId, UmbracoContext);
}
/// <summary>
/// Redirects to the Umbraco page with the given id
/// </summary>
/// <param name="pageDocument"></param>
/// <returns></returns>
protected RedirectToUmbracoPageResult RedirectToUmbracoPage(IDocument pageDocument)
{
return new RedirectToUmbracoPageResult(pageDocument, UmbracoContext);
}
/// <summary>
/// Redirects to the currently rendered Umbraco page
/// </summary>
/// <returns></returns>
protected RedirectToUmbracoPageResult RedirectToCurrentUmbracoPage()
{
return new RedirectToUmbracoPageResult(CurrentPage, UmbracoContext);
}
/// <summary>
/// Returns the currently rendered Umbraco page
/// </summary>
/// <returns></returns>
protected UmbracoPageResult CurrentUmbracoPage()
{
return new UmbracoPageResult();
}
/// <summary>
/// Gets the current page.
/// </summary>
protected IDocument CurrentPage
{
get
{
if (!ControllerContext.RouteData.DataTokens.ContainsKey("umbraco-route-def"))
throw new InvalidOperationException("Can only use " + typeof(UmbracoPageResult).Name + " in the context of an Http POST when using the BeginUmbracoForm helper");
var routeDef = (RouteDefinition)ControllerContext.RouteData.DataTokens["umbraco-route-def"];
return routeDef.DocumentRequest.Document;
}
}
Changed how surface controllers are routed: because we don't load plugins in via App_Plugins/[PackageName] like we did in v5 which meant that we can autoroute all plugin controllers with their own areas, in v4 we have to do something different. 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.
2012-09-26 11:04:07 +07:00
Added all code to support auto-routing surface controllers and started implementing the code for BeginUmbracoForm.
2012-09-25 13:09:59 +07:00
}
}
Reference in New Issue Copy Permalink