I'm about to start on a small, static website project: no database or CMS required. Basically, a brochure website.
I used the CodeIgniter framework recently to develop a full-blown web application, and I'm wondering if it appropriate to also use CI for smaller, simpler sites.
Typically for a static brochure site I would write regular PHP pages with a few includes thrown in to save on repetition (i.e. HTML with a sprinking of PHP), but this time around I'm wondering if my new friend CodeIgniter might be able to streamline the development process.
Is it sensible to consider a framework for such a simple project, or is it overkill? I'm worried that I might be the proverbial carpenter whose only tool is a hammer, and sees every problem as a nail!
I think almost never, the needs change and come more with time... so it is better to have a good base using a framework to wait the future needs. but if your project will not have a long live time and your needs are reaaally simples then i think is not necesary use a framework.
I personally would never develop a site outside of a framework for anything more than a single page brocure-ware site. I work so much faster inside the framework.
I'm a Python/Django developer but here's my take.
I've done some small non-framework sites with PHP and I don't know how PHP frameworks compare to DJango, but if they're anything alike the fact remains that I'm far more proficient developing within a framework than to code something from scratch by hand.
It helps me stay organized if nothing more than giving me the VC of the MVC. Django provides me with a lot of built-in tools, like form handling, that make my life much easier even for small sites.
I'm going to presume PHP frameworks provide similar things, maybe not though.
You also can't anticipate how the site will grow over time. It's easier to maintain something built in a framework, and if you ever need to extend the site in the future it's nice to have some structure behind it.
Since I tend to either inherit bespoke frameworks, or write my own, I would peg it at about 3 pages: if it's more, then setting up a framework is worth it. And if it needs a DB, then odds are good you'll end up with more than 3 pages, anyway. :-)
I recommend Rapyd, a "minimalistic and rapid PHP framework".
How long is a piece of string?
I use CodeIgniter (specifically PyroCMS) for crappy 5 page brochure-ware but that is purely to let clients admin their own pages easily with a WYSIWYG.
Any client will say "Wow, news, contact form and I can get me some of that Twitter too?!" so I just dump it in there to save everyone time.
If you are developing from scratch there is no point if the content is static. Something like CodeIgniter helps with DB interaction, Form validation and the breaking down of multiple pages into logical chunks i.e Controller classes and methods.
If you have no db-content, don't handle forms and don't have many pages then there is litterally no point adding the overhead.
That said, try my Twiny framework for literally the smallest MVC framework around.
If you don't need a database, CMS and is just a simple static HTML/css/PHP page, I don't think you can go wrong creating a site without a framework. Plus, if you have been using frameworks for a long time, you can have a break and do "code for code" and have a feel what it's like to code from scratch :)
Site is never small if the client is there who may want to ask you to add more functionality at any time :)
For a simple site like that. why even use a framework why not use something like concrete5. Overkill? definitely. but hey it is easy and requires almost no coding so upkeep is a breeze.
The site would be up and running in less than an hour and it makes you look good in the eyes of your customer and that can't hurt.!
I don't think any project is too small for a framework, I think some frameworks are too big for small projects. Everyone hopes their website will grow. So no matter how small the site is now, growth will be easier to manage if you start with a framework.
The only case when framework would be an overkill is with a throw-away scripts, such as when you need to quickly automate something that you won't need to do again ever. For anything that will enter execution cycle more then few times framework is a probably would be better.
If it requires under several hours of work - then it is small. Anyway if you plan to devote more than "several hours" - definately use a framework AND a control revision system.
It depends. If you're positive this is all the site you're working on will ever be, or migrating when future needs arise, then I can't see why there would a reason for using a framework, unless you feel more comfortable working with one.
As a personal example, I recently worked on a semi-static website, for which I put together a minimal framework which worked as a caching preprocessor for static html, inserting common html-elements into preset places. This allowed for some dynamic content, yet still using only static html for content.
I'd say you're answer lies within a formula consisting of future development needs, your own working preference, and performance.
Related
I like CodeIgniter for php development, but I have a client with no tech skills that wants to make his own changes to his site. I taught him how to make pages in MODx (that was a feat in itself). Is it possible to develop a site with CodeIgniter and use MODx as the content management system? Will MODx mangle the framework?
Short answer is "very probably". There's a good chance that modxcms handles all routing, controller actions, etc. on its own. There probably is no simple way to plug either one of these into the other.
Long answer is "it depends" followed by these conditions: what framework does modxcms use? How does it handle calls through its index.php file? What's the overhead of modxcms? If you want to manage routing in CodeIgniter, how will modx interfere? How would it be possible to have these two systems work together absent a some major refactoring of code?
Typically, it makes the most sense to stick to CMSs that are built on a platform that you like. For CodeIgniter, the only one I know of is ExpressionEngine, which is nice and all, but it costs. Other CMSs that I've experienced like Joomla or Drupal are a disaster if you're coming from something as clean as CodeIgniter.
So...not sure if this really helps you much, but I'd operate under the assumption that you can't (or at least shouldn't) mix CI with modx. IMO, it's easy enough to make a decent CMS using CI alone, giving you much more immediate control over the presentation. In my experience, taking a CMS like Joomla and trying to turn it into a complex alternate creation is probably one of the most annoying things a programmer can put himself through.
My company is looking at various PHP frameworks to build a customer's site. This is a shop that has some legacy in-house frameworks and we're trying to move away from that. In my spare time, I've coded in CodeIgniter and dabbled a bit in Kohana. I have yet to use a CMS like Joomla or Drupal, but I recognize that they're built using an MVC and PAC design pattern respectively. In starting my excavation, I came to the preliminary conclusion that it might make more sense to use something like CodeIgniter to build the user-facing portion of the site and something like Joomla to build the admin-facing portion of the site, such that Joomla is never loaded unless you specifically go to admin.xxxxx.com.
So following this logic (and please do let me know if it's very flawed), I'm here to ask if anyone's ever done anything like this before, and if so, what might be the best method of taking advantage of some of the more automated features of Joomla (sorry if I don't go into too much detail here...I haven't studied Joomla enough to know everything about it....please correct any gross cognitive errors!!) from within a more lightweight framework like CodeIgniter.
Or is this going down the wrong line of thinking? My first instinct is to just link the two by data in the database and never have them communicate directly, but I just wanted to be sure this was correct before I take it to my superiors.
Vielen dank, guys
Quite possibly flawed, all of these CMS's run on assuming that they are used for both admin and user site, the major problem this causes is that code and the way things work are very intertwined meaning that a simple 'hook in to the database' often isn't enough and you'll have to use most of the CMS code just to pull / put valid data - the other caveat with that is that if the admin is upgraded, it can easily change the database schema which would break your front end.
I'd highly recommend going with one or the other, either your own design using frameworks for admin and user site(s) - or just stick to single CMS and bolt on whatever functionality you need with plugins.
Best!
I Agree with Nathan.
When you're using pre-built frameworks you lack the control factor over the core elements, this is not good especially developing for a corporate system, you need to have full control over every part of the system for future developments / integration.
My advice is to start with a small but abstract system it would be more beneficial, my advice is to use a framework like codeignighter that consists of an MVC Pattern but also plays the simplicity role with ease.
Take a look at the OpenSource application called "OpenCart" which is a small MVC Store, the reason I say look at this is because it's an extremely basic MVC Pattern and can be abstracted for your applications.
Hope this information helps.
Regards.
When your using pre-built frameworks you lack the control factor over the core elements, this is not good especially developing for a corporate system, you need to have full control over every part of the system for future developments / integration.
Well I don't know if i would necessarily agree with you about this?
Would creating a custom php mvc framework from scratch be completely pointless for a small digital agency?
I have heard recently from a friend that His colleges are infact spending time on such a project within their agency. Their argument against using another such as cake or zend being that they come with so many unused features and therefore lots of unnecessary code.
I would have thought that such an endevour is completely pointless and indeed a waste of time and money. Surely it would make more sense to pick a framework that matches your needs as close as possible and then customise/extend it. On such frameworks as zend the code is surely going to be of a much better/tested level than that of 1 or 2 programmers could create in a few months.
It just doesn't make sense to me - can anyone pursuade me otherwise?
Using your own framework has one big advantage over other solutions. It means you have total i mean TOTAL! controll over it. No matter what happens to other frameworks, because one day you have open source software and another day it could be abbandoned or stopped project. And your framework will still be developed. Even if it means you will need to constantly add some features to it, with time it will pay off. Besides, PHP is like one huge framework after all, and it's evolving. Writing your own framework will keep you up to date with this technology :) Of course keeping with other frameworks or CMSes is also good idea, because maybe your clients will want to use them, and you can also learn from them and move some solutions to your software :D
No, I think you will find most here would agree with you - I certainly feel it is a complete waste of time. Especially given that they are a small agency, their limited resources could be better spent elsewhere.
Since they are concerned about a bloated framework, I suggest that instead they investigate using a lightweight PHP framework such as CodeIgniter and Kohana.
I see it pointless. But it's a curse of PHP programmers who tend to invent wheel again and again. I know what I'm talking about. I tried it too.
The best approach seems to be to learn a framework and if it doesn't suit you ask friends who knows other frameworks to learn how is the particular problem solved in other frameworks and if none of them seems good then MAYBE it's time to start work on a new framework.
The point with lots of unused code is not completely valid. Zend contains classes that can be stripped off as far as I know.
EDIT: Performance of PHP can be enhanced via eAccelerator for example. I find it easier than building a brand new framework.
MVC FW is less than 5% of average project code base, so I strongly recommend building MVC for every project and adapt it to the project specifications.
If someone has enough knowledge about MVC pattern and some experience in using and building MVC frameworks, it can be built in some days.
General arguments are speed and performance given by the custom FW.
Sometimes when people are afraid of changes and learning new things, they come up with all kinds of silly reasons why somethings is bad and should not be used.
I once worked in company that was determined to write their own web framework instead of using Django. One of the developers that was working on "admin" part of framework said i wanted him to lose his job cos Django has auto generated admin.
Unless is it very specific framework and you have very good reasons and enough fundings for project it is never a good idea to reinvent the wheel specially if you can't make it the same or better quality then what is already out there.
It depends on what kind of projects they do, and what are their needs. Never forget that in software, the 'best' always depends on what you are doing. There is no 'one golden solution' for everything. This includes mvcs.
There are various reasons to code your own mvc :
You can tailor it to your exact specific needs
You can keep it closed source, reducing exposure, increasing security due to obscurity
You can continue developing it, and then release it to the world when it is mature and fulfills a major purpose - a lot of current mvcs came to being in that way anyway.
You can continue developing it, keep it closed source code, and build massive SaaS services and applications on it, to which you will retain full rights. Can be done with apache license too though.
You can fulfill a purpose that is not fulfilled by any other mvc. Despite every mvc has its zealots who believe that they have the one and all solution, every mvc has its downsides. And believing that 'everything that can be done, has been done' because there are 15-20 mvcs out, is as stupid as saying 'all that can be discovered has been discovered'. And there were people saying the latter at the start of 20th century.
Not to mention that with an external mvc you are using, you are obliged to that mvc's project team for many things. They may already have or may introduce things that you dont like, or even hamper your specific applications.
Not to mention they may just get abandoned. Can happen to the biggest. Codeigniter was all the rage. What happened ? Ellis is dumping it basically. Development slowed down to a halt. Probably soon totally halting. Being open sourced does not guarantee a project either - there have been many open source projects which went similar ways.
What's going to happen to people who had coded major applications with Codeigniter ? Are they going to undertake the security of the Codeigniter installations they have themselves ? Therefore de facto becoming maintainers of their own mvc ? Or are they going to hire external parties to maintain the mvc for them ?
Not a good future investment.
My preference for coding my own mvc is mainly to have a mvc that fits my own style of coding. My criteria for a mvc :
Fast development
Fast modification
Low maintenance
Speed
Security
Extreme simplicity
Reliability in regard to future development
I have coded a major mvc for myself before. and i am still successfully running it on one of my hobby websites which handles ~600,000-1,200,000 unique visitors per month. At a given moment, 250+ visitors (google analytics - it doesnt include any bots) can be present on the site, hammering page after page. And it does not even blink. I like that. Despite it has various shortcomings that i dont like, it works spectacularly.
In the current mvc im doing, im using the lessons i learned from the previous one, as they apply to my specific purposes.
Not to mention it is a great way to hone and develop new skills.
But one thing is a must: plan it very well, and keep building on it, changing and improving it.
For any framework
Pros
get exact functionality you want
control over small details important to your project
familiarity with code
Cons
everything that breaks you must fix yourself
don't get to learn from the mistakes of the past
won't get as many bugs noticed due to smaller audience
Personally I recommend exploring existing frameworks before even considering writing your own. Just remember that it's okay if you don't understand it all in a day!
It's a waste of time. Unless they are building a site with the traffic of Facebook, the performance hits they will get using something like Yii vs. their own should matter very little
It's not necessarily a waste of time but I agree with you, I tried it myself too. I've been using Zend, Code Igniter and Fuel depending on what project that I'm working on.
The consequence that I had in creating my own framework is the deadline. If you're working on a project with a very tight deadline then creating your own framework would be a bad idea.
I am building an application currently in PHP and I am trying to decide on whether to use a pre-existing framework like codeigniter or build my own framework. The application needs to be really scalable and I want to be completely in control of it which makes me think I should build my own but at the same time I dont want to reinvent the wheel if I dont have to.
Any advice greatly appreciated.
Thanks
Use an existing framework.
First of all creating a framework from scratch represents a massive investment in time and effort. The process involves a lot of trial and error, because you're designing something that needs to be both simple and powerful. For every design decision you'll have to ask yourself how it will affect every single future project that will be built on your framework.
You'd think that you could take each design decision and weigh it against the requirements like you would do for any other software project, but the thing is you don't know your requirements. You can't know them, because a framework is supposed to be able to do almost anything (or have the ability to be extended to do almost anything) within its domain. Future project a will need to be able to do x. Can your framework allow that without turning it into spaghetti code? And what if project b needs to do y? What if project c needs to do z?
Have you predicted everything?
Now the normal response to this is that if something doesn't work, you'll just change it in the future. It's software after all. A framework however isn't like a simple application. It's supposed to have an interface and once you expose that to the software that will be using it, you can't change it. You can extend it, but not change it. So now you have to think about deprecating methods, api versions and version compatibility. It's a whole new set of problems to deal with along with normal framework maintenance and new application writing.
Then there's documentation. You need an API, tutorials, example code. Once you build your own framework you have to deal with this as well. You could ignore it, but I assure you that eventually you yourself will need to find out what that method you wrote 6 months ago does. What does it return? What if special case x happens? Have you written all that down, or do you need to step through the code again? And I wont even mention how easy it will be for a new team member to get started on a custom framework whose documentation lies completely or at least mostly in your head.
You also have to acknowledge that unless you're working with the very best and brightest (and have a budget to match) you'll never have the extensive set of libraries that existing frameworks boast. Can you analyze, design, code, test and debug faster than an open-source community?
Finally you should ask yourself if you are proficient enough to be writing a framework. Have you dived deep into the code of a modern OO PHP5 framework to find out what makes it tick? And most importantly do you know why it does things that particular way? Keep in mind that any mistake you make in your design can blow up in your face months from now and you can end up paying for them over and over again.
To sum things up I'd advice you to go with an existing framework; it doesn't mean however that you have to pick one and like it. Take the time you'd otherwise devote to developing a new framework and devote it to learning an existing one. Then you can extend it to fit your needs. Also remember that there could be things you wont be able to do. But I assure you there would be things you wouldn't be able to do with your own framework either, so it doesn't matter all that much. A framework imposes a few limitations. It's the price you pay for being able to develop applications faster.
Make a list of requirements for your framework (ORM, PHP 5.3, PDO, etc). Then iterate over the existing frameworks and narrow them down to find the ones matching with your requirements. Then look at the codebase, documentation, community, project activity – does it feel something you would like to work with? Also be realistic about the time needed to to implement all your requirements by yourself – do you want to focus to building an application or a framework?
I'm building my own and I'm very glad I did in terms of learning, which is important to me. Also I LOVE to be in total control of my code. It comes with lots of negatives though, the big one being I'm the only one that knows how to use it. Also, a lot of development time is spent on improving my framework rather than delivering products to my clients. But I can't stress enough that I really, really enjoy building and using it.
If you want to learn (A LOT) build your own. If you just want to get work done use an existing one. (Before starting my own I almost went with CodeIgniter)
While I've build my own CMS framework in the past, and used custom (in-house) general php frameworks, I'd find an active framework that fits your development style, and use it.
Unless your main product/application is the framework. But it doesn't seem that way.
Your concerns about control and scalability should be applied to the host of frameworks out there - giving you a short list of options that fit your requirements.
Certainly, it's not a question of 'in-house' vrs 'public', then once you've made that call just pick any old framework.
To answer the question behind the question, for a framework that gives you complete control and should be able to scale reasonable well (I'm not sure how you need the framework to scale), I would suggest the Zend Framework. You can use single parts of it, rewrite what you want, and it's far more than just a MVC implementation.
Update: A quick example of customization with Zend. If you don't want to use their MVC stack, but need something to route requests, you can just use Zend's router library. If you like the MVC stack, but hate the way the router works, you can just implement the interface and write your own router.
This applies outside the MVC stack as well. Zend has a ton of libraries for mail, rss feeds, caching, auth, db, etc. Use what you want, and ignore the rest. Extend what you want, most of the framework is tiered with interfaces/abstract/generalized classes that you can build on if the standard functionality doesn't suite your needs.
The decision is very plain and simple.
If you want to learn and have full control - go for your own
If you want just to make money fast - go for ready made one.
I work in a company that initially wrote its own framework, built by a guy that worked here. It was only used on one project. The reason for this is that we soon realized that although it was clever and very good, there was no documentation for it. So if we employ another developer or a freelance guy, they'd have to learn it.
We run with CakePHP for a while, which is popular, but it does seem a mess. We eventually settled on KohanaPHP. Easy to extend, some good documentation (probably not up there with some others though), nicely formatted code (meaning if you can't find documentation you can quickly work out whats going on). The way the framework is written makes it pretty easy for a developer to pick up and follow what is going on. Whereas we always had trouble doing this with CakePHP.
I think the only argument for rolling your own framework is that you may want some highly customised stuff. But Kohana is so easy to extend, you can just throw it in there. You don't have to use their packed libraries if you really don't want to.
That said, some project I don't bother with a framework at all, just some sort of routing solution, like GluePHP. Since it would be overkill to use a full stack framework.
If you were just trying to practice, I'd suggest writing your own. Otherwise, though, definitely go with using an existing one. Symfony ftw.
The short answer is symfony2 IHMO.
The reasons are:
do not reinvent the wheel
a good wheel is better than yours (others are professional wheel makers,
since a lot of time)
an OSS framework can be expanded or modified, even only inspected
first or later you will not have time to maintain your own wheel
a number of eyes and hands do it better than 2!
Of course the previous points are valid for a very small set of professionally made frameworks! My favorite is symfony2, but there are a number of good alternatives.
This isn't a question about what framework to use. I've learned both Rails and Django, and I write all of my webapps in PHP. My question is why bother with the frameworks? It's always taken me longer to use a framework than to reuse old MySQL code and build "models" with phpMyAdmin. I also like writing everything myself, because I know what's going on. I can still reuse functions, etc. and do things how I want, and this freedom seems to be missing from most frameworks.
I'm not saying that my way is right; in fact, I'm trying to figure out where my logic fails. The hype can't be just thin air. What am I missing?
The basic idea of a framework is to allow you to work at a higher level of abstruction and write only the code you have to write to implement your specific requirements. All the other repetitive stuff is handled for you by the framework, and probably with far fewer bugs and security holes than if you did it yourself.
It may feel like it takes longer to learn a framework than to just do it yourself using basic language features and standard APIs, but it's simply not true - not if the framework is good and the app is non-trivial, and especially not once you have learned the framework (using a different one for each new project would of course be idiotic) and factor in the time it would take to find and eliminate all the bugs and correct all the design mistakes that have long since been found, eliminated and corrected in the framework by its developer community.
Almost every developer has cowboy coder instincts that tell him "Doing things yourself is much more fun than using code others have written, and I'm sure I'm good enough to get it right the first time, so it will even be faster and better!". These instincts are almost always wrong.
Frameworks allow you to concentrate on the application itself rather than worrying about the boilerplate code that you'd otherwise have to write for every application. They allow you to structure you site in a much more logical (mostly object-oriented) way, using tried and tested design patters such as model-view-controller. The code in framework is generally more mature and of a higher standard than code you would write yourself for one-off projects as framework have a large community of developers perfecting the code perfecting the code over year. This means that framework-driven sites often perform better and are much more secure.
You also mentioned you like writing things yourself - I know where you're coming from. My solution to this was to write my own framework - I get to reuse and improve my code with every project I do and I know the entire codebase inside out.
Writing it your self may make it easier for you to understand things your self but unfortunately it can make it much harder for other developers to understand what is happening. Frameworks will often be better documented and have a larger community that can support a new developer that is working on the app that you wrote.
I think a big part of it is what you focus on. Frameworks standardize the parts that you shouldn't have to keep revisiting, which helps you focus on the application as a whole. If you reuse your own code all the time you're already using your own makeshift framework.
Your comparing a framework (Rails) to a language (PHP). A framework is going to give you pre-built components so you can spend time on what makes your project unique.
You may already have a code base that helps do this for you. Check out some of the PHP frameworks since that's where you are more comfortable. Take a look at CakePHP, CodeIgnitor and/or Zend Framework.
If you are building many small apps/sites, using a framework may make your life easier.
I think a good step for you is to create your own framework with the code you've programmed so far. ;)
Try to make your code parametrizeable, in other words: create components which you can reuse in different parts of a website (for instance: styled containers), or in different websites (form generators/validators).
You can even go further and create base-classes from which you extend new classes to build your websites. (for instance: data objects with generic select/insert/update/delete methods).
I bet this gives you the best view on why frameworks are so damn handy ;)
It'll take you longer to initially use a framework for the same reasons a PHP developer would take longer to initially use Ruby - you're not familiar with it.
Once you're familiar with them, frameworks can offer the ability to skip the mundane and focus on actually writing the important parts of the app.
You should also just use a PHP based framework like Symfony or CakePHP using them should reduce your production time considerably.
One reason to use a frame work is code separation. Take symfony for example. The model is all done with propel or doctrine libraries. Very little SQL needed. You instantiate a new object and user getters and setters, to store your data, and instead of writing SQL in your page code you create functions in the objects related to the query. When you need to access the same kind of data on different pages you are asking the model for it, keeping the business logic with the model where it should be, so there's never any difference. All the work is done in the "action controller function". You get all the data you need, and then put as little php in the display, basically just echoing the variables you got in the action controller, (with the exception of some for loops and if statements for conditionals. I have found this a more efficient way to code, and on my 2nd project saw the production time cut in half.
You don't need to learn a new language python/ruby just to use a great framework, just have to fin one that works for you.
First, PHP has frameworks too, so the question as stated misses the point.
Yes, you can write your own framework, and as Kris said, there's no shame in that. However, part of the leverage of code reuse is the collective value of the efforts of many. It's not just about reusing your own code. Frameworks encapsulate the common tasks and patterns we all share and provide well tested solutions with many iterations of improvements from the community. No individual effort is going to measure up to that, no matter who you are.
If you roll your own, it will only become world class due to the collective effort of world class people, and that will only happen if your idea merits the attention. The top frameworks out there are already proven on those criteria.
DHH is a smart guy, but the Rails we have today never could have been realized by him alone. Not even close.
If you like "writing everything yourself" as you say, then choose a framework with a core philosophy that matches yours, and start making core contributions in the areas where you can see room for improvement.
Depending on the functions of your Web Application, it can be faster to develop without a framework. For example when the Webapp is just some kind of data viewer.
But as soon as you begin to implement more advanced functions, you are much more efficient with a framework.
Try do do this from scratch:
- proper Form validation
- Handling of multiple Language and Date/Time formatting
- Authentication
See a framework as free tools and stable implemented function for you to use.
Sounds to me like you have already written your own framework in php, since you do mention code reuse.
I can imagine it being easier to use your own set of wheels instead of adapting to someone else's. No shame in that.
Frameworks are there mainly to help people who are semi-new to PHP (or the specific language it is built on) to be able to build a website to an extent that it is secure and easy enough to add on extra parts to the site without having to know a lot about the specifics like security, MySQL (or other database types). In my opinion it is a fairly good way to help break coders into a language, allowing for the fact that the framework isn't too complex of course.
EDIT The reason behind me saying they are for beginners is because myself, as a beginner has used frameworks to break myself into languages a lot better.