What is the actual difference between the terms setModel() and getModel() in tabbed panes (for blackberry).
BB docs notices these as being:
getModel()
Returns the PaneManagerModel associated with this view.
Does this mean i get to access the methods and variables of code inside the pane associated with that model?
setModel()
Lets you associate a PaneManagerModel with this view.
Does it only give access to set the usage of that pane for display in another pane?
Re edit:
I have used this piece of code to invoke method held inside another pane from first pane and now i want to refresh the display.But dont know how.Please guide.
model.getController().getModel().getPane(1);
//model.getPane(1).getPane().getScreen().getUiEngine().updateDisplay();
model.getPane(1).getPane().getManager().invalidate();
What to use get or set?
getModel() is a function that returns the PaneManagerModel field of the view.
setModel() allows you to set a PaneManagerModel field for your view.
This is a standard OO set/get situation. Here is a demonstration of it (so you get what it actually is, it doesn't necessarily work exactly like so)
public class View
{
private PaneManagerModel model;
public PaneManagerModel getModel()
{
return model;
}
public void setModel(PaneManagerModel me)
{
model = me;
}
}
Edit: use set. Get only lets you get what is inside. If you want to put something new in, use set. If you want to trigger code that is only executed while you're setting but you want to keep the same PaneManagerModel use setModel(getModel()); though it is ugly.
Wrong and wrong
getModel gets you the underlying PanelManagerModel. The Model handles data, and is totally separate from methods / code in the pane
setModel lets you set the underlying datamodel of your panel, but has nothing to do with display, except for setting the elements to be displayed.
This is strictly about the data items in your tabbed pane
It's all related to the concepts of "setter" and "getter".
A "Setter", which in this case is setModel(), lets you set a new Model on the View. On the other hand a "Getter" allows you to obtain a certain property of a certain object. In this case the getter gives you access to the currently set Model of the View.
Related
Is it possible to safely programmatically get a list of fields that are in the View that has just posted back to a Controller?
I noticed a problem with the default implementation of the scaffolding, in
DB.Entry(model).State = EntityState.Modified
DB.SaveChanges()
The problem is that if I haven't included a field to be edited in the view, it is being overwritten by the default value of the field that .NET assigns when creating the object. eg. If I have a User class with ID, Email and PasswordHash and I want to allow the user to update their Email address only, if I don't include anything for the PasswordHash field, it is reset to NULL as it is passed into the controller as NULL. At the moment, I am working around it by retrieving the current object from the database and updating only the fields which I know are in the View from the model passed in. That isn't such a problem for a small table, but I would like to have a general solution that I can apply across the board, especially for large tables which may during development and I don't want to have to update the code every time.
I know that I could loop through the POST variables and examine them to see what has been posted, but that creates a security issue as the user could inject additional fields that I don't want them to edit. I suppose I could explicitly exclude ones that I don't want them to edit, but then again, I would rather not have to list those if I can avoid it as it is an extra thing to maintain.
I think that there are 2 problems here and I'm not sure either are solvable...
Getting the View that posted back
Establishing which fields are included in that View (I might need to construct it again temporarily to do that?)
I suppose that I can probably get away with ignoring the first one as I could just only ever use that method on the Controller for a single View. That is still a little less neat than I'd like, but it does reduce the issue to just establishing which fields are in the View.
If a view needs only certain properties, create an interface with only those properties. Use this interface in the HttpGet and HttpPost methods.
And then you can use something like AutoMapper to map the viewmodel to your entity.
I'm working a feature in the application where model will be dynamic in the sense that any settings data could be displayed and the view will get the model based on what tab they clicked on. I use Hidden field to store what the settings name was because they are same as model name. for ex., if tab1-> Settings1 then Model is Settings1[already exists in the Model].So I used # model dynamic in View and used #Html.EditotForModel() to draw the required UI based off the model. My problem is when I do HttpPost on Edit currently I'm using FormCollection to read the data on that page when I declare the model name in the param it will get it for me but I don't know which model is coming back other than by the Hidden variable and I need it because the Model validation is broken because of this issue. Any help or feedback is appreciated? I can give more details if required? Has anybody crossed this issue before??
Dynamics can be a good thing and a bad thing. Using them on models that have a common interface in a controlled manor is best.
There are different options that you can look at:
1)
Have you tried making the action method accept a dynamic type? That might be the easiest way.
You might have to set up a casting helper to cast the object to the correct type based on the hidden field.
2)
I have a similar idea in some code, but I created a viewmetamodel class that contained all my types as nullable properties. My action method accepts this viewmetamodel type and validates the properties that are not null.
In line with this, if your data is not too large, then you could load all the settings tabs and use Jquery apply the tab with on click.
3)
You could also create #sections or use EditorFor(c=>c.settings) for each tab. That way each tab will load a type safe object. You would need to create controllers for each.
I would say pick the easiest method for you. I hope that this at least gives you some ideas.
I'm new to X++, and I want to put an unbound
checkbox on a tab in the sales header form
(SalesTable). When the configure line button is
pressed on the bottom half of the form for a sales
line, I need to have code in that other class
check the on/off status of the unbound control in
the SalesTable form and do something. I really
don't need the database to record the status.
The current status is I've placed the checkbox on
the form, see it on the display and can click it,
but can't refer to it.
How do I refer to the unbound
control in the SalesTable form from another class
and, is this the right approach?
You don't refer to the unbound control from another class, it is not the right approach.
Rather inform the other class when the unbound control is changed. You do that in the modified method of the checkbox control:
boolean modified()
{
boolean ret = super();
;
salesTableForm.parmSpecialAction(this.value());
return ret;
}
In this case the SalesTableForm is informed of the change of the checkbox by calling a method parmSpecialAction (name arbitrarily chosen).
The other route (you indicated in the question) would be to inform the class about the existence of the control and let the class call control.value() directly. However this will usually make the form and the class tightly coupled, which is not what we want. The controls belongs to the form where they were born and should not be passed around.
Ironically the SalesTableForm.enableUpdateJournalButtons method violates this rule, as it accepts button controls as parameters. The correct approach would be to calculate (and cache) the enableWathever values in getter functions, then let the form call the getters and enable or disable its own buttons.
I was doing a code review today and seen that someone having a view model classes that besides of data contains different methods, like
GetTable, GetPdf, LoadSomeData etc.
I personally didn't like it, since prefer to have a "plain" view Model classes, containing only the properties and put logic either into Controller either additional Service.
But on review I was not possible to find good arguments for that.
What do you think, is it a good way (style) of having a logic in view Model classes? What are pros/cons?
EDIT: It was ASP.net MVC2 application.
EDIT: Example (just from head) of such code..
public ActionResult SomeAction()
{
var model = new ViewModel();
model.LoadSomethingFromSomething();
model.AnotherMethod();
return View(model);
}
The principal of separation of concerns and the single responsibility principal dictates that the only "logic" that should be contained in the view should be that which manipulates how the view displays the data. Everything else should be in the controller. Semantically the view does one thing - displays data, anything unrelated to displaying said data - i.e. manipulating data, formatting data, loading data, converting data etc. should be handled by the controller.
In the real world, we don't always have the luxury of idealism, but in the ideal world, that's the way it should be. The principal of least surprise says that code should be in the least surprising place to find it. If I (as a code maintainer) need to fix something, I need to be able to find it quickly - if it's not where logic dictates I would find it, it provides unnecessary hindrance to my completing my tasks quickly and efficiently.
If GetTable pertains to loading a table construct (i.e. an HTML table) for the view, then perhaps it is relevant, if we're talking about getting table data from a database, then it is not.
I used to subscribe to the idea of totally "dumb" models.. I.E ones that don't do ANYTHING. However after using that idea in practice I found it wasn't ideal. I now subscribe to the idea that viewModels should know about how to create themselves from other objects.
I.E.
public ActionResult SomeAction(int? id)
{
var serviceModel = _myService.Get(id ?? 0);
var model = new ViewModel(serviceModel);
return View(model);
}
Basically, rather than adding methods to your model, create several constructors that take in objects used in that view model's creation. This frees up your controllers & service from knowing anything about how the viewModel works (meaning there is no object mapping code cludging up everything).
Then, to get an object out of the viewModel, you can do the following:
[HttpPost]
public ActionResult SomeAction(ViewModel model)
{
_myService.Update(model.MapToServiceModel() );
return SomeAction(model.id);
}
Your question feels vague to me. When you say view model, do you mean a view specific model constructed from your domain's model that a view consumes? In that case, I agree the view model should be pretty simple overall. The view shouldn't have to "think" much (ideally, it shouldn't "think" at all). Calling methods from a view (that aren't defined in helpers), even branching in a view, is a code smell to me.
IMO, controllers should also be thin and light. I like the real bulk of my logic to be in my models and also in the data access layer. Just depending on what type of logic we are talking about.
In handling a 1--->0...1 relationship, I'm trying to use a separate partial view for the 0...1 end. I'd like to use RenderPartial() rather than RenderAction(), for the sake of efficiency.
Is it possible to gain access to the containing view's model data from this partial view, in order to access the PK/ID of the main object?
Is this just a sad attempt at a hack that shouldn't even be considered in the first place?
Does anyone have a better example of how to handle this 1--->0...1 relationship using MVC?
Sort of.
If you don't pass a model to RenderPartial, the parent's view is passed by default. So you can access it via the partial's Model property.
But if you do pass a model, then no, the partial can't see the parent's model, because it sees its own instead.
Is this just a sad attempt at a hack that shouldn't even be considered in the first place?
I'd say "kludge" rather than "hack", but yes, probably. :)
First ask why you need the PK?
However I'd have a ParentID property in the child model if I really needed to have it. Then you just set it before you send it off.
foreach(var vChild in Model.Children)
{
vChild.ParentID = Model.ID;
Html.RenderPartial(ViewName, vChild)
}
If you needed ALL of the data from the parent then you can have a Parent Property instead and set the whole property.
This logic would be better suited to be in the Model itself however like this:
List<Children> mChildren;
public void AddChild(Child tChild)
{
tChild.ParentID = this.ID;
mChildren.Add(tChild);
}
or something of the sort. It would really depend on how things are set up already, but that's the general idea.