I'm using Codeigniter to flesh out a pretty large project (especially for a n00b). One issue I'm having is how to organise my files and methods. I've broken my project down into features - the app is a task management software so already we have basic features such as "Task", "Project", "User" etc.
The way I intend to do this is by creating controllers for each and then following CRUD methodology in each. So for example in Task we would have the following methods:
create()
read()
update()
delete()
This makes sense in my head. Now in terms of Views, should I have multiple views, or should I combine create and update into the same form? Also, where does non-View functionality go, such as setting cookies etc?
This is quite a specific question but if anybody has any more holistic guides on general structure convention for CodeIgniter projects I'd be very grateful.
I'd say you got it right. This is what I do.
I tend to use the same view for create and update, keep it DRY (don't repeat yourself) if you can.
Non-view related stuff that does not handle anything business-related goes in what I call helper-classes. If it's business related, I put all the logic into services, so I can unit-test them without being dependant of any framework (not sure how new you are at this, but oh well :) ).
You can also use Grocery Crud, a library that provides out of the box CRUD functionality for codeigniter.
It handles pretty good 1->n and n->n relationships so its convenient for small projects.
I don't know if you are familiar with it. If not give it a try. It will save you tons of time and effort.
My controller consists of these methods, which follows REST API guidelines:
read -> get all records.
find -> find record by primary key/id.
create -> show the form view.
store -> insert data from the form into the database.
edit -> show the form view, populated with current records' data.
update -> update data from the form into the database.
delete -> delete data from the database.
This is called Resourceful Controllers.
Yes, you can combine create and edit in same form. However, there are cases those require you to use different create and edit form. In that case, just make 2 separate forms.
And... like #Theodore suggested, GroceryCRUD is worth a try if you don't need too many customizations.
Related
I'm learning Laravel and I'm watching many tutorials, but I dont really get it, what's the difference between the controller and model, because you can put in both a function.
Controllers in Laravel are used to determine how to handle http requests.
When you have anything to do with the DB, its better to place those function in the model, and call them from the controller.
In clear terms:
Model performs all operations on data from DB.
Controller call necessary model methods and ready the data.
View take care of displaying the data.
I hope this is clear enough.
You will be familiar with all of this soon.
model methods is for relationships mainly , or to make some thing for every object of this model (database table) every column in db is an object and every table is a model.
but in controller you set your app functionality that you want , and its an intermediator between model and view .
i hop this makes you good in this point.
good luck
You can write functions anywhere, you are perfectly right.
But is not an efficient way to do things.
The answers for those questions can be easily find out. Search about MVC pattern. In few words, remember brief:
MODEL => working with relational databases / storing the data
CONTROLLER => working with the logic(taking inputs, calculus etc) / general functionalities
Combining them is more efficient than working with those together, that is the reason why using a pattern is more great than writing code in a old style mode reinventing the wheel again.
Is there a reason why Create and Update are distinct when making MVC application in PHP?
I see why they are distinct in theoretical explanations, but is it worth keeping separate actions and views for create and update in CRUD controller? If I only need to change the title of save button it seems logical to have one action for both create and update operations. which will save object as new DB row or update existing depending on the id it has (or hasn't).
PS. I've always merged them into one action and recently when started searching for information about Zend Framework I've found that every tutorial with some CRUD functionality has distinct create and update actions and views that have almost the same code. It seems strange why authors copy-paste 90% of the code from one method to another.
I think you're asking more of a style question than a purely functional one. For me it's separation of concerns - there is no guarantee that create and update will truly overlap, and there may well be functional differences, so it's a potential landmine in the future to lump them together.
I am building a CRM using a framework (codeigniter) for the first time and I am having trouble determining where a certain module should go while maintaining the MVC methodology. The module automatically generates a new user (when a new company is created) and emails the log in details out to the supplied email address.
I am familiar with the idea of skinny controllers and fat models but to compile all the information needed the module must request data from several different tables as well as inserting data into several tables.
The scenarios I have considered so far:
The logic is in the model where most of the information comes from.
Create a totally new model that deals with just this module and the multiple tables required.
Place the logic in the controller that deals with creating a company.
Create a new library or helper and call the module when it is needed.
Skinny controllers and fat models seem to suggest that one or two are the right options but I was lead to believe that a model should only deal with one table in the database.
What is the right approach to ensure adherence with MVC?
Codeigniter allows you to be flexible with your MVC approach. So the answer is which option is:
Easiest for you (or your team) to understand
Easiest to code maintain
Easiest for someone else to understand
There's no point putting your code into a library, if you dont have any other libraries and dont understand libraries. Same as if all your models are "fat", but only point to one table, do you want this model to be the only one that also points to 4 other tables?
Personally, if this "logic" only ever happens in one place, then I would place it into the controller, and call the 4x models you need to do each bit of the code.
If this "logic" occurs in multiple places, I would place it into a library and call it when needed.
What I have is the following db structure(tables):
lists[name,id]
list_items[title,list_id,content]
I've created the needed files and code(the MVC) needed to manage the first table(lists).
I also added the hasMany to the model class. At that point I am stuck.
What I need is a solution for managing each item (basic CRUD, I assume that complex management is just an advanced CRUD that I will find out how to do by myself).
I will be specific: since it's a content that have no place (but the admin) that it will be used by itself, should I -
create a full mvc structure for it? (can or should I implement it somehow[how?] in the lists package?
if not, how can I attach the tables? (since the use is about to be dropped in version 2)
would an element(cake concept/context) will be the appropriate way to create a view for such situation?
ANY insight will be appreciated.
If I undertant correctly, you want to create a CRUD part of this tables by yourself, without bake.
You need to write all the MVC estrucure and be carefull with the naming combention of cakephp http://cakebaker.42dh.com/2006/02/18/cakephp-conventions/
You need the model into app/models and also a a controller into app/controllers (remember naming combentions) and for each model you need a folder into /app/views.
Alfo, every, every function in your controller needs a view, even if this action doesn´t write anything to screen
I hope this was usefull.
Have you tried using Cake's bake feature? Your CRUD will be automatically created in about 2 seconds. I would also recommend you do the Blog tutorial to get a feel for scaffolding.
CakePHP is all about convention over configuration. Eg naming conventions for tables, controllers, models etc.. So much can be done automagically.
My problem is in somewhere between model and controller.Everything works perfect for me when I use MVC just for crud (create, read, update, delete).I have separate models for each database table .I access these models from controller , to crud them . For example , in contacts application,I have actions (create, read, update, delete) in controller(contact) to use model's (contact) methods (create, read, update, delete).
The problem starts when I try to do something more complicated. There are some complex processes which I do not know where should I put them.
For example , in registering user process. I can not just finish this process in user model because , I have to use other models too (sending mails , creating other records for user via other models) and do lots of complex validations via other models.
For example , in some complex searching processes , I have to access lots of models (articles, videos, images etc.)
Or, sometimes , I have to use apis to decide what I will do next or which database model I will use to record data
So where is the place to do this complicated processes. I do not want to do them in controllers , Because sometimes I should use these processes in other controllers too. And I do not want to put these process in models because , I use models as database access layers .May be I am wrong,I want to know . Thank you for your answer .
Just a short comment (no solution) AFAIK that is an eternal question - MVC is just a pattern, and as such, is in theory implementable cleanly. In practise, due to limitations set by available tools (such as programming language library contents and UI component interface design..) you have to make local decisions. The important thing is that you aim to separate these...and not have everything in one mess. I take my comment off the air and am left to see if someone has a "final solution".
For simple tasks I would write action helpers (e.g. sendNewsletter).
For sophistocated tasks I woud create services (eg. email, auth etc.).
In MVC, you should place those things in the model (for reuse reasons for one).
However, in HVMC, you could place them wherever (such as in a controller) and call the controllers from within your application.
I would make your controllers simple.
In many ways the model allows you to offload a lot of the complexity that would otherwise occlude your controller code. Its this division of complexity which will make your code more easily understood, and easier to maintain.
personally I try to keep my models resembling real world objects, not databases tables or rows. It makes it much easier if you have made things speak in more readable terms. A single real world object might involve 5 or 6 database tables... And it would be a rather large hassle to speak with 5 or 6 models, when all you want to do is turn on a switch, or pick a flower, or paint an icon, or send a message.
What's wrong with a controller using multiple models? Isn't the point of MVC to make the model reusable? In your first scenario, it's perfectly fine to send emails and manipulate other model objects from wherever the "register user" controller code is.
In regard to your second scenario, why can't SearchController use ArticleModel, ImageModel and VideoModel? It's fine to have a controller without a model. SearchController doesn't need a SearchModel class, it just uses the other model classes.
I'm trying not to get into a rant about MVC in web apps, but basically, IMHO the controller is just a high-level list of steps to complete an operation. As a rough example, the "register user" controller code should do each of the following steps in roughly one or two lines of code:
Validate the input
If not valid, redisplay the form with an error
Create the new UserModel object from the form input
Insert the new UserModel object into the database
Create/edit whatever other model objects are necessary
Send off an email to the new user
Display a "registration successful" page
How those steps are coded largely depends on whatever framework/architecture you're using.
Keep your controllers clean. For backend processing use Manager classes like MailManager etc..