Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have the following two grails Controller. My index action of controller B should call the test action of controller A. After that call index should proceed as it would do without the call to test.
The problem is that index does not renders the view when I call test.
How can I fix that?
class AController {
def test() {}
}
class BController {
def index() {
// do stuff
forward controller: 'a', action: 'test'
// do stuff
// render view
}
}
That is not how a controller should work. If those controllers need to share logic they do to much work and that logic should be moved into a service. The service in turn can be used by both controller.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have been using asp MVC model state error when handling errors.
currently, I was using temp data as you see below:
TempData["message"] = "Successfully Added New Data.";
and rendered in all my views with forms.
I just want to ask any best practice that can be used when it comes to handling success message/status.
TIA!
If you are redirecting to another view you can use TempData collection. If you are staying on the same view, I would return current view with a flag in the model and then render it base on the value or just use ViewBag.
You should include the error or success message in the model you sent to the view.
Something like that:
public async Task<IActionResult> CityDetails()
{
MyModel MyModel = new MyModel();
MyModel.Message = "Successfully Added New Data.";
return View(MyModel);
}
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I created a product registration page using ASP.Net MVC. I need to implement the same product registration page for subsidiaries (maybe 3 or 4) with a few minor changes to the way the site looks. For example, the logo will be different and some text at the top of the page. What is the best way to use the same codebase?
The best option I could come up with is passing HttpContext.Current.Request.URL to the view and using java script to update it.
However, I know routing can be an option too.
If you will be keeping the same .cshtml view for all registration pages then i think creating a partial view for logo generation would probably help you out.
Add another variable to your view model.. maybe call it subsidiary?
public int Subsidiary { get; set; }
then create a partial view called something like _LogoPartial.cshtml and in there do a if statement on the Subsidiary variable and return a different logo based on it
#model int
#if (Model == 1)
{
<img src="something" />
}
else if ...
then in your main view call it with
Html.RenderPartial("~/Views/Shared/_LogoPartial", Model.Subsidiary);
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I m working in MVC and some one recently has reviewed my code. On some places in my controller actions I was returning to other views, for example in below code in Index action I m returning to List view:
public virtual ActionResult Index(Student student)
{
// Logic
return View("List", student);
}
Why it is not a good practice ? I did not get any idea why this is wrong. Kindly guide me so I can correct this.
There is nothing wrong with returning a different view to the default action view. The only thing I can think that might be unsettling to some is it does not following the MVC paradigm of convention over configuration.
This may make it difficult to follow someones code if they have lots of actions with names that are different to their corresponding view names i.e:
public ActionResult Index(int id)
{
//logic
return View("StupidName");
}
Convention would have you think the index action would return the Index view, although it doesn't and now the programmer has to go look for the StupidName view. This may seem harmless for one action but if someone has written multiple actions that return differently named views it can be difficult to follow the flow of the project.
Alternatively you could ask the code reviewer why he thinks it is a bad practice. Communication is key in a team.
Personally I see nothing wrong with this as long as the logic for compiling the input for the view isn't duplicated.
If you have to copy a lot of code to ensure that the model for the view is correct, and this isn't really the responsibility of your action, you'd rather redirect to the action instead of calling the view directly.
If this is not the case, or there is a very specific situation, I don't see why this is a problem.
Consider these examples:
You have a error dialog view. If the model just consists of a single property defining the message, it is no problem to call the view directly;
If you have the same dialog, but in order to create the model you have to fetch some general information from the database, have some custom logic, etc., then it is probably best to call the (or create an) action doing this all for you. Also, the number of calls to that view may matter in your decision.
Try this :
public virtual ActionResult Index(Student student)
{
// Logic
return RedirectToAction("List");
}
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have a required field, string attribute { get; set } in a class and want to set its value in Razor. Is something like the following possible?
#model.attribute = "whatever'
Close. #model is how you declare the model for your view. Your view should have a Model property, so you can do this:
#{
Model.attribute = "whatever";
}
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Can someone point me in the right direction of the correct feature in Grails to implement dynamically changing attributes in my views? For example, when an instance of a domain class is in a particular workflow step, I want certain field prompts, button labels, and data modify-ability to be specific for that step. I will probably store these attributes in another domain class, but I am not sure how to apply them when I am executing, say, the edit method on the instance of data. Is that were custom tags come in, or do I just replace all those attributes in my views with variable tags and pass the values in from the controller? A search term to get me started is fine. Thanks.
Within a controller action you can return a model (Map). The data from this model can be read within views:
class MyController {
def test() {
return [myData: 'hello', myOtherData: 42]
}
}
Within the view you can access the model in the following way:
...
<h1>${ myData }</h1>
<g:if test="${ myOtherData == 42}">
<p>${ myOtherData }</p>
</g:if>
...
If you want to return another view with a model from a controller you can use the render method:
render view: 'myview', model: [myData: 42]
See the section Models and Views from the grails documentation for more details.
Thanks for your reply #micha. Specifically, I am wondering what the best practice is for dynamically changing the visual aspects of a page(view). I think I answered my question by looking at the views from a dynamically scaffolded domain. For example, field prompts are all in the form:
<label for="last">
<g:message code="employee.last.label" default="Last" />
</label>
So you can calculate what all the prompts need to be in your controller/service, or query them from a database, and pass them in along with the data that goes into the fields. I was just checking if Grails anticipated this need and made it easier through some specific aspect of the architecture.