is there a way to debug the scaffolding template (generated in /src/template/scaffolding). Not to debug the view gsp files, but the template itself. I guess I could put some comments.. other than that..
Normally you should not have to "debug" the template as the templates work rather well.
I am thinking you are looking for tracing the data flow to make your own modifications to the templates which will lead you to using print statements. Otherwise, you are looking at using the Page Renderer.
So, there are two options I would recommend:
Print statements. This is your easy, tried and true, brute force approach. I have used it a year ago in early 2011 for a project and it works well. The downside is that it is non reusable (unless you leave your code commented out but that's a bit awkward).
This allows you to step through the "guts" of the template system and see what happens. The framework cannot "hide" anything from you really, so you get a front-row seat at what happens.
Use the grails.gsp.PageRenderer
This allows you to debug things at runtime, you can create proper tests, asserts, reusable components, the works. You are a little removed from the actual templates (as opposed to using print statements inside the templates).
Here is a link to the GRAILS Doc: Page Rendering Doc
Here is a link to an example on how to use them: Grails Goodness: Render GSP Views and...
Related
I've inherited an MVC3 project that has a large number of ASPX views that I would like to convert to Razor. This question => Aspx to Razor syntax converter? is similar to mine, and it helped me find a bunch of options for converting the views themselves, but I'm unclear on the steps I need to take in addition to converting the views.
The first known limitation of Telerik's razor-converter is "The tool only works with views and does not deal with the project structure and master pages". This tool claims to be able to convert master pages as well, but it doesn't look like anybody beyond the developer has ever used it.
I think these are the steps I need to take:
Use a utility to convert the views
Convert the master pages manually (how do I do this?)
Modify the project structure (what needs to be modified?)
Delete the ASPX files
Test the application (any specific gotchas I should look out for?)
Are these the right steps? Can you help me with my questions on steps 2 and 3?
I have only tried this on one solution and the actual conversion did a fairly good job. I downloaded the Telerik converter project, compiled it, and then converted my projects using these command lines:
aspx2razor C:\Development\MyProject\MyWebProject\*.ascx C:\Development\MyProject\MyWebProject -r
aspx2razor C:\Development\MyProject\MyWebProject\*.aspx C:\Development\MyProject\MyWebProject -r
aspx2razor C:\Development\MyProject\MyWebProject\*.master C:\Development\MyProject\MyWebProject -r
I only needed to go back to add an #include for a namespace here and there, and to add a few parenthesis to force the Razor view engine to recognize my inline code properly. This was also a fairly simple solution, so YMMV. But even if it converted 80-90% of your views successfully, it's that much less manual work which you would have to perform yourself. From here, you could also create a _ViewStart.cshtml file and make a few minor adjustments to take advantage of Razor-specific layout features. (Check out Scott Gu's post on it here: http://weblogs.asp.net/scottgu/archive/2010/10/22/asp-net-mvc-3-layouts.aspx)
The big issue I had was trying to reconcile the file changes with source control. Since the classic MVC view engine uses .aspx, .ascx, and .master extensions, I had to manually add the .cshtml files to my MVC web project and source control then remove the old versions. It wasn't difficult, just time-consuming.
In addition, you may need to add all of the necessary web.config entries to support the Razor view engine as well if your project was created using MVC 1 or 2. Projects created with MVC 3 should already have these entries in place, even if it was not originally created as a Razor site.
I am giving:
RazorGenerator
a try. The quick start guide mentions to switch the build action to 'None'. However, this means that the views are not published. Is the build action 'Content' correct as this allows publishing?
Thanks.
The purpose behind Razor Generator is that it pre-compiles your razor views, translating the markup in your cshtml files into C# code that gets executed when the view is rendered.
This can happen at design time, when you save a view, if you set the custom tool property for that view to RazorGenerator. Alternatively, it can happen at build time by integrating the Razor Generator MSBuild target.
As you mentioned, without Razor Generator you normally set the build action for your views to "Content". The markup is parsed at runtime, when the view is first requested, and a compiled view is made available in a dynamically generated assembly. If you use Razor Generator, there is no need to copy the markup around because the compiled views are already part of your web assembly. This is why you can set the build action to "None" on your views.
Other Details:
Razor Generator extends ASP.NET MVC by adding its own PrecompiledMvcEngine to the collection of ViewEngines. This is used to locate the compiled views as they're requested.
There are some properties of the PrecompiledMvcEngine that, if set, will have the engine check if the view exists on disk and use it if it is newer than the pre-compiled view it has in the assembly. This can be useful at design time, so that you can see changes made to your views without rebuilding everything.
As I understand it the RazorGenerator creates a Html helper that you can use in your views. The HtmlHelper is compiled as a class with an extension method. The view that it is based on should not be published since you're not supposed to use it directly within your project. Thus the view should have build action set to none, exactly as stated in the quick start.
Step 3 in the quick start illustrates how you use the created Html helper:
The nested file will be compiled with your project and can be
referenced as a regular helper. e.g. Html.WriteSpan("Hello world")
Ok so this is a little random but..
Using MVC 3 (with Razor view engine) with Knockout.js which uses jQuery Templating i've come across a little problem i'm sure is possible to solve.
In order to use jQuery-Tmpl you need to supply a template in
<script type="text/html">
...template elements go here...
</script>
Now the problem is that the razor view engine doesn't seem to generate HTML inside of these specific script tags. It handles standard html, (script type="text/javascript") fine but appears to just not do anything with the aforementioned script tag.
Does anyone know how to get around this issue i.e. how to use MVC 3 Razor with jQuery-Tmpl?
There is a pretty good solution in this blog post: http://www.wiredprairie.us/blog/index.php/archives/1204
This creates a "template" helper that emits the script start/end tags.
Otherwise, I have some ideas for putting templates in external files, which would be another way to avoid this issue. It involves storing the templates in .html files and injecting them into the page into script tags. There are certainly many ways that this could be accomplished though on the client or server side, just a few ideas.
A more general approach if you want to keep things in the document is using #Html.Raw to output html without affecting the edit-time syntax state.
For example:
#Html.Raw("<script type='text/x-dot-template' id='awesome_template'>")
<!-- insert some awesomeness here -->
#Html.Raw("</script>")
I happen to like the helper method suggested above a little better, but it has not always been something I was able to implement, so this is an alternative with its own benefits (namely clarity over ease of use and terseness)
Duplicate: Unit Testing the Views?
Is there any way to unit test View?
I am sure that we can test Model & Controller but don't know how to unit test View?
Is that worth testing View?
You can enable compilation of MVC views. That helps a lot. Otherwise, I don't think it is worth it. After all, the there are only two things that you are interested in. Does view compile and do you get any exceptions (null, out of bounds exceptions, or similar)?
There are some folks who claim that you should not include any logic in view. Write helpers for anything. In that case, compilation is pretty much everything you'll want.
We decided to invest into WatiN testing. It tests views and it tests the whole app at the same time. Has some nice helpers, but requires constant maintainance.
Haven't views abandoned code behind now? So what are you going to test? If you are testing the controller, then you just need a succesful view result to show that the view works. Rather than going to the trouble of pre compiling views or whatever, this will start to drag any sizeable project down in terms of continuous integration, and build.
From what I have read (in Pro ASP.NET MVC Framework by Steven Sanderson), views are not considered worth testing. ASP.NET MVC viewes can be generated using various engines, e.g. the default lightweight ASPX, or for example http://www.stringtemplate.org/. For ASPX output you might run some HTML syntax checker tool, and for other view engines the fact that the views compile successfully should be a good enough test ;)
I do not see the point of unit testing the views, since they don't contain much logic. You can however to some integration testing/UI testing using a tool like WatiN.
Example of a test written in WatiN:
[Test]
public void SearchForWatiNOnGoogle()
{
using (IE ie = new IE("http://www.google.com"))
{
ie.TextField(Find.ByName("q")).TypeText("WatiN");
ie.Button(Find.ByName("btnG")).Click();
Assert.IsTrue(ie.ContainsText("WatiN"));
}
}
You should not try to test everything using tool like this. Select some key functionality of the application, and write test for them.
For those who do not see the value in testing views.... How can you be sure that the view has the right attributes on elements, or that it is bound correctly?
Many answer "at a higher level" (such as running the site and using tools such as selenium or equivalent).
However these techniques make it virtually impossible to prove that the source of the error is in the view itself and also require massive changes to the server side code so that the views can be rendered in a targeted manner.
I have just started playing with the ASP.Net MVC framework, and today I created a simple UserControl that uses some CSS. Since the CSS was declared in a separate file and included in the View that called the UserControl, and not in the UserControl itself, Visual Studio could not find any of the CSS classes used in the UserControl. This got me thinking about what would be the most appropriate way of dealing with CSS in UserControls.
Declaring the CSS in the View that is using the UserControl gives more flexibility if the same control is used in different contexts and needs to be able to adapt to the style of the calling View.
Having the UserControl supply its own CSS would lead to a more clear separation, and the Views would not need to know anything about the HTML/CSS generated by the UserControl, but at the cost of a fixed look of the control.
Since I am totally new to the framework, I'm guessing people have already come to some good conclusions about this.
So, would you have the UserControl handle its own CSS, should it depend on the CSS declared in the calling View, or is there another, better solution?
If you look at a skinable toolkit like Yahoo UI it documents the classes used by each control and then provides a single skin file for the entire toolkit. By swapping out the single skin file you can change looks for your entire site.
I would assume that 99.9% of the time you would want to custom skin your controls and not have them come predefined with a look and feel.
As an example here are the CSS defines for Yahoo's TabView control
It should always be in your global CSS really. If you pass this on to a designer, you dont want to have to explain which control defines x style, etc.
A quick point... it's ok for your Views to be aware of HTML... that's what they are for. What I would recommend (if you want to be ubber cool), is to add a parameter to your "MVC UserControl" that specifies the class name. Example:
<%= MyHelperClass.Marquee("This text will scroll!!!", "important-text") %>
I'm of course pretending that "important-text" is the class name that I want to add to my control.
I am assuming that when you say "UserControl", you're referring to an example like in that link above.