Our development team has a number of semi-technical users that act as intermediaries between our developers and domain experts. One of their tasks is building forms using a very clumsy, antiquated system that makes their job much harder than it should be.
I'd quite like to create toolbox controls similar to the standard HTML controls that simply render an MVC partial e.g.
<% Html.RenderPartial("UserProfilePartial", ViewModel.UserProfile); %>
but presented as a friendly toolbox item with an icon. This way our developers can create reusable form elements that they can simply drag and drop around in the design view. While this may sound like anathema to most developers, they're quite excited about the possibility.
Creating a custom server control does not appear to be the right approach, as it always insists upon adding a register statement to the head of the view, and it also seems to insist upon rendering controls with the <cc{0}...> prefix.
How can I create a Toolbox control that just renders arbitrary markup?
I blogged a while ago about how to write declarative ASP.NET controls for use with ASP.NET MVC. If you want a design-view experience then controls are the only option since that's the only code you get to run in the VS designer.
Having said that, Darin's two links are definitely the most MVC-friendly way to go. Some folks don't like seeing controls in their MVC view pages. Then again, it's strictly a matter of opinion, it's neither right nor wrong, nor is it even a bad practice. So if it fits your team's needs, go for it!
Related
With the asp.net MVC, we see a lot different view engines, like Razor, spark, webform etc.
I thought the idea of MVC is separating of data and view, I assume view part should be something that allows a designer to do some work, even after it is created by a developer. But I see now most if not all view engines introduce new syntax, not stick with html. The old web form, you can use "view designer" to see how a page looks like even with some code blocks, designer could at least move blocks and html elements around, but now with engine like Razor, you cannot even view a page in designer mode. So I don't quite get what is the point?
This came to me when I tried to search for a server side templating that allows end user do some changes on the page. I perfer something stick to pure HTML, maybe Spark is the one, but I am not sure. Please someone can give me some idea.
Thanks
Views are meant for that. It will not static design. Markup will be generated on fly.
If you take razor as an example, you will have the combination of c# and html as code in view page. So, as you may be able to understand now, you cannot see the actual design until the c# and html execution goes hand-in-hand.
Hope it clarifies a little!
I have a CMS website written in aspx 2.0 that allows users to build up pages by dropping controls on a page and setting properties (reflection on the server side) and events (client side js). The render engine knows what property to call on each control to find out what to save into the database. I went through all the pitfalls of control re-hydration and lack of proper ids on the controls and really struggled to make the solution SEO friendly which currently is partial at best. Also suffer from viewstate getting huge so I have started to look at MVC as a better way forwards for the next version. The final design of the page is only set when the user decides to promote it live, and may make many changes per day.
A typical page may have many textbox controls, radio button groups, checkbox groups, dropdownlists and images. Also we have a few of our own controls that we reflect at runtime into the solution.
From my initial research into MVC, this looks to have been written to avoid these types of issues and not try to hide the html which looks very promising as well as giving final markup that is much more cross browser friendly.
Now the question - since the requirements are to generate dynamic pages with dynamic html controls, is this a step too far for MVC and I should stick with ASPX, or is there a way to generate the dynamic content which would be suitable for a non technical person to be able to do?
Really appreciate any guidance before I jump in with both feet :)
Thanks
Mark
I'm assuming by aspx 2.0 you mean WebForms? It's really not a question of if MVC is capable of doing what you need - it is capable, and in
my opinion it's more capable. However There are some major differences between WebForms and MVC check out this post for more on that topic: MVC versus WebForms.
I hope this helps. Without more information on exactly what you're trying to accomplish, there's not much more I can say. Consider asking more specific questions with some code examples.
Some of the main advantages of MVC: Clean HTML, No ViewState written on the page, easier to support html5 and thus SEO as well.
For me, since I used MVC 3 years ago I don't even want to touch WebForms thesedays.
Btw, if you want CMS + MVC, why not use Orchard rather than building yourself?
http://paulmason.biz/?p=118
I am trying to learn ASP.NET MVC by porting my current app written in ASP.NET Webforms to MVC. For starters, I am planning to use the Default View Engine (WebFormsViewEngine) as most tutorials/examples and the book I have use that as the default.
However, I know for sure that I do not want to use WebformViewEngine in the future and once I have a grasp of MVC, I would like to switch to a different ViewEngine (Spark seems to be interesting)
Would this be a simple change or would it take a lot of effort in terms of coding new views? What I basically want to know is which would involve more effort? Learning an alternate ViewEngine now or switching later?
OK - firstly you've got a decent sized investment in WebForms I'm assuming, and by virtue of that, you'll have a fair amount of user controls on existing forms etc. I'm sure you already know that this in itself is going to be the most work in the process, and has nothing to do with which view engine you choose because even the WebForms MVC view engine doesn't support user controls directly. This part of the work will still need to be done regardless...
Secondly, you probably are looking for a view engine that can take most of your other view built in logic and code (i.e not user controls), and by that I mean the stuff between the bee-stings ( <%= blah %> ).
Obviously the WebForms view engine does support this same syntax, but you also say that you specifically don't want to use the default WebForms view engine. Well you'll be happy to know that Spark also supports the <%= blah %> syntax, and this has been done specifically to support migrations like this.
Your best bet before deciding would be to watch this recent video here, and see how Louis goes through the simple WebForms-based MVC solution and it keeps running correctly even though the code still contains <%= blah %> syntax.
This support makes it much easier to transition and when you're ready you can then start moving your code to the more recommended way of using ${blah} syntax instead. But this can be done at your own pace whilst the overall functionality still works.
Hope that helps,
All the best,
Rob G
Looks like you can have a mixed bag of view engines in your application... link
Also check out this post from Phil Haack that shows using partials using different view engines to render on the same page.
This would allow you to simply switch over to the new syntax and not need to rewrite all of your existing views.
It should be as simple as calling
SparkEngineStarter.RegisterViewEngine(ViewEngines.Engines);
SparkEngineStarter should be a class in the Mvc part of Spark.
The documentation of spark is actually pretty good. Check out the section on getting it to run in ASP.NET MVC
My group is working on a new web application and is considering using MVC. However, there are members who would rather include pages than use master pages. Is this possible to do in ASP.NET MVC? In the small amount of time that I've poked around with MVC I have not yet been able to figure out how one might accomplish that.
Why the preference?
Having used both in the past, Master Pages are much easier to use. You just have to get over the (very small) learning curve.
ASP.NET MVC doesn't force you to do either one though...
If you like the Include method, then you would probably feel most comfortable using Partial Views to provide the same functionality. You would just add the Partial Views to each page instead of including another page.
No. It does not force you in any way.
You should really avoid server-side includes with anything newer than classic ASP. They're more difficult to debug, IIS has a hard time finding correct line numbers when there's a problem, etc. Also, I haven't looked at the order in which SSIs are processed in the request pipeline - they may not work at all with ASP.NET.
If you're moving into MVC, use RenderPartial() or RenderAction() instead. These perform essentially the same function as a server-side include, but are more inline with the spirit of the framework and provide some additional benefits, like passing models without having to declare a global variable (which should also be avoided, and I'm not sure if it is even possible under .NET scope rules).
And, no, master pages are not required, but you really should use them. Using includes to build your page layout works, but only if you don't and won't need to radically change the layout of your site at any point in the future. I'm in that boat now with a 350k line classic ASP app which used very nicely structured code and #includes to create the page layout. That was the best solution available at the time, but it's causing me a lot of headaches now (10+ years later).
With a master page you can move your ContentPlaceHolder blocks anywhere you want, whereas with #includes the final page really determines the format by the order in which the includes are placed. This also makes it pretty straightforward to create a mobile version of your site - you can create a mobile-specific master page and use the same content views.
Its a matter of choice,but for consistent look and feel across the web application, master pages give you just that. You have to take the team through the learning curve of good master page design, not only would it be useful for the current project at hand but also future projects. Good luck!
I would rather opt to go for Master pages due to the ease of use and built in support in MVC for this.
If you want to know more about it check out this tutorial: Creating Page Layouts with View Master Pages.
Grz, Kris.
Like many others on this site I am considering a move to ASP.NET MVC for future projects. Currently my sites are running the traditional ASP.NET 2.0 Web Forms, and it works OK for us, so my other option is just to stick with what I know and make the move to ASP.NET 3.5 with the integrated AJAX stuff.
I'm wondering about how user controls work in ASP.NET MVC. We have tons of .ASCX controls, and a few composite controls. When I work with web designers it is very easy to get them to use ASCX controls effectively, even without any programming knowledge, so that's a definite plus. But then of course the downsides are the page life cycle, which can be maddening, and the fact that ASCX controls are hard to share between different projects. Composite controls are share-able, but basically a black box to a designer.
What's the model in ASP.NET MVC? Is there a way to create controls that solves the problems we've dealt with using ASCX and composite controls? Allowing easy access for web designers without having to worry about code being broken is an important consideration.
To implement a user control you do the following call:
<% Html.RenderPartial("~/Views/Shared/MyControl.ascx", {data model object}) %>
You may also see the older syntax which as of PR5 is not valid anymore
<%= Html.RenderUserControl("~/Views/Shared/MyControl.ascx", {data model object}) %>
You will always have to worry about code breaking when moving from Web Forms to MVC, however the ASP.NET MVC team has done a great job to minimize the problems.
As Nick suggested, you will indeed be able to render your user controls, but obviously the page-cycle, pagestate and postback from traditional ASP Webforms won't work anymore, thus making your controls most likely useless.
I think you'll have to rewrite most of your complex controls to port your website to MVC, while simple controls which, for instance, provide only formatting and have no postback status, should simply work.
The code provided by Nick will simply work in this case.
And about sharing between more projects: I think controls will be more like "reusable HTML-rendering components" that can be shared across a website, rather than "reusable code components" with logic (like WebForms controls). Your web logic will/should be in the pages controllers and not in the HTML controls. Therefore sharing controls across more projects won't be so useful as in the WebForms case.
MVC has different page life cycle compare to your user control.
You may consider this to re-write.
The aspx is the view. You still need a re-write, the syntax is different.
JavaScript will work. But I hardly find the WebControls will work. Because MVC does not have viewstate and postback anymore.
For the code behind (aspx.cs) you need to convert that to be a Controller class.
Page_Load method will no longer works. You probable leave it to Index() method.
Model is simply the entity classes that your code behind consume.
Conclusion, it's a total rewrite. Cheers. Happy coding.
Yeah, you can do RenderPartial. That's a good start. But eventually these guys will need logic and other controller type stuff. Be on the lookout for a subcontroller implementation from the framework team. There should also be something in MvcContrib soon. Or roll your own.
Edit: I just posted about this here: http://mhinze.com/subcontrollers-in-aspnet-mvc/