Commit Graph

18 Commits

Author SHA1 Message Date
Stephan
7a615133ff Renormalize 2018-06-29 19:52:40 +02:00
Shannon
c90d6be8ab U4-8861 Extract GlobalSettings to an interface and expose on the standard UmbracoConfig.For settings singleton including a bunch of cleanup, getting the installer and steps to be DI 2018-04-06 13:51:54 +10:00
Stephan
c76403077f Normalize cr/lf/tab 2017-07-20 11:21:28 +02:00
Stephan
1f5c47f029 Move Plugins to Composing 2017-05-30 15:56:30 +02:00
Shannon
8127731f72 Namespace and file cleanup - Profiling --> Logging, root cache stuff moved to Cache, XmlHelper --> Xml, TypeFinder, etc.. --> Plugins 2016-05-18 23:34:56 +02:00
Shannon
fd682efdb1 Merge remote-tracking branch 'origin/6.2.0' into 7.0.2 2014-01-15 13:37:46 +11:00
Shannon
5c614a88a2 ensures webapi plugincontrollers are routed to /backoffice if [IsBackOffice] is specified 2014-01-15 13:29:17 +11:00
Shannon
273c1956ab Fixes: #U4-2343 for api controllers, already fixed for surface controllers 2013-06-18 15:46:36 +10:00
Shannon
47d70e858b Getting media picker working 2013-06-10 10:36:59 -02:00
Shannon Deminick
c8e20cf64b Fixes: #U4-2012, #U4-2005 2013-03-28 09:07:36 +06:00
Shannon Deminick
6815092b62 Changed default api routes to support multiple actions, not strict REST only methods. updated more examine mgmt. 2013-02-27 06:50:26 +06:00
Shannon Deminick
cc55107da3 Added method to WebSecurity to validate members, updated routes for umbraco api controllers 2013-02-27 00:19:48 +06:00
Shannon Deminick
7c32365bd3 moved web api controllers to namespace Umbraco.Web.WebApi and created web api member authorize attribute 2013-02-26 22:14:32 +06:00
Shannon Deminick
63159702e3 Implemented UmbracoApiController as a plugin and is auto routed 2013-02-26 03:45:39 +06:00
Shannon Deminick
d8721197b7 Fixes up pull request so that there is no breaking changes. We now type check for a new base class called
UmbracoControllerFactory to get the controller type. Adds SurfaceRouteHandler to ensure that UmbracoMvcHandler is used for all SurfaceControllers, and updates
all routes accordingly. Streamlines the RenderRouteHandler to then just look up surface routes in the route table
for posted values. This now ensures that UmbracoMvcHandler is used even with plugin surface controllers.
2013-02-19 07:30:46 +06:00
Shannon Deminick
45c335702d Updated view engine to look only in App_Plugins/ not App_Plugins/Packages/.
Updated view engine to automatically create the required razor web.config in the packages
Views folder if it is not there already.
2012-10-01 23:43:47 +05:00
Shannon Deminick
5ece0b5af0 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
Shannon Deminick
332b42aa49 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