What is the model using for when constructing grid? I have created two grids with different model but same code excepted model. It works same.
#Html.Infragistics().Grid<Model1>
#Html.Infragistics().Grid<Model2>
Thanks
Wilson
Related
I am using spacy to train my own NER model. In addition to entities trained by spacy basic 'en_core_web_sm' model (ORG, PERSON, DATE, etc), I want to add my own entities. I trained my model with 'en_core_web_sm' as my base model, but then the model can only detect my own custom entities only, not the basic entities. Is there any way to do this? Thanks.
You can definitely do this with spaCy, cf the docs and also check Matt's blogpost around the problem of "catastrophic forgetting" (when your model "forgets" about the old types it knew before, which you obviously want to avoid).
A design question on multiple DropDownLists on a View.
What is the best approach to displaying multiple DropDownLists on a View? Is it possible to pass multiple DropDownLists to a View model?
For example:
If I had the following View models: Student, Course, and Enrollment. And on the Index View page, I'm returning and displaying all students. But I'd like to filter the number of Students being returned based on values selected from multiple DropDownLists, such as Suburb, LanguageSpoken...
Each DropDownList will be populated from the database.
Two approaches that I can think:
In the Student View model, have a (fully populated) collection of Suburb, LanguageSpoken... .
Have multiple Models passed to the View model. In this case one Model will be a Student, and the other Models will be each DropDownLists. I haven't looked into the details of this yet.
I don't like the first approach, as it sounds very inefficient, i.e. each Student hold collections of list of all Suburbs, Languages... Also, not sure if the second approach is possible or even a good idea.
I'm using ASP.NET MVC 5 and Entity Framework 6.
Ok, after alot of reading up and trying a number of things, I've finally have a (simple) solution: Drop Down Lists using ViewBag.
E.g. the Student controller returns a Student viewmodel to the View, and any further models such as postcodes, languages... are returned via ViewBag to the View.
I figure ViewBag is appropriately used for such data, i.e. lookup (static) type data.
My question has to do with data modeling.
We have a Score-model which links to both a Division model and a Element model. Between the Division and the Element model a habtm-relation exists. The score has to be evaluated against an attribute of the Element model (criterium attribute).
Now we want to introduce the concept of "Problems". A problem is each score which does not pass the criterium. (additional info: Multiple scores will be recorded over time, different types of scores exist. Filters on score_types and date ranges are desired)
What is the best way to model the Problem concept?
Just calculate the problems in the controller each time the view of the problems is requested
Introduce a Problems-model (which does not really contain any new information from the Score and Element info
Create a tableless Model like ActiveModel.
None of the above, as it is a newbie question and you should do it like so and so ... (fill in the blanks)
Any help would be much appreciated.
Without knowing what your codebase looks like and assuming the Problem model would only be storing the id of an associated Score, I'm going to suggest using a scope on your Score model. You can create the ARel query (or queries) to get the desired Scores without adding too much more code. Check the Rails Guide on Active Record Querying - Scopes section for more info.
If you need the Problem model to do anything that the Score can't do, I'd consider creating an actual model (persisted or not is another decision).
I'm developing a rails project where I have one data model with multiple fields that are collection selects. I'd like to create another model to represent all of these collection select fields. So, for instance, my main data model has three collection select fields -- one for county, one for category, and one for classification. I could separate these into three separate data models, but that seems redundant since they all share the same characteristics. They have a type and a value, like a county is a county and it has a value of let's say Sonoma, just as category has a type of category and a value of let's say Winery. If you've ever used Drupal, I'm basically looking for the behavior of the taxonomy functionality.
So you see my dilemma: I need to separate these fields into three separate fields but they have very similar data structures. Any suggestions would be greatly appreciated.
This is a perfect case for single-table inheritance. Your problem is screaming for it.
I'm not sure if this question is non-sense or not, please tell me if so. I am wondering do I create my models like one per each table in my database, or do you do one per controller? Is there something I am missing here?
From what I read the Model is suppose to be a representation of the real business objects, so would I just want to make it one big model or divide them out based on things in the app? based on real user/client perception of the data?
Thanks for your advice.
There's nothing wrong with controllers sharing models. But trying to serve every controller with the same model doesn't make sense.
Models and controllers really are't related, nor should they be. Models also aren't directly related to how data is stored in your application.
Models encapsulate data. Their design should be dictated by the data they are encapsulating. The demands of the system dictate what models you'll need and what data they must hold.
Don't try to overthink it. For a given request, determine what you need to show in your view and how it will be displayed. Determine what an appropriate model would look like for this scenario. If one already exists, use it. If not, create a new model. Save the overengineering later when you know what your needs are and can find commonalities between models.
Models can also contain other models, that's fine. Think of a model for a sales report. You would have a model for the report which would contain not only a report name, a total, but also a collection of other models which make up the report's line items.
It depends on what you mean by "Model". If by model you mean the business rule layer of your application, then there is no relationship in terms of numbers. One model of that type is used for any amount of views you need to build.
Personally, however, I would not bind any view to any model, but create an intermediary layer called a ViewModel that essentially taylors the data from your model to fit a particular view. In that case, the relationship is one-to-one. This is essentially how Presenter patterns work. Every view is strongly typed to it's own ViewModel that is populated from the Model layer.
Models do not necessarily have a literal coorespondence with the database either. How you store data your model is different from how your "Model" uses that data.