RFC - Partial View Macro Engine

[Shannon Deminick]

I'm in the midst of implementing the Partial View Macro Engine for 6.0 release and would like some feedback on a few points below. First I'll just explain what this is: It is a macro engine very similar to the razor macro engine except that it runs natively through the MVC engine and uses the exact same objects, classes, models and query structure in the view as the MVC templates in 4.10+. Currently razor macro syntax and MVC syntax is slightly different, this will unify the syntax into one syntax so there will be zero confusion. Essentially this will supersede razor macros entirely and one day we will obsolete the entire umbraco.MacroEngines DLL. And of course this works for rendering macros in both MVC and Webforms.

So I have a few questions/comments that I'd appreciate your feedback on...

• These macros are just MVC Partial Views and therefore are currently called "Partial View Macros" (just like macros that render User Controls are called "User Control Macros"), but I would like to know if that name is ok with everyone? 
• The cshtml/vbhtml files will be stored in ~/Views/MacroPartials (this was the convention in v5). Since these views run through the native MVC engine, the views require the standard MVC web.config to exist in the sub root folder that they exist in. For example, the standard MVC web.config already exists at ~/Views/web.config so therefore I think it is convenient that these partial view files exist under the ~/Views folder. The question is, does everyone agree with this? It is possible to store these files in another root folder somewhere but I much prefer to keep the root folder of a website less polluted... plus this convention makes it nicer for this next point:
• Based on the above location convention, I'm also planning to allow Partial View macros to be stored in package specific folders. In 4.10+ we now have an App_Plugins folder for package developers to store files specific to their package. (This is also required for SurfaceController's that are shipped within a package, see http://our.umbraco.org/documentation/Reference/Mvc/surface-controllers ). So based on the feedback from the previous question, we would also allow the storage of partial views for this macro engine in this location: ~/App_Plugins/[YOURPACKAGENAME]/Views/MacroPartials

Let me know what you think.

Cheers,

Shan

[jbr...@gmail.com]

There probably isn't any feedback yet because everything looks good :).

[Shannon Deminick]

It's all implemented and working in 6.0 BUT, there is no ui tooling support in the back office. There's a task for it but not sure it will make it into 6.0

[Jonas Eriksson]

Late answer here, just wanted to say it all sounds good to me.

But I'm having a question about the name "macro". Perhaps I misunderstood the term all along, but to me "View" or partial view describes the purpose better now. If the purpose only is to render a model - and never to add any logic (other than view logic as loops and ifs).

Did you discuss the possibility to also have "scripting code items", which are supposed to have logic? Using C# (over razor or roslyn) or a DSL.

Thanks for an awesome job with the MVC in U4&6 !

[Shannon Deminick]

@Jonas: The purpose of a macro is to render a view/user control/python/razor/whatever script with available parameters inside the WYSIWYG editor. There's really not many other reasons to use macros since Umbraco supported UserControls in v3 (or whenever that was). People still use macros for rendering user controls, etc... but there's really zero reason to do so unless you are rendering the content inside of the WYSIWYG editor where an editor can edit a parameter that is injected into the macro (i.e. another selected node in the tree). I guess the only other reason to use a macro is if you want to execute XSLT to render since without a macro I'm not sure there's another really nice way to render XSLT. As for MVC Views, etc... people should really only use macros to render these for use in the WYSIWYG editor since normal partial views, child actions, are faster and provide the same functionality.

[Anthony Dang]

"People still use macros for rendering user controls, etc... but there's really zero reason to"

One other reason to use macros is caching. It's really helpful to be able to add cache to a single page component.

"These macros are just MVC Partial Views and therefore are currently called "Partial View Macros"

I think you should just call them Partial Views. Adding the word macro can be confusing as Umbraco already has a concept of a macro. The partial view is not a macro, it's a partial view. We can create a macro which wraps the partial view. But we don't have to create a macro to use the partial. So it doesnt make sense to add the word Macro,

"The cshtml/vbhtml files will be stored in ~/Views/MacroPartials"

Why not store in ~/Views/Partials. Drop the word macro. Same reason as above.

However if we want to be consistent, and use the word Macro to denote the possibility of using these files as macros, then we should rename existing xslt and usercontrols folders to MacroXslts, MacroUserControls.

[Shannon Deminick]

@anth... I think you're confused a bit :-)

A 'partial view macro' IS a macro. It's a need macros engine that you can use native mvc views with, just like you can user controls, python, razor, etc.

You can of course use normal partial views all you like, but if you want to use an mvc partial view in a macro for what use (such as to out inside the wysiwyg editor) than you'd use the new partial viewing macros.

This will supercede razor macros entirely, you would use these instead of razor macros since this unifies the syntax of all views since it uses the exact same objects and query structure as mvc (and uses native mvc to render).

Sent from my phone

[Stephen Gay]

On Friday, December 21, 2012 3:30:52 AM UTC+1, Shannon Deminick wrote:

@Jonas: The purpose of a macro is to render a view/user control/python/razor/whatever script with available parameters inside the WYSIWYG editor. There's really not many other reasons to use macros since Umbraco supported UserControls in v3 (or whenever that was). People still use macros for rendering user controls, etc... but there's really zero reason to do so unless you are rendering the content inside of the WYSIWYG editor where an editor can edit a parameter that is injected into the macro (i.e. another selected node in the tree). I guess the only other reason to use a macro is if you want to execute XSLT to render since without a macro I'm not sure there's another really nice way to render XSLT. As for MVC Views, etc... people should really only use macros to render these for use in the WYSIWYG editor since normal partial views, child actions, are faster and provide the same functionality.

I'm a bit late on that one but... the _major_ reason we're using macros in 4.7.x is not rendering in the RTE editor but cache. When we don't need cache we just RenderPage some cshtml, but the header, footer, and various parts of our sites such as the list of the most recent news items, etc. are macros just because they can be cached for 10 mins, 30 mins, 2 hrs, whatever. Great for performances.

Stephan

[Shannon Deminick]

Yup, but as i said with MVC the real only good reason to use macros will be RTE. We have an HtmlHelper extension to render partials with cache for any period specified, even by member (IIRC).

Shannon Deminick

w: http://shazwazza.com

e: sdem...@gmail.com

s: shannondeminick

t: shazwazza

--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.
To post to this group, send email to umbra...@googlegroups.com.
To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/0K6OusUq65kJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dirk De Grave]

@Shannon,

 

Part of the reason I’m still using macro’s (I’d love to get rid of it as it’s a pita when using CI) is not to render them through the RTE but to take advantage of “advanced” caching, meaning a header/footer could be cached based on parameters supplied to the macro (eg. Language of the page)

 

Don’t think I could achieve this NOW when using cached partials, right, as the docs says that if the model and/or view data is different, result will be the cached result of the first execution, which we don’t want in multilang scenario’s.

 

Or did I misunderstand all that?

 

Cheers,

/Dirk

[Shannon Deminick]

We could make it work :-)

In any case, this thread is not to discuss why we use macros, it's about the new partial view macro engine for which you can use mvc partial views for macros... Which now supersede razor macros.

Sent from my phone