When I use a map constructor like:
Person p = new Person(name: "Bob")
through something that is called via a grails.gsp.PageRenderer, the field values are not populated. When I use an empty constructor and then set the fields individually like:
Person p = new Person()
p.name = "Bob"
it succeeds. When I use the map constructor via a render call, it also succeeds.
Any ideas as to why this is the case?
Sample project is here in case anyone wants to dig deeper: https://github.com/danduke/constructor-test/
Actual use case, as requested by Jeff below:
I have a computationally expensive view to render. Essentially it's a multi-thousand page (when PDF'd) view of some data.
This view can be broken into smaller pieces, and I can reliably determine when each has changed.
I render one piece at a time, submitting each piece to a fixed size thread pool to avoid overloading the system. I left this out of the example project, as it has no bearing on the results.
I cache the rendered results and evict them by key when data in that portion of the view has changed. This is why I am using a page renderer.
Each template used may make use of various tag libraries.
Some tag libraries need to load data from other applications in order to display things properly (actual use case: loading preferences from a shared repository for whether particular items are enabled in the view)
When loaded, these items need to be turned into an object. In my case, it's a GORM object. This is why I am creating a new object at all.
There are quite a few opportunities for improvement in my actual use case, and I'm open to suggestions on that. However, the simplest possible (for me) demonstration of the problem still does suggest that there's a problem. I'm curious whether it should be possible to use map constructors in something called from a PageRenderer at all. I'm surprised that it doesn't work, and it feels like a bug, but obviously a very precise and edge case one.
"Technically it is a bug" (which is the best kind of bug!), and has been reported here: https://github.com/grails/grails-core/issues/11870
I'll update this if/when additional information is available.
I have a question that I have been unable to find a clear and concise answer to without extra unnecessary calls through Dart and Polymer.
I want to create a parent custom-element that is able to allow it's child objects to access the parents information.
Example:
If I create a container called Student-View that sets up some tabs and pulls the basic information. Then have a child element that is able to access much of the same information through {{firstname}} {{lastname}} etc...
I am not sure the best way to accomplish this, and would prefer if it were all self contained. Or, should I go the angular dart route. Thanks!
Your description is pretty vague. Do you mean something like this?
http://jsbin.com/kelub/5/edit
In this case, the parent binds the student record to the child element's student property, like so:
<student-worksheet student="{{student}}"></student-worksheet>
Want to improve this post? Provide detailed answers to this question, including citations and an explanation of why your answer is correct. Answers without enough detail may be edited or deleted.
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 9 years ago.
Improve this question
I have a drop down list that displays values from a table to the end user. I would like to have these values be sorted alphabetically.
According to proper MVC design, at what layer should I place my sorting logic: the model, the view, or the controller?
EDIT: In response to LarsH's question, "Do you mean code that determines what sort order is desired? or code that performs the sort?", I was originally referring to the code that determines what sort order is desired.
Who controls the sort order?
(From Wikipedia)
1) Natural order within the data itself:
The order is part of the Model, so it should go there. A raw pull of "all data" would return the data in the sorted order, and there is no interface to choose the sort order.
2) The user should control how they see the data:
The View would provide an interface (such as ascending/descending arrows) that interact with the Controller, and the Model understands the data well enough to do the requested sort on the data. However, a raw pull of the data doesn't necessarily have to be sorted, unlike in (1).
In either case,
The View doesn't understand that there's a sort going on, other that the ability to show which sort direction has been chosen. Don't put the logic there.
Small caveat
The sorting functionality could go purely in the View, under one circumstance (that I can think of offhand; there may be more):
A "dumb" sort where all the data is already in the view and it doesn't have to use any domain knowledge to do the sort. Very simple string or number comparison, for example. This is not possible in, for example, search results on a webpage when results are likely to be split across multiple pages.
(Note: this quote and citation is taken from #dasblinkenlight's answer, but we disagree on our interpretation of it. read his post and make up your own mind).
According to MVC description,
A controller can send commands to its associated view to change the view's presentation of the model (for example, by scrolling through a document). It can send commands to the model to update the model's state (e.g. editing a document).
Sorting logic (e.g., the sorting comparator/sorting algorithm) belongs in the model since it contains business rules and state data. Since altering the way the model data is sorted falls squarely into the "change the view's presentation of the model" category, the controller is responsible for "doing the sorting" by calling the model.changeSortedState() method.
According to MVC description,
A controller can send commands to its associated view to change the view's presentation of the model (for example, by scrolling through a document). It can send commands to the model to update the model's state (e.g. editing a document).
According to this, sorting logic belongs in the controller, because altering the way the model data is sorted falls squarely into the "change the view's presentation of the model" category.
EDIT: To clarify multiple misunderstandings voiced in the comments, the "sorting logic" is not the code that performs the sort; it is the code that defines the sort. The sorting logic compares individual items to each other to establish an order (e.g through an instance of IComparator<T>) or contains logic that constructs an object to be used for ordering by an external system (e.g. through an instance of IOrderedQueryable<T>). This logic belongs in your controller, because it needs knowledge related to the "business" side of your application. It is entirely sufficient to perform the sort, but it is separate from the code that actually performs it. The code that sorts may be in your view, in your model, or even in the persistence layer that backs your model (e.g. your SQL database).
None of the above. Sorting is business logic, and business logic doesn't belong in any of the three. Not every piece of code in your application will be a model, view, or controller.
What I generally do in my MVC apps is I have a service layer that performs all the business logic. The methods in the service layer should have a clean, simple API with well named parameters. You can then invoke those methods from your controller to manipulate the data in the models.
In that sense, the sorting is "in the controller", but the code itself that does the sorting should not be implemented in the controller, only invoked from there.
Definetly not the controller: It sends messages to view and model but should do as little work as possible. If the user can change the sorting that request gets handled by the controller by informing the model or the view about it.
Maybe the View if it is a pure View thing. If the Application works just as well without sorting then the sorting is just part of the representation and should go in the view.
If the ordering is inherent part of the domain it should go in the model.
Views are the part of MVC which is supposed to contain presentation logic.
Model layer is where business logic is contained.
Controllers only change the state of both, based on user input.
So the choice is - do you think that this is part of the domain business logic or presentation logic.
If you were implementing a proper MVC Model2 or classical MVC pattern, then I would say that the ordering of data provided by the model layer should be triggered by the view's request to the model layer. View asks for ordered data, model layer provides it.
But, since you are using ASP.NET MVC's interpretation of MVC pattern, which is a bit different then your standard MVC - the ViewModel instance should request ordered information from the model layer (for some reason ASP.NET framework thinks that templates should be called "views" and views should be called "viewmodels" .. it's strange).
I would usually do it in the controller to remain in line with the pattern as per the other answers. See below for reasoning.
I've been mulling this over and reading the answers and related material and pragmatically speaking I would say it would depend on your application for instance:
Is it a medium/large application and/or has multiple UI's associated with it (i.e. a Windows App, Web interface and Phone interface).
In this case I would probably construct a service layer and put it in
the business object and then call the appropriate method from the
controller.
If its a well defined single UI website and you're using something like EF Code First and you do not have or have no intention of creating a service layer and plan on using a simple out of the box Extension method to acheive it:
In this case I'd probably put it in the controller as pragmatically
its the best fit with regard to time/budget.
If its the same as the above BUT cannot be implemented with an out of the box extension method.
I may well choose to pop it in the Model class (if its truely bespoke
to that single type) as it would be more appropriate here than in a
controller. If the sort could be applied to more than one class then
I'd implement it in an extension method and then call it in the
controller.
To sum up:
Dogmatic answer: Service Layer
Pragmatic answer: Usually the controller
I would suggest sorting data from a table-data that is small enough to be useful in a dropdown list-should come from the DB already sorted via the query. To me, that makes the model the place the sort is applied.
If you are determined to do the sort by hand, I think there are good arguments for using either the model or controller as your preferred spot for logic. The limitation would be your particular framework. I prefer to manage data solely in the model. I use the controller to marry data(model) and presentation(view) as I've been (self)taught.
Whilst I agree in principle with the idea that sorting is Business Logic because by breaking it down to it's origin you would end up with something like "The client would like the Product page to display with the images sorted by date" then it becomes clear that the sort order for data is typically not arbitrary - even if there is no sorting as that's still a business decision by omission (an empty list is still a list).
BUT... These answer don't seem to take into account the advances in ORM technology, I can only talk in relation to the Entity Framework (let's avoid an argument about whether this is true ORM, that's not the point) from Microsoft as that's what I use, but I'm sure other ORMs offer similar functionality.
If I create a Strongly Typed view for a Product class using MS MVC and the Entity Framework and there is a foreign key relationship between the Product and Image table (e.g. FK_Product_Image_ProductId) then I would out-of-the-box be able to quickly sort the images during their display using something like this in the view:
#foreach(Image i in Model.Image.OrderBy(e => e.DisplayOrder)){ //etc etc... }
There was mention of a specific Business Logic layer, which I also use to perform 80% of my business logic, but I'm not going to write sort functionality into my Business Logic layer that mimics something that comes out-of-the-box from the Entity Framework.
I don't think there's a correct answer to this question, other than to say that; you should abstract complex business logic where possible but not at the cost of reinventing the wheel.
Assume that you have MVC website, WebForms website and a mobile application.
If you want sorting to be consistent between these presentation layers, then I'd say sort outside of the presentation layer. Service would be a good candidate.
Otherwise, I would store that logic in a view model. Why? Because it'll be reusable and easily testable.
Out of the three you have listed, I would say that it belongs in the controller. I don't really like placing this sort of logic in the controller, though. I usually create a service layer that the controller communicates with that will be responsible for communicating with the data store and handling sorting logic. For small applications it is fine sitting in the controller, though.
This is a question asked with the asp.net in mind, but since somebody did mention Rails, I thought it would be interesting to consider the problem in that context. In Rails, it is natural and pretty common to perform the sorting along with the retrieval as a controller action, since the framework and ActiveRecord/ActiveQuery api provisions for it. On the other hand, it is possible to define some sort of custom sort order for static items and put that in the model to be used by the controller, so the model can play a part in the sorting logic even though it does not carry out the operation directly. Whatever it is, it can be safe to say that putting the sort logic in the view is generally frown upon.
I'm slightly amused that some answers are absolutely against putting the sort in either the controller or the model, and I find them too pedantic for my taste, but I suppose it depends on the nature of the framework used and the usual conventions associated with it. I also agree with Bill K's comment that having the separation in the first place is more important.
Is there any tutorial or sample on how to create a local multiplayer in an XNA game(Windows)?
I often see tutorials for networking game but never on how to enter a second player. How to ask the second player to sign in, to use the same object but with different controller...
Thanks.
I've not come across any tutorials, but I can outline some basic ideas for you.
If all of your players will be identical:
Modify your 'player' objects constructor to have a parameter for some playerIndex. When checking for input inside the player class, use this index. That way, you can create a bunch of 'players' without needing to write individual classes for each. You can then write general-purpose code like:
if (inputManager.IsMoveRight(playerIndex))
{
// do some stuff etc.
}
This will require some modifications to your input management structure. You should be aiming to generalise the code you already have.
If each player will have completely different implementations:
You'll need to take advantage of polymorphism in this case. If each player should select their character in a menu screen, you'll need to have some attribute in the player class that holds their chosen character (Note: If each player should be a preset default, i.e player 1 is always mario, player 2 is always sonic, it would probably be best to subclass your player class for each player). This attribute could be moved up a layer and stored in a 'controller' class if you wanted.
Menu logic:
Handling player sign-ins is really best done before any levels are loaded. I'm going to assume that you don't need players to drop in/out during the game. Basic outline:
When the game is in a character selection screen (or just the main menus) check for input from all controllers. If a controller presses 'start', sign them in. This could involve simply adding a playerIndex to an array for example. Then, when the game loads, check the array for active players and spawn any that are found.
Character selection can be implemented in very much the same way, although you'd probably want a specific menu sign-in screen. Check for input from active players during the sign in screen and allow them to scroll through and select a character. Store the result somewhere (player or controller class for example).
Other things to consider:
Are getting input from the keyboard as well as gamepads? If this is the case, it might be easier to default the keyboard to player one, and only allow sign in/out from gamepads.
I mentioned this before, but you will need to generalise your input management to prevent a major case of spaghetti code. In order for any of this to work, you should not be checking previous/current controller states from directly within your player class. The MSDN Game State Management sample is worth examining as it uses a similar system.
This isn't a very comprehensive guide, but hopefully I've raised some points for you to consider.
This is probably a very "dumb" question for whoever knows VirtualShellTools but I only started using it and couldn't find my answer in the demos' code. Please note that I'm also unfamiliar with virtualtreeview.
I use a VirtualExplorerTreeview to display a directory structure, linked with a VirtualExplorerListview to display a certain type of files in the selected directory as well as specific informations about them
I've been able to point them at the right place, link them as I wanted, filter everything in the listview, and looking at the demos I have a pretty good idea about how to add my own columns and draw it to display my custom data.
My issue lies with the Treeview: I would like to sort the directories displayed in the order I want; specifically, I want "My Docs" and other folder to appears first, then drives, then removable media. Looking in the TNamespace property I found how to distinguish them (Directory and Removable properties), but I don't know how to implement my own sort/what event I need. I tried CompareNode but that doesn't even seem to be called.
If you want to do everything yourself, then set toUserSort in the TVirtualExplorerTree.TreeOptions.VETMiscOptions property. That causes the control to just use the DoCompare method inherited from the virtual tree view, and that should call the OnCompareNodes event handler.
A better way is to provide a custom TShellSortHelper. Make a descendant of that class and override whichever methods you need. Create an instance of that class and assign it to the tree's SortHelper property. (The tree takes ownership of the helper; free the old one, but not the new one.) If the items are being sorted on a column that that class doesn't know how to compare, then handle the tree's OnCustomColumnCompare event.
To help you figure out exactly which methods you need to override or events you need to handle, set a breakpoint in TCustomVirtualExplorerTree.DoCompare and step through to see what gets called in various situations.