This project is read-only.

Extending Orchard Module

Topics: Writing modules
Mar 12, 2012 at 5:53 PM

Hello everyone,

I want to ask if I can extend an existing orchard module as a different module which is only extending other module's methods. I don't want to copy the module and then extend it with my needs.



Mar 13, 2012 at 1:35 AM

Yes but it depends how it was built.

Mar 13, 2012 at 8:52 AM

Thanks Bertrand, I didn't start working on code yet but I want to extend Orchard.Widgets module, so is it possible to extend this module?

Mar 13, 2012 at 9:17 AM

In general yes, but that is a very vague question. Might help to give some details about what it is you want to do.

Mar 13, 2012 at 9:58 AM

Okay, I want something like this: when user adds new widget, I want to add new unique layer just for that widget with it's layer rules. And also on view part I want to change the backend widget view, I don't want to show layer part to user. I just need to show zones and let user to add widgets to each zone.

If it's possible I want to do this as new module, so if I enable this, widget module will work like this and if I disable it'll work like normal way.

Mar 14, 2012 at 5:43 AM

Having one layer per widget sounds like a dreadful idea. What would the rules look like? Instead, maybe you should create a rule part that would be added to the widgets and that would get evaluated at the widget level to decide if it must be shown or not.

Mar 14, 2012 at 9:22 AM

Thank you Bertrand, I was thinking like it's easier to add unique layer instead of adding rule part to widgets. All I need is just add a new layer at widgetpost method. Can you explain why it's dreadful idea and why it's better to create a rule part for widgets, because I'm already adding existing rule structure of layers and actually that's why I want to add unique layer for each widget. It might be really dumb idea but I can't find out which part I'm skipping atm, if you can help me I really appreciate this.

Mar 14, 2012 at 9:37 AM

Because you're going to end up with a boatload of layers, that will have to be evaluated all the time. It's a little like selling individually package peas.

Mar 14, 2012 at 10:03 AM

If I'm not wrong you're suggesting add rule for each widget and use one layer (default) because I don't want to show layer parts to user. In this situation rules will be evaluated at widget level.

If I add layer for each widget, again there will be same amount of rules but will be evaluated at layer level.

Is this makes performance difference?

Mar 14, 2012 at 1:26 PM
Edited Mar 14, 2012 at 3:04 PM

(removed my own stupid comment)

Mar 14, 2012 at 2:21 PM

Thanks for reply TheMonarch, but I think there is a misunderstanding.

Each layer has its own rule, only 1 widget in any zone of that layer and it must be evaluated only once and then next layer comes. Again if I'm not wrong this means 10 layers and each has its widget & rule; 10 rule evals.

If I add this rules for each widget, 10 widgets means 10 rule evals.

Mar 14, 2012 at 3:02 PM
Edited Mar 14, 2012 at 3:02 PM

Ah, yeah, nevermind. I just took a look at the docs -- have no idea how widgets and layers work :)

Mar 14, 2012 at 10:35 PM

OK, so this is clearly not how it's been designed and the workflow is not going to be ideal, but one can't always implement things the ideal way, so, well, whatever works with the limited time you have. I'm not quite sure what rule you'll put in there so that it targets only one widget, but you could create that layer, I suppose, from a handler that would listen to creation events for widget contents.