I've been learning CodeIngiter and up till now but can't seem to get a grasp on how CodeIgniter can be used to work as a team. Can someone explain the basic of team work using CodeIgniter?
From what I understand, it's like this so correct me if I'm wrong :
Let's say there is a project with 5 pages, Home, About Us, News, Gallery and Contact Us. Where CodeIgniter can help is let's say I have 2 programmers in my team, so each one of us do a module (for each Controller-View-Model) (for example Programmer A does News module, Programmer B does Gallery module) in different folders (folder news and gallery), etc.
So the end product will be a group of modules in seperate folders. home/ , content/, news/, gallery/, contact/ , etc.
Is that the right flow of teamwork using CI? I read that CI can be used to collaborate between designers (front end CSS) and programmers (database and controller) but I think with this flow, designers will have to wait for programmers to get the variable names to be parsed into the view and that will somehow halt the progress of the work.
I currently work in a team environment with Codeigniter and I'll tell you generally it flows like this.
Designer produces Designs coded out (html/css) with static content. (no variables)
While he is doing that Myself and others are working on the data model we are going to use and writing Model Methods we can forsee needing to interact with the data in a way our application will utilize.
Then the Designer hands off the static layouts, I "cut them up" into header/footer/etc... and replace the static content with the variables by writing the controllers to accomodate.
As a bonus I would highly recommend using some sort of version control with your team, depending on your needs I usually stick with SVN or GIT, GIT is a little more accommodating to distributed teams that are not in a centralized location. This will greatly improve efficiency and prevent ( or mitigate ) situations in which two people end up working on the same file and someones work gets overwritten, and other situations that occur when multiple people are working on the same files.
CodeIgniter is just one way of doing of Model-View-Controller. You probably don't need to divide things up into separate modules or folders; instead, you'll probably want to create files like this:
controllers/gallery.php
controllers/home.php
controllers/news.php
views/gallery_view.php
views/home_view.php
views/news_view.php
models/page.php
models/picture.php
It's perfectly legal for each controller to make use of multiple models and views; in fact, that's the point. A blog controller might use models for user, post, and comments. You can also do sub-views which are used from inside your other views (such as views/header_view.php).
If your project has well-defined specs, you might consider making the team division between one person doing the model and controller logic, and another writing the view output. Or, you could divide the work between different pieces of the site; however, you'll still want to write some shared code that gets used project-wide. That's the biggest principle of MVC: Don't Repeat Yourself.
Related
I am currently trying to understand how the MVC framework does work in PHP. Therefore, I have created this basic sketch of how I think that MVC is implemented in PHP:
[I know that some steps are missing, e.g. how the Routerparses the route in order to know what View and Controller to load, but these steps are rather technical based and are not important in order to understand the general flow of MVC in PHP.]
I draw my understanding of MVC in PHP from this article series. However, I think that this structure will differ from most of the structures people think off, when they talk about MVC in PHP, because of this article (The article basically states that not only the Controller but also the View does communicate with the Model).
What I'd like to ask you now are several questions:
Is this generally a right way of implementing MVC in PHP?
How can I add a Login/Logout-System to this approach? So that user, who are not logged in, will always see the LoginView and users who are logged in can see different views? (I know how a login system does work, but I can't figure out where to place it in the MVC, so I don't have to insert the code multiple times, e.g. in each Controller.)
What if my application consist of multiple elements (say a user bar [with user name, link to settings, etc.], a navigation and a content container) that are always loaded? How can I assemble these elements to a final view? (The only idea that comes to my mind is to assemble the final view in each view separately, but that would mean that I have to insert the code for it multiple times in each view, which misses the point of MVC, doesn't it?)
What if I want to use AJAX in my application? My idea would be to send ajax requests through the framework as well, while only accessing controllers and views that are made for ajax? In other words the AjaxViews do only return e.g. json objects and the AjaxControllers do always expect authentication codes to prove that these ajax calls are legtitim?
I know that there have already been asked dozens of questions about MVC in PHP and I've been reading quiet a lot of articles until now, but I think that only reading does not enable me to understand MVC completely.
Furthermore, after reading the articles linked above, I'm not longer sure whether other articles about MVC, I find on the web, does explain MVC the same way as the articles above. Because if they don't, I'm trying to understand one framework while reading about two or multiple different approaches.
Thank you very much in advance for taking the time to answer my question!
-- --- --- Update --- --- --
According to the answer below I've changed my MVC sketch. Just in case someone finds this link and wants to know more.
Let me first answer your questions, then place my take on it.
There's no right way of writing MVC. There are so many flavors and variations, and that get even multiplied when talking about web MVC.
About Logging in and Logging out. I think the most robust system would be a Role Based Access Control combined with an Access Control List, see How can I implement an Access Control List in my Web MVC application?.
There are generally two approaches, either you have a 1:1 ratio between Controllers and Views, and then after the Controller is done, your bootstrap script calls the View with the same name (LoginController, LoginView), or your Controller returns the View name along with action and parameters, to be called by the bootstrapper. The view then picks a template, and that template can include other sub-templates (like the user bar, or the footer).
In that case, your view needs to have an ability to select a different template based on the Accept: HTTP header (and send something like Accept: application/json in your AJAX requests). Your view then returns a JSON template instead of an HTML template.
What is wrong with your sketch?
Your model isn't just the gateway to your database, it's where all the logic happens. All the computation. See this yet another excellent answer that explains How should a model be structured in MVC?.
The idea of MVC is to simply separate your application into three layers: Input (controller), Logic (model) and Output (view). This is to extend on the usual way PHP works (here's a request, give me a response, all in the same page).
For that reason, implementation details may vary, the concept is what matters. "Web MVC" is merely the result of good OOP practices and some naming convention someone made up a few decades ago.
It is for parallel development and code reuse ability. There is a separation of concern how your system works and how users work. This provides a solution of the problem. There is boundry now, MVC.
I'm starting to look at Object Oriented PHP. To date I've developed a large number of PHP systems with a procedural approach, but I think it's time to move forward.
One of the projects I'm working on at the moment is a Grade and Handicap Calculation plugin for WordPress. In short, the plugin takes table tennis players' results from uploaded CSV files and works out their grading for handicap tournaments.
I'm using WordPress because my table tennis club's website uses WP and if it works for them I can potentially give it to other clubs/leagues and they too will be able to install the plugin and have access to a fully-fledged grade and handicap system.
Outside of WordPress, I'm reasonably confident that I could develop such a system in OO-PHP using the MVC pattern. It would probably look something like this:
Controller
Create an instance of the Model
Deal with "navigation", i.e. GET/POST requests, and work out which page templates to display accordingly
Model
Deal with uploading and storage of files
Update and select information from database
Host mechanism for working out players' grades
View
Admin pages, i.e. settings and uploading files
Grades page, displaying players' grades and handicaps
Results page, where specific users can see individual players' results (mostly for debugging purposes)
Please correct me if I'm wrong, as I've only learnt this pattern in the past 30 minutes or so, but by my logic that is a true MVC approach to creating this system.
However, once I bring WordPress plugins into the equation, I'm starting to struggle with the following questions:
In the non-WP system, CSS styles would simply be included in the View's PHP pages which I'd then include in the Controller. However, in WordPress, it doesn't work like that - I can't use CSS styles in that way, they have to be enqueue'd. Where would I host the function for enqueueing my CSS files?
When someone first activates the plugin, it will need to create the appropriate database table using WordPress functions to do so. This would then have to be run off a hook, i.e. a register_activation_hook. Where would I host these functions? It would seem sensible to put them in the Controller but at the same time I'd imagine that maybe the Controller needs to be kept as clean and simple to read as possible.
Similar to the above question, I also need to create WordPress admin pages using add_menu_page and add_submenu_page commands. Where do I host these functions?
All of these questions probably have the same answer, and I know it's just semantics, but I'm keen to try and get this right early on so I can truly get my head round the MVC pattern of Object Oriented PHP.
Thanks in advance,
If you are looking for a better place for learning MVC, this would be it.
Hope I'm getting this right.
Can't tell you about CSS, as I just keep those defined in my layout files (view).
Heavy logic can be put into services (external Class), and then being ran in controller. You'll keep your controller 'thin'
Similar to previous one. You can have your menu stored as a model (which doesn't have to be strictly DB related, but also XML/JSON/array data), and then call your add/remove actions in controller.
I'm looking for advice, tutorials and links at how to set up a mid-sized web application with Kohana 3. I have implemented MVC patterns in the past but never worked against a "formalized" MVC framework so I'm still getting my head around the terminology - toying around with basic examples, building views and templates, and so on.
I'm progressing fairly well but I want to set up a real-world web project (one of my own that I've been planning for quite some time now) as a learning object.
I learn best by example, but example-based documentation is a bit sparse for Kohana 3 right now - they say so themselves on the site. While I'm not worried about learning the framework as I go along, I want to make sure the code base is healthily structured from the start - i.e. controllers are split nicely, named well and according to standards, and most importantly the business logic is separated into appropriately sized models.
My application could, in its core, be described as a business directory with a range of search and listing functions, and a login area for each entry owner. The actual administrative database backend is already taken care of.
Supposing I have all the API worked out and in place already - list all businesses, edit business, list businesses by street name, create offer logged in as business, and so on, and I'm just looking for how to fit the functionality into a MVC pattern and into a Kohana application structure that can be easily extended.
Do you know real-life examples of "database-heavy" applications like directories, online communities... with a log-in area built on Kohana 3, preferably Open Source so I could take a peek how they do it?
Are there conventions or best practices on how to structure an extendable login area for end users in a Kohana project that is not only able to handle a business directory page, but further products on separate pages as well?
Do you know any good resources on building complex applications with Kohana?
Have you built something similar and could give me recommendations on a project structure?
Bounty
I'm awarding the bounty to #antpaw because he provided me with a Kohana application with some business logic that is giving me a lot of examples. Cheers #Pixel Developer for your excellent input as well - as so often, I'd wish one could split a bounty!
Lots of questions to answer here, I'll try my best.
Do you know real-life examples of "database-heavy" applications like directories, online communities... with a log-in area built on Kohana 3 where I could take a peek how they do it?
There's a few example applications out there. Woody Gilk (Kohana founder) has published the code to his personal website on github. For the login area he assigns a cookie value. Kohana 3 / 2.4 sign the cookies which makes it safe and removes the requirement for sessions. This might not be up to everyone's tastes so you can always use built in authentication library that uses both sessions and cookies.
Here are some other projects you might be interested in:
Shindig - Light weight blog module for kohana 3
Kohanut - An extensible CMS written in Kohana 3
Are there conventions or best practices on how to structure an extendable login area for end users in a Kohana project that is not only able to handle a business directory page, but further products on separate pages as well?
If I understand you correctly you want to generate a login box for each of those pages? This is easy with Kohana 3 as we can take advantage of the H in HMVC. Sam de Fressyinet wrote an article detailing what this all about on the iBuilding Tech Blog. Scaling Web Applications with HMVC.
What you can then do is perform an internal request to the login controller or action and dump the response into your view page.
$login = Request::factory('login')->execute()->response;
$login now contains the login form, which you can put anywhere you like. You may want to return a different response if the request is internal which is why this piece of code can be useful:
if (Request::instance() !== $this->request)
{
print 'Internal called made with Request::factory';
}
Do you know any good resources on building complex applications with Kohana?
There's not going to be documentation showing you how to build complicated applications. The view of the Kohana community is that you're a PHP developer and should be able to solve these problems for yourself. If you can't, well you shouldn't be using Kohana then.
Have you built something similar and could give me recommendations on a project structure?
Once you understand how Kohana 3 finds files things are easy to understand.
|- classes
|-- controller
|-- model
|- views
For example:
Controller_Mathew extends Controller
Will look for a file called mathew.php in:
classes/controller
Underscores can be used to specify deeper directories. Example:
Controller_Mathew_Davies extends Controller
will look for a file called davies.php in:
classes/controller/mathew/
As you can see, the underscores in the controller name act as directory separators. This rings true for models and vanilla classes.
i would use the auth module that comes with kohana for the login. This will give you the roles table where you can setup the possible permission options and relating them to the users later. After that you can check inside the __constructor() or action_function() of each controller whether the user has the required role e.g. with the ->has() function. You also should use the ORM module, its just awesome, since you have many relations between the tables. Also the __get() method inside an ORM object can be extremely handy.
Its also pretty easy to extend a controller function by setting the new parameter to NULL and checking for that in a if statement. e.g. you need only one function for editing a old entry or adding a new one.
public funciton action_manage($id = NULL)
{
$entry = ORM::factory('entry', $id); // if id is null a new entry will be returned
}
It's also important that you structure the views into sub folders to avoid a messy view directory.
The web-based application I’m currently working on is growing arms and legs! It’s basically an administration system that helps users to keep track of bookings, user accounts, invoicing, etc. It can also be accessed via a couple of different websites using a fairly crude API.
The fat-client design loosely follows the MVC pattern (or perhaps MVP) with a PHP/MySQL backend, Front Controller, several dissimilar Page Controllers, a liberal smattering of object-oriented and procedural Models, a confusing bunch of Views and templates, some JavaScripts, CSS files and Flash objects.
The programmer in me is a big fan of the principle of “Separation of Concerns” and on that note, I’m currently trying to figure out the best way to separate and combine the various concerns as the project grows and more people contribute to it.
The problem we’re facing is that although JavaScript (or Flash with ActionScript) is normally written with the template, hence part of the View and decoupled from the Controller and Model, we find that it actually encompasses the entire MVC pattern... Swap an image with an onmouseover event - that’s Behaviour. Render a datagrid - we’re manipulating the View. Send the result of reordering a list via AJAX - now we’re in Control. Check a form field to see if an email address is in a valid format - we’re consulting the Model.
Is it wise to let the database people write up the validation Model with jQuery? Can the php programmers write the necessary Control structures in JavaScript? Can the web designers really write a functional AJAX form for their View? Should there be a JavaScript overlord for every project?
If the MVC pattern could be applied to the people instead of the code, we would end up with this:
Model - the database boffins - “SELECT * FROM mind WHERE interested IS NULL”
Control - pesky programmers - “class Something extends NothingAbstractClass{…}”
View - traditionally the domain of the graphic/web designer - “”
…and a new layer:
Behaviour - interaction and feedback designer - “CSS3 is the new black…”
So, we’re refactoring and I’d like to stick to best practice design, but I’m not sure how to proceed. I don’t want to reinvent the wheel, so would anyone have any hints or tips as to what pattern I should be looking at or any code samples from someone who’s already done the dirty work? As the programmer guy, how can I rewrite the app for the backend and front end whilst keeping the two separate?
And before you ask, yes I’ve looked at Zend, CodeIgnitor, Symfony, etc., and no, they don’t seem to cross the boundary between server logic and client logic!
You and everyone else with a brain is asking this question and it's a sticky one. A really good Information Architect thinks in terms of usability, behaviors and flow, although he/she may not even know how to use design tools or be able to draw or program. If they can get an interface into a sketch, the designers can make it pretty. Let the designers do the looky feely STATIC stuff--that's what they are good at. Provide IA with a library of front-end behaviors that they can specify for screen objects. They don't implement this stuff, they only USE it. This is much easier if you use a front end tool such as JQuery, and it's great if you have a front end guru who understands both design & the back end quite well. Separate your javascripts into their own directory and always link them as external files. All the PHP frameworks have methods to do this dynamically. I have toyed with the idea of a config structure that maps files to all the front end stuff that they load so each individual view only loads what it needs. But you are absolutely right: There is a whole nother sub-MVC for the clientside that lives primarily within the views of the overall MVC. I think you can partition off the Ajax stuff (when the view needs to refer back to the server) I document Ajax controller methods as ajax methods and don't call them otherwise. A lot of it is having everyone on your team buy into the division of labor paradigm. It will just cause them to write more decoupled reusable code whatever framework you ultimately choose to hang it on. And you're right, you can do the front end encapslation with all of them, but NONE of them enforce good front end encapsulation, I think that's still in the realm of DYI. Good luck.
Sorry for the confusing title....
We are developing an application to be used by multiple companies. For the most part, the application is the same, your standard sort of database manipulation pages (search pages, edit pages, etc.) customized for the data that it is designed for.
However, each company has a slightly different process, and we will be dealing directly with each company so we'd like to use some sort of system that would allow us to tweak pages depending on which company is viewing the page. For example, one company might want a couple extra fields on a data input page, or another company might want to view a different piece of data on a search results screen, and so on.
I understand this is all hypothetical and I wish I had a concrete example to give you, but honestly the companies haven't even given us very good examples. We just want to be ready.
So my basic question is, what is the most flexible way to allow for these tweaks and customizations on a per-company basis? Obviously, the most flexible but least programmer-friendly way would be to make a complete copy of the app for each company. This obviously isn't an option because we'd need to manage updating code on all the sites, trying to keep them all running and tested and having issues resulting from the customized code.
What are your thoughts on Smarty being a solution to this? Perhaps if we have a master set of templates, but then each company can have a different subfolder with any replacement template files... Of course we'd still need to update a bunch of different template files whenever we change one of them, but it would be a little more localized anyway.
Is there a better way? Some sort of differencing template engine maybe, so that we can still edit the original files and the changes will adapt on top of the originals (kind of like a patch)? Or perhaps we should use the object-oriented features of PHP5 and then use polymorphism? What is your best suggestion, and especially if you've had experience with this sort of thing, what are the options and which have you used and why?
I think the template method pattern will help you out a lot. It's really a great pattern for factoring stuff that is mostly the same but differs in a few places. I'm actually working out a template method hierarchy for my own project right now.
I would suggest you try to create the application either using an mvc framework or using your own implementation of mvc.
In this manner you could create models that could be reused (and also views) for other companies.