This project is read-only.

Orchard dynamic layout platform

Topics: Announcements, General, Writing themes
Mar 9, 2011 at 1:50 AM
Edited Mar 9, 2011 at 1:51 AM


I was struggling for the last couple of days with building the full-featured Orchard dynamic layout platform, which I'll try to deliver in the next few days. Featuring:

  • Allows users to define the layout structure via Dashboard (zones, nested zones, flow of the nested zones and such)
  • Easy theme creation, as no Layout.cshtml file is needed - only styling. No Layout.cshtml because the whole layout is defined by user:)
  • Theme creators can provide preexisting (and maybe already styled and scripted) layout zones, which can be further customized by users (by adding and nesting child zones). Those hardcoded zones can come from the Theme.txt file or from the simple IZoneProvider implementation (which gives more options)
  • Dynamically generated CSS you can download, modify accordingly, upload and get your site styled!
  • (Future) For the next release I'm thinking about adding layout customization for different layers.

What do you think?



Mar 9, 2011 at 4:57 AM

Wow, hanging for a squiz at this.

do you have a day job?

Mar 9, 2011 at 1:25 PM

Yes, I have. Fortunately it's mostly Orchard-related, so projects like this can be born in the meantime:)

Mar 9, 2011 at 1:56 PM


Mar 9, 2011 at 6:27 PM

Do you intend to send this as a contribution to core or as a separate module?

Mar 9, 2011 at 8:06 PM

Good question, as I haven't really thought about that yet. Both ways have their pros and cons. As I think about it right now, I'd better stick to the separate module way for now. Of course I'd be glad to have it appear in the core, but maybe in the 1.2 release:) I realise that there will be a lot of changes, new feature proposals, and also a lot of testing, performance issues etc. in the incoming days/weeks. If it would become stable enough in terms of feature list and performance I'd be very happy to contribute it.

- Piotr

Mar 18, 2011 at 5:32 PM
Edited Mar 19, 2011 at 12:09 AM

I just installed your Frooth module on a server where my very own DesignAreas module already was installed -- the DesignAreas module of course has no knowledge of Frooth because I just came around the existence of Frooth half an hour ago.

But now I have a "Circular component dependency detected" exception (and the entire site is dead):


[DependencyResolutionException: Circular component dependency detected: 
	-> Orchard.ContentManagement.Handlers.IContentHandler[] 
	-> Orchard.ContentManagement.Drivers.Coordinators.ContentPartDriverCoordinator 
	-> System.Object 
	-> Orchard.ContentManagement.Drivers.IContentPartDriver[] 
	-> Orchard.Widgets.Drivers.WidgetPartDriver 
	-> Szmyd.Frooth.Services.FroothWidgetsService 
	-> Szmyd.Frooth.Services.FroothZoneManager 
	-> System.Object 
	-> Szmyd.Frooth.Providers.IZonesProvider[] 
	-> Szmyd.Frooth.Providers.FroothAlternateZonesProvider 
	-> Szmyd.Frooth.Services.FroothZoneService 
	-> Orchard.Widgets.RuleEngine.RuleManager 
	-> System.Object 
	-> Orchard.Widgets.Services.IRuleProvider[] 
	-> DotNetFabrik.OrchardModule.DesignAreas.Handlers.DesignAreaRuleProvider 
	-> DotNetFabrik.OrchardModule.DesignAreas.Services.DesignAreasService 
	-> Szmyd.Frooth.Services.FroothWidgetsService.]
   Autofac.Core.Resolving.CircularDependencyDetector.CheckForCircularDependency(IComponentRegistration registration, Stack`1 activationStack, Int32 callDepth) +420
   Autofac.Core.Resolving.ResolveOperation.Resolve(ISharingLifetimeScope activationScope, IComponentRegistration registration, IEnumerable`1 parameters) +182

Any clue what could be wrong? There very same message occurs when just running orchard.exe command line.

Mar 18, 2011 at 6:09 PM


Thanks for trying to use my module. Unfortunately it's still alpha (I'm working on a first stable release right now).

The circular dependency, from what I see in the stacktrace you provided is because of the widgets service trying to reference itself indirectly.

  1. You have your own rule provider (DesignAreaRuleProvider), which references the IWidgetsService
  2. In my module there is FroothWidgetsService, which overrides the default Orchard.Widget.Services.WidgetsService. 
  3. It depends on FroothAlternateZonesProvider, which references the RuleManager. The RuleManager dependes on IRuleProviders.
  4. One of those providers is your provider (DesignAreaRuleProvider), which, through DesignAreasService depends on IWidgetsService (FroothWidgetsService), and the circle starts again...

 This is the exact circle:

  1. (...)
  2. Szmyd.Frooth.Services.FroothWidgetsService ->
  3. Szmyd.Frooth.Services.FroothZoneManager ->
  4. System.Object ->
  5. Szmyd.Frooth.Providers.IZonesProvider[] ->
  6. Szmyd.Frooth.Providers.FroothAlternateZonesProvider ->
  7. Szmyd.Frooth.Services.FroothZoneService ->
  8. Orchard.Widgets.RuleEngine.RuleManager ->
  9. System.Object ->
  10. Orchard.Widgets.Services.IRuleProvider[] ->
  11. DotNetFabrik.OrchardModule.DesignAreas.Handlers.DesignAreaRuleProvider ->
  12. DotNetFabrik.OrchardModule.DesignAreas.Services.DesignAreasService ->
  13. Szmyd.Frooth.Services.FroothWidgetsService

To solve this problem you should make your IRuleProvider not depend on IWidgetsService (directly or indirectly). Maybe you could move some functionality to other object, such as filter?

In general - the circle has to be interrupted somewhere, eg. one of the injected dependencies has to be handled differently, so it won't be necessary to inject it through constructor.

I'll try to figure out some more specific workaround to this.


Mar 18, 2011 at 6:32 PM

You might want to try injecting a Work<T> rather than a T. It might help by delaying injection. Depending on the nature of the ciruclar reference (whether it's passive or not) it may unblock you.

Mar 19, 2011 at 12:22 AM

Thanx for explanation why that could happen by just using pieces which don't know of each other.

I meanwhile solved the problem by splitting the service into smaller parts so my IRuleProvider does not require IWidgetService indirectly anymore. Will give the Work<T> approach a try the next time such things happen.

I did not notice whether FroothWidgetsService really was replacing the original WidgetsService since a found no AutoFac module like it was being used to replace the NavigationService in your HierarchicalMenu module.

I wonder if the Layout.cshtml render template in your module should already be used in some magic way since it is no theme? What is the priority for render templates which exist in multiple active features? Would it be deterministic when I add a second Body-html.Editor.cshtml file to another module beside TinyMce? What if I place a third into the active theme -- will it have highest priority?

[Every feature I come across rises new questions.]

Mar 20, 2011 at 1:08 PM

BTW: Work<T> does not exist in 1.0, yet.

Mar 20, 2011 at 8:59 PM

Lazy might also work in the meantime.