Would you recommend code within a macro? (Controller/View separation)
Let's say I'm an Umbraco site administrator with developer (or at least scripting) knowledge. And I like to create a custom form on my site. And with the input I like to do something very common (adding a document, sending a mail or something). "My .php CMS site friends does that all the time :-p".
How would I accomplish that? I don't have Visual Studio. And I like to do something Contour cannot do.
Should I create a macro? Is it cool to use a macro to run some code?
I have a split mind about this. I don't want to create macros that are doing things they are not intended for (and I don't want to recommend other people to do so), and esp with MVC they are intended to be plain (dumb) Views, right? At the same time, the possibility to quickly make a macro that deals with user input or run some simple code is very useful for many kinds of sites.
I think we might have the need for some kind of "DynamicControllerMacro" or a "ScriptingMacro". A way to add a macro that works as a controller - and code it from the backend. It helps to keep a Controller / View separation + it tells "normally you should not add code to a macro, but in this type of macro it is ok".
Ideally no, but there are exceptions to every rule. If you have one macro that nicely encapsulates all the code then why not? The trouble is that if you don't really know what you are doing in the first place are you even going to know about encapsulation etc. Chances are you will cut and paste something in and high five yourself if you get it even remotely working "good enough". No thought at all will be given to the fall out that could follow. But thats using your use case. In that case I would say no. If you knew what you were doing you could do it well enough but then if you knew what you were doing you would do it in VS and C# like a good lad (or lady) should.
Noticed this is all very Razor/MVC targeted but antoher way to go that we've used in the past is XSLT include files for shared code and then just a plain old XSLT Marco which calls it. Works well, separates code from presentation and allows reuse. Not a vanilla solution though so again probably fails your use case?
Nice discussion point though, if only we where in a pub by a fire...
I like that pub environment thing, let's have a virtual one :)
Here are some use cases to consider
1) a simple view (like a navigation macro), that only depends on the umbraco content, with or without parameters. Used in the wysiwyg or directly in a template.
2) a view that collects information from other places (feeds or databases)
3) a script that gets form post and does something with either a database or the umbraco content, and then renders some result back
I think the MVC purist would only recommend 1) without creating a controller
Ok, a simple standpoint would be to let Packages (or custom programmed controllers) handle the business for the administrator with scripting habits. Contour for 3) for example.
1) a simple view (like a navigation macro), that only depends on the umbraco content, with or without parameters. Used in the wysiwyg or directly in a template.
You should use a pure razor view to do this, no controller required, assuming it's just reading content.
2) a view that collects information from other places (feeds or databases)
Well, this could be down to your descretion, because I recently wrote a plain Razor view which had a very small amount of C# in it that loaded and rendered the contents of an RSS feed, however if it required slightly more code and perhaps (secure) connection strings then I would put that in a controller action.
3) a script that gets form post and does something with either a database or the umbraco content, and then renders some result back
Definitely controller action, because you will posting back to an action.
That's how I would approach it, but obviously no.2 should be at your descretion as you technically you could do everything in a razor view, but wouldn't always want to.
Yea, I would probably say #1 & #2 make sense in a View, but #3 feels more like a controller should get involved. That said, I also have done all three in XSLT and Umbraco Razor (non-MVC) at times for better or worse.
The Umbraco Ninja package gave us access to App_Code which helped me separate some logic from the Razor views in the past. Seems like a way to edit a Controller or some code would be nice at least at a package level. Not sure how it would work. Doesn't the MVC project need to be compiled?
Thanks for everyone's input! I did not know about the ninja package before.
I have a wish for (inspired by the kids endless lists with chrismas gifts wishes...) a scripting DSL for Umbraco "actions". With roughly these modest (ahem) requirements:
Easily editable in the backend
Useful functions (like consolidate data from several documents (build a model for a view), get data from external sources, send email, add document, run external service)
Syntax control
Documentation for all the functions
Simple, familiar syntax for everything
Extensible
Rock solid (only access safe well tested methods).
Can be routed to - with a simple structure: perhaps folder path = route path
Can return views and views with models
Can return json
Lower priority
Intellisense
Can be used as a maintenance scripts
Can be hooked to Umbraco events
I know much of this can be done half okay today with Razor. But Razor has its problems. It can access everything, and as such are too powerful. Also the necessary syntax is not that straight forward (either enclose in @{ or @functions et c). Thirdly Razor is not as efficient as other solutions + its dynamic compilations can cause problems as appstarts (ok, very rarely).
The functionality is also bit hard to work (looks like much of that will be solved in the v6 api though, which is great!).
So which problems will this solve?
My vision is that this scripting language and functions should be able to take care of 90-100% of common advanced needs in a modern web site (Umbraco already takes care of all the regular stuff). And one should feel very safe using them.
We should need no .dll's for custom made forms (with or without ajax functionality), aggregating of data from outside, adding emails to a service and other common stuff.
"We have this already - just add the necessary packages"
There's a lot of great packages available and they do fill in many of the holes I'm thinking of here. But there are a few left. And the packages do not have a common api syntax, plus there is no common help page structure.
Alternatives for the "platform"
Razor - would probably be the easiest as it pretty much works already + no problem adding functionality. It could be safe guarded + have it's syntax prettified (by automatically adding some boilerplate code).
Lua - a popular scripting language which can be plugged in pretty easily, I don't know how efficient it'll be
Javascript + some host. Familiar syntax and lots of tools available, needs a host and might not be the most efficient
Roslyn - c# scripting, more efficient than Razor, CTP, and pretty much complete c# already (no dynamic though). I'm not sure I like the C# syntax as a scripting language. A bit terse compared to say Lua or CoffeeScript.
CoffeeScript + some host
TypeScript + some host
Okay? Sounds wild and half impossible? I hope so, those kinds of ideas are more fun to work with... :-)
Would you recommend code within a macro? (Controller/View separation)
Let's say I'm an Umbraco site administrator with developer (or at least scripting) knowledge. And I like to create a custom form on my site. And with the input I like to do something very common (adding a document, sending a mail or something). "My .php CMS site friends does that all the time :-p".
How would I accomplish that? I don't have Visual Studio. And I like to do something Contour cannot do.
Should I create a macro? Is it cool to use a macro to run some code?
I have a split mind about this. I don't want to create macros that are doing things they are not intended for (and I don't want to recommend other people to do so), and esp with MVC they are intended to be plain (dumb) Views, right? At the same time, the possibility to quickly make a macro that deals with user input or run some simple code is very useful for many kinds of sites.
I think we might have the need for some kind of "DynamicControllerMacro" or a "ScriptingMacro". A way to add a macro that works as a controller - and code it from the backend. It helps to keep a Controller / View separation + it tells "normally you should not add code to a macro, but in this type of macro it is ok".
What do you think?
Or is Contour meant to fill this space?
/Jonas
Ideally no, but there are exceptions to every rule. If you have one macro that nicely encapsulates all the code then why not? The trouble is that if you don't really know what you are doing in the first place are you even going to know about encapsulation etc. Chances are you will cut and paste something in and high five yourself if you get it even remotely working "good enough". No thought at all will be given to the fall out that could follow. But thats using your use case. In that case I would say no. If you knew what you were doing you could do it well enough but then if you knew what you were doing you would do it in VS and C# like a good lad (or lady) should.
Noticed this is all very Razor/MVC targeted but antoher way to go that we've used in the past is XSLT include files for shared code and then just a plain old XSLT Marco which calls it. Works well, separates code from presentation and allows reuse. Not a vanilla solution though so again probably fails your use case?
Nice discussion point though, if only we where in a pub by a fire...
Merry Christmas
Pete
I like that pub environment thing, let's have a virtual one :)
Here are some use cases to consider
1) a simple view (like a navigation macro), that only depends on the umbraco content, with or without parameters. Used in the wysiwyg or directly in a template.
2) a view that collects information from other places (feeds or databases)
3) a script that gets form post and does something with either a database or the umbraco content, and then renders some result back
I think the MVC purist would only recommend 1) without creating a controller
Ok, a simple standpoint would be to let Packages (or custom programmed controllers) handle the business for the administrator with scripting habits. Contour for 3) for example.
I've done all 3 in XSLT :)
Yeah, and it does work, but wouldn't it be better to have a built in way to separate stuff nicely?
Hi Jonas
1) a simple view (like a navigation macro), that only depends on the umbraco content, with or without parameters. Used in the wysiwyg or directly in a template.
You should use a pure razor view to do this, no controller required, assuming it's just reading content.
2) a view that collects information from other places (feeds or databases)
Well, this could be down to your descretion, because I recently wrote a plain Razor view which had a very small amount of C# in it that loaded and rendered the contents of an RSS feed, however if it required slightly more code and perhaps (secure) connection strings then I would put that in a controller action.
3) a script that gets form post and does something with either a database or the umbraco content, and then renders some result back
Definitely controller action, because you will posting back to an action.
That's how I would approach it, but obviously no.2 should be at your descretion as you technically you could do everything in a razor view, but wouldn't always want to.
Kev
Yea, I would probably say #1 & #2 make sense in a View, but #3 feels more like a controller should get involved. That said, I also have done all three in XSLT and Umbraco Razor (non-MVC) at times for better or worse.
The Umbraco Ninja package gave us access to App_Code which helped me separate some logic from the Razor views in the past. Seems like a way to edit a Controller or some code would be nice at least at a package level. Not sure how it would work. Doesn't the MVC project need to be compiled?
Thanks,
Jason
Thanks for everyone's input! I did not know about the ninja package before.
I have a wish for (inspired by the kids endless lists with chrismas gifts wishes...) a scripting DSL for Umbraco "actions". With roughly these modest (ahem) requirements:
is working on a reply...