I'm talking about HUGE forms - like medical forms with 1000+ fields.
How do you logically create models for them? Do you include every single little field as seperate model? Do you have the whole form as a HUGE model with every single field? Do you have formsections as models and each formsection has few fields?
I know this might be subjective, but I really want some advice on someone who has dealt with this before and save others a lot of time down the road by avoiding mistakes at the onset.
Your data model should follow an EAV method. Medical systems are well suited to this approach as not all patients are going to have all this information filled in. This method allows you to fill in what is appropriate and populate your model. Makes organizing the data easier as well.
As for organizing it in the view, I suggest you break it up into sections where sections are logically related to each other (past history, family history or by type of information), making the information easier to digest.
Related
I'm creating a web app for my client as a part of my schools final project.
It's a web app where users fill forms (surveys) and after forms are submitted,
values are saved in the database.
There are three types of users: admins, moderators and viewers. Admin's can see the
overview of filled forms, moderators will fill these forms and they also can make edits
to them and get the overview of the forms they've filled. We haven't discussed about the rights of viewers
at this point.
I'm using CodeIgniter as a framework of my project since it comes pretty handy when it comes to database
manipulation and forms. What would be the best way to implement this kind of situation? There are apprx.
4-5 forms (surveys) each moderator will fill. After they've filled them, they only can make edits to that particular form.
So one user can fill each form only once.
I've designed that each of the forms needs one table. So if there is a form (survey) about IT equipment, I will create
a table for IT equipment. User's id number will be saved in to the last column in the table, usually called "user_ID" where I can
make queries based on users and check if user is already filled the particular form.
What about controllers and models? I've thought I could only make one model for inserting and editing the form.
However, is it pretty much the only way to create a controller or method foreach form since there are different types
of form fields to validate based on the form user is actually filling. I've already created a controller for inserting and updating
the IT equipment form and both of these methods are pretty big when it comes to the amount of code, over 200 lines per method.
So that would be a total amount of 2000 lines of code just for inserting and editing all the forms.
What'd you do and how you'd implement this if dealing with similiar kind of project?
Thanks in advance for all the ideas and point of views!
You should take a look into this:
http://cibonfire.com/
It's a really good addon for codeigniter, that allows you to data oriented development.
Let's say we are structuring an application with MVC (also, Stores/Services). SQL is used as the persistence mechanism. And memory efficiency is a major concern.
Obviously, we should take advantage of SQL queries and only ask for fields of our Model in theory object when they are needed.
For example, an mobile app may need to display a list of title for articles, while the body of the article doesn't get displayed until user taps on a specific title. In this case, we ask SQL for just the titles first.
The question is, what should the model object look like?
The solutions I can think of are:
Enhance the model with some states that indicate which fields are populated. This could also be archived by using nil/NULL/None values on unpopulated fields of the model object.
Split the theoretical model to multiple classes. Following the previous example, we could have an Article class and an ArticleDetail class, with a one-to-one relation.
Forget the Store object, let each model object lazy evaluate it's costly fields. The model would have to know about its persistence mechanism.
This should be a common problem. How do the ORM in your favorite frameworks/libraries resolve it? Any best practices?
I'm an old CFML developer, new to CF on Wheels and MVC programming in general. I'm picking it up pretty quickly, but one thing that isn't evident to me is how one can offer a form to optionally update multiple db table records (models). I'd specifically like to set up a tabbed form for User info and User Profile info, where the former is required and the latter is not. This data is stored in two different one-to-one tables. What's the setup I need in order to call two "new" or "edit" views, run 2 "create" or "update" procedures, affecting two different tables. Or am I thinking about this all wrong.
Update: Adding some more info on what I'm trying to do. To keep it simple, I'll stick to 2 tabs and 2 tables, though I'm really looking at at least 3 in this instance.
So I've got a Users table and a UserProfiles table, and I've got models named User.cfc and UserProfile.cfc that are related 1-to-1, with UserProfile dependent on User. Pretty standard stuff. For each I've got controllers: Users.cfc and UserProfiles.cfc, each of those containing actions. add, edit, create, update, doing the obvious stuff (add and edit display forms). I have partials that display the add/edit form fields for each, so that's already prepared. Now, I want to create what is effectively a single add/edit form that can update both tables at the same time. The tabs don't really matter; effectively it could all be on one page.
So conceptually I'm doing something like:
#startFormTag(action=???)#
#includePartial("form_user_add-edit")#
#includePartial("form_userprofile_add-edit")#
<button type="submit" class="btn">#operation#</button>
#endFormTag()#
Do I need to create a separate controller action that basically combines the create and update actions for two different controllers?
Thanks in advance from a pleased and eager CFWheels newbie...
Brian
If all of the data is related through hasMany or hasOne associations, I'd recommend looking at nested properties.
http://cfwheels.org/docs/1-1/chapter/nested-properties
If you're a newbie though, you may want to refrain from this until you've got something simpler worked out.
I guess you are talking about two models representing these two tables, possibly associated using hasOne. Models allow you to validate data, this makes controller much simpler. This way you could create two forms under two tabs, and keep record's primary key as hidden field. Controller could run the validation and re-display the forms (partials may help)... Hold on, I am just going through the reference.
I realize this answer is pretty generic, as well as your question. I suggest you to go ahead and try something, see how it works.
After that update your question with code samples and ask if you have some specific problems. For example, validation and displaying errors in CFWheels may be a bit tricky.
I am wondering how the models in code ignitor are suposed to be used.
Lets say I have a couple of tables in menu items database, and I want to query information for each table in different controllers. Do I make different model classes for each of the tables and layout the functions within them?
Thanks!
Models should contain all the functionality for retrieving and inserting data into your database. A controller will load a model:
$this->load->model('model_name');
The controller then fetches any data needed by the view through the abstract functions defined in your model.
It would be best to create a different model for each table although its is not essential.
You should read up about the MVC design pattern, it is used by codeigniter and many other frameworks because it is efficient and allows code reuse. More info about models can be found in the Codeigniter docs:
http://codeigniter.com/user_guide/general/models.html
CodeIgniter is flexible, and leaves this decision up to you. The user's guide does not say one way or the other how you should organize your code.
That said, to keep your code clean and easy to maintain I would recommend an approach where you try to limit each model to dealing with an individual table, or at least a single database entity. You certainly want to avoid having a single model to handle all of your database tables.
For my taste, CodeIgniter is too flexible here - I'd rather call it vague. A CI "model" has no spec, no interface, it can be things as different as:
An entity domain object, where each instance represents basically a record of a table. Sometimes it's an "anemic" domain object, each property maps directly to a DB column, little behaviour and little or no understanding of objects relationships and "graphs" (say, foreign keys in the DB are just integer ids in PHP). Or it can also be a "rich (or true) domain object", with all the business intelligence, and also knows about relations: say instead of $person->getAccountId() (returns int) we have $person->getAccount(); perhaps also knows how to persist itself (and perhaps also the full graph or related object - perhaps some notion of "dirtiness").
A service object, related to objects persistence and/or general DB querying: be a DataMapper, a DAO, etc. In this case we have typically one single instance (singleton) of the object (little or no state), typically one per DB table or per domain class.
When you read, in CI docs or forums, about , say, the Person model you can never know what kind of patter we are dealing with. Worse: frequently it's a ungly mix of those fundamentally different patterns.
This informality/vagueness is not specific to CI, rather to PHP frameworks, in my experience.
I have a web application built on an MVC design.
I have a database which contains a large number of objects (forum threads) which I can't load into memory at once. I now want to display (part of) this collection with different filters in effect (kinda like what stackoverflow does with questions sorted by date, votes, tags etc).
Where do I implement the filtering logic? It seems to me that this must go into the model part of the application, as only models interact with the database (in my implementation). If I make the filtering a part of the view, then the view must access the database directly to get the list of filtered objects, right? I'd like to avoid this, because it exposes the database layout to the view. But at the same time, displaying different views of the same data should be implemented in the view part of the application, as they are just that -- different views of the same data.
So how do I resolve this? Do I create an additional model, say, FilteredThreadsList, and have it remember the filter to use, and then use a FilteredView to display the list of threads that FilteredThreadsList spits out?
Or do I have to build a ThreadQueryier that allows views to query the database for certain thread objects, so I can have the filtering logic in a view without exposing the database backend?
You should never query data from the view. I don't know what framework you are using in particular but as for Ruby on Rails (should be the same for other frameworks) we always pull the necessary data from the controller and store all that information into a variable. The variable will be accessed by the view which can help you avoid querying your database directly from the view.If the code to query the database gets too lengthy in the controller, insert that code into the model instead so it's more maintainable for your project in the future. Additionally, you can call this model method from multiple places in your application if needed. Good luck!
From an architectural point of view, the model should be having the code for filtering. This is so, because in many applications the code for filtering is not trivial and has a good amount of domain logic in it. (Think of filtering top gainers from a list of stocks). From your example as well, it looks the same since you might want to filter by vote or by date or by tags and then by answered or unanswered etc.
In some very simple applications that deal with search/list of entities and allows Create/Read/Update/Delete of an entity, the pagination, sorting and filtering logic is usually very generic and can be implemented in a controller base class that is inherited by all entity-specific controller classes.
The bottom line is this: if your filtering logic is generic put it in the controller else put it in the model.
Model, that's only bunch of entities.
View provides a visual representation of the data from model - use as much of views as you want. If your application is web based, you can fetch data into browser just once (AJAX) using and re-use them for different UI components rendered in the browser.
As for what entities and what view to use for their representation, I think it's work of Controller. If you need some support for it on "model layer", add it but avoid tight coupling.