This project is read-only.

Resuable "widgets" best practice

Topics: Customizing Orchard, Writing modules
Sep 2, 2011 at 10:12 PM

Hi all!

I was wondering what is the best way to build (by other module developers) reusable UI components ("widgets", but not Orchard widgets). I mean such a "widget" could be a controller action with some code that returns a partial view. This action then could be rendered in a view with the Html.RenderAction() helper.

Although the approach above seems fine and I would definitely make it in a regular MVC project, is this the "Orchard way" of correctly doing this?

Thanks in advance!

Sep 2, 2011 at 10:19 PM

Not sure how this is not a widget. Custom shape maybe?

Sep 3, 2011 at 12:33 PM

Looks like shapes are exactly what you are looking for. Shapes can be created from code or as a .cshtml file. Take a look at CoreShapes.cs and /Views folder in Orchard.Core project - there are a couple of good examples of both approaches there. 

You can display shapes from .cshtml files like: @Display(New.MyShapeName(MyParam1: sth, MyParam2, sth2))

Sep 3, 2011 at 1:09 PM

Thanks both of you for your answers!

@Pszmyd: Thanks for your detailed reply! I looked through various implementations of shapes (and various descriptions about shapes), including the ones you mentioned and others in modules. I have the idea that shapes are not meant to have  a "code behind", or any complex background logic (like talking to a database), they just server to display data they get (and maybe perform some view-related logic like the Pager shape does). Anything more complex should be a real widget. Am I understanding this correctly?

Sep 3, 2011 at 1:47 PM

It's not about complexity but rather about the purpose.

Shapes are the basic UI building blocks in Orchard and thought to be generic enough to be reused in other places in code (by developers). Widgets are more complex, specialized and their advantage is easy GUI-based management and possibility to be extended with other content parts (by an ordinary user).

Yes, shapes are only supposed to build a display for some arbitrary object/s without complex processing of that data (which should be done by the logic layer). Logic included in shapes/views should be only about displaying, as the SoC principle tells. But you are free to prepare data to be pushed into shapes inside shape lifetime events - OnCreating/OnCreated etc (take a look into CoreShapes.cs Discover method for example). This would help you achieve the "code-behind" behavior.

Sep 6, 2011 at 9:23 PM

Thank you very much, that cleared things up!

Sep 8, 2011 at 11:38 PM

Chris Bower describes a nice approach of using a Shape method with a view (not the topic of the article, but anyway): Shape Method Caching