I have an Article model and I also have a Comment model. My article show page is rendering a view from the Comment views. It is rendering a new comment form and a show comment form. If I reference a variable in the comment form, like #comment, does it look for the #comment in the article controller or does it look for it in the comment controller?
The views are independent from the controllers. Only one controller will be accessed based on your routing settings, regardless if you include code from another view.
However, it sounds like you're doing things the "wrong" way. Article-Comment is a classic example of a nested resource and is probably what you're looking for. Try this article.
Related
I am constructing a form wizard that guides the user through a form that has already been created and deployed. The model and controller should stay the same as the only thing of change is the view (guiding the user through each form field). What is the best (and easiest, if possible) way of accomplishing this task?
Even through the wizard, once the user saves their form, it gets saved to the same database via the same model and controller. From doing a bit research it seems that this is possible by obviously creating a new view, create a simple controller that extends the original controller, and routing the new controller to the new view.
Any suggestions are really appreciated. Thanks!
After doing some research, I figured out a couple of ways to accomplish my task:
A simple way is to create a wizard action within the form's controller. Have the wizard action render the wizard's view.
A better way is to create a wizard controller and have it subclass the form controller. Override the new action, and render the wizard view. This is the more preferred method because basic CRUD actions in Rails acquire REST for free. Thus, following this method will yield a RESTful wizard.
You should definitely look here:
http://railscasts.com/episodes/217-multistep-forms
Otherwise, to answer shortly, you can tell any action of your controller to render ay view you want.That's what is done in the basic scaffold controller:
render :edit
How can i render partial to string and assign content to my model attribute?
I now that is not by MVC convetion, but it's easier to predefine some content then
assign same thing from controller to controller
THanks
you should create a helper for that.
A helper is here to provide your views and controllers with those kind of things. It allows your controller to stay thin. And your model to stay a model.
I once included a render_as_html into a model. And it was ugly.
I am writing a basic blogging application in ASP.NET MVC. I have a Post model which can be displayed via View.aspx. On that page I also want to have a form to submit a comment, but as View.aspx inherits the Post model, I don't know how to have it edit a Comment model.
In your controller you can use whatever model you like. So place a form in your view which points to Post/Comment/{postid} or Comment/Add/{postid}. After you added the model to the database redirect to the previous view.
tsv - create a few partialviews for the comments (strongly typed) and create a couple of methods on the comment controller:
GetComments(int postId)
AddComment(Comment newComment)
in your post view, call the partialview either via $ajax or directly in the page.
jim
The key thing to understand here is when your page 'inherits' a class (Post, in your case), this is purely so that the Model does not need to be cast in any way.
This does not restrict you from referring to other classes within the aspx page, nor does it prevent the page from having a form which posts to another Controller/Action that inherits from a completely different class (Comment, in your case).
Maybe if you posted some example code, we could suggest ways to make it work the way that you want.
As Jim said, you can create the necessary methods in a different or in the same Controller and call <% Html.RenderAction("methodName","ControllerName") %> in your view.aspx which will still inherit the Post Model.
Then, create usercontrols for the form to submit a comment and to display all the comments.
I am creating a very simple forum as my first MVC project. My database layout is rather simple:
[ForumThread]
Id
Title
[ForumPost]
Id
ThreadId
Message
ParentId // To tell which post this post should hang on to
Created
CreatedBy
Updated
UpdatedBy
I am creating a view for the ForumThread for displaying the list of threads and to be able to create a new thread.
There is a details view of the ForumThread which shows the thread with the underlying posts.
My question is how I the easiest way in the ForumThread details view, can display a view to create a ForumPost, without having to navigate to another page first?
You could create a partial view (.ascx) which will contain the form allowing you to create a forum post and include this partial in the details view:
<% Html.RenderPartial("~/Views/Home/PostForm.ascx"); %>
As mentioned by Darin, you simply need a partial view - within that view you can implement the form, bind to a different model etc and also handle any events etc by a different controller if needs be.
It's also nice to encapsulate areas of functionality into partial views - keeps the code looking clean and if you find yourself needing to use that form again, then it follows the DRY (Don't Repeat Yourself) principle - you just add another Html.RenderPartial() call into wherever you need it.
Imagine a blog engine in ASP.NET MVC where I want strongly-typed Views. I have a Model for BlogPost and a Model for Comments. A typical page would display a blog post and all of that post's comments. What object should I pass to the View()? Should I create a Presentation Model? Maybe I'm using that term incorrectly, but by that I mean should I create a composite model just for a View(), something like BlogAndComments? Should my controller create an instance of BlogAndComments and pas that?
Or, should I somehow pass both a BlogPost and Comments object to the View?
I think you're on the right track with your understanding of Presentation Models. As to when you should create a View Model, the answer is probably 'it depends'. In your example, you can probably get away with passing the BlogPost and Comments in the ViewData object. It's not gorgeous, but hey, it gets the job done.
When and if that starts to feel ugly or unwieldy, then I would start thinking about making a View Model. I usually end up with the notion of some sort of 'Page', which includes the page title, common data, and then specific stuff for a particular page. In your case, that might end up as a BlogViewPage, which includes Title, BlogPost and List comments.
The nice thing about that approach is that you can then test that controller by making a request and testing the BlogViewPage to ensure that it contains the expected data.
In my opinion comments belong to the view as much as the post itself.
Make a BL class for your comments like:
class CommentBO
{
Guid UserID;
string Text;
}
Then you have a BO for your post.
class PostBO
{
Guid UserID;
List<CommentBO> Comments;
}
Then your model can be really simple.
class BlogModel
{
string AuthorName;
string BlogTitle;
List<PostBO> Posts;
}
Pass it to the view and render it.
You may be tempted to omit all BO and just fill the model directly from the database. It is an option, but not exactly the right one. A model is just a package of things for a view to display. These things however should be prepared somewhere else, namely at the business logics level with just a nominal participation of the controller.
I always use strongly typed views and create a presentation model class for each view or view user control. The advantage is that by looking at the presentation model class alone I know exactly what are the values that the view uses. If I were passing domain models then that would not be obvious because domain models may contain many properties that the view does not use. I would have to look at the view's markup to figure out what values it needs. Plus the presentation model usually adds certain properties that are not available in the domain model. It seems a bit tedious but I think it saves time and makes the code better in the long run.
In my opinion if comments belong to a blog post why not create a collection of comments on the blog post model? That makes perfect sense from a domain modeling stand-point and chances are whatever ORM you are using would support lazy-loading that collection which simplifies your controller logic as well.