I am looking into developing a commercial application using PHP. Since I have experience in CodeIgniter and it has been working well for me, I decided to use it. Now, if ever my application comes to a point that it needs to grow and have to have custom modifications in the platform, is it possible to modify the CodeIgniter source code to the point that it's far from the original?
I'd strongly recommend not modifying the source code as this is the back bone of the application will make updating to futures releases of codeigniter impossible.
Instead you should be creating your own classes/libraries that extend the core bases. This is best practice.
The codeigniter users guide has some fantastic information regarding this, http://codeigniter.com/user_guide/general/creating_libraries.html
Good luck.
Don't modify it, extend it. Ellislab is good about releasing bug fixes and patches, and the last thing you want is to have to re-engineer all the updates into your new hybrid everytime they release updated source code. Plus, different features and bug fixes are released at different paces for the core and reactor, so unless you plan to lock your framework in at the current version, extending is the way to go.
The good news is CI is built for and encourages extensions of the source. The system folder and the application folder separation are a clear indication of how you should segregate your enhancements from the base libraries.
CodeIgniter is written in PHP. You can completely rewrite the framework anyway you like. So the answer is "yes".
There are many big websites that were written in a different language or build on a framework when they started and have been rewritten many times since. I think a lot of developers (mostly freelancers) are over-thinking when starting out. When I start a project, then I try to get it done and get it out in the web asap. If a website starts taking of - and most of the times start making you money - then you can always take the time to rewrite it.
I think it is a lot more important to spend time when you plan and design your database and tables. I think it is a lot harder to redo parts of your database later on then it is to rewrite the code that uses the data.
Just my 2 cents.
If you have used CI, then you should know that being a PHP framework that all of the source-code is there in the download, furthermore opening the system and application folders and looking through there will tell you a lot. Yes all of the source is there in plain English (plain programming English) and not only is it in plain English but has been extensively documented inside and out (literally that is in the source and in the user-guide). CI gained initial fame from that simple fact, that all code is extensively and meticulously documented.
Beyond all that, the question itself raises concerns that maybe you should study CI a bit further before writing commercial applications using it. Ci is a powerful and very easy to use PHP framework, but it is not a WYSIWYG. In my opinion, a coder should know his tools inside and out in order to be able to create a solid secure and trusted application. The first measure of which is to read the user manual, you should know at the very least everything in it, and since there are 12 sections in it that cover everything from extending CI libraries to creating your own libraries, and everything in between I would say you need to spend a little more time with it.
I want to say though, I am not being rude or trying to shame you in any way I am simply saying that you should learn the framework a bit more before venturing into a commercial application using it.
In the early days of PHP people realized how amazingly easy it was to use and how fast you could write an application with it. At the time the major options where very difficult for new and hobby programmers to use or involved expensive software to run, PHP was free, easy to learn and most of all ran on a free OS. It also took hardly any setup to get going, you could download PHP and essentially be programming in minutes. All of these factors lead to the almost destruction of the language.
Entry level programmers were destroying it with bits of code taken from other applications, never knowing (or caring) what the code actually did beyond the simple fact that it did what they wanted at the time, never considering or even investigating if the code might be harmful. Because of this practice PHP applications that had grown to Goliath sized websites, taking thousands of hits an hour were:
beginning to crash
being hacked to reveal sensitive customer/client data
generally crumbling all around the web
All because since the language was so easy to use that people had taken advantage of it and failed to take time to learn it. PHP was becoming a joke to other professional programmers and wasn't even thought of as a viable application language by many who had dubbed it "the copy and paste" language.
So my advice to you, please take the time to know your tools inside and out, what makes them tick, if they have any gotchas and where they are vulnerable. I understand that in order to learn a language to a professional level you have to build with it so I suggest that you take it slow with CI stick to the core for now. Trust me when I say that even in its purest form CI is an amazing and powerful tool that in the right hands can create awesome powerful web application, but in the uneducated/inexperienced hands it can create havoc and destruction.
So (stepping off of the soap box) I simply ask that if you are serious about creating commercial applications period that you take your time and learn your tools/language become as close to an expert on them as possible. I gurentee that if you do that you will always have work when you need it and you will spend less hours beating your head against the table or worse explaining to a client why their site is down.
I truly wish you good luck, just slow down and learn your trade and you will do just fine.
Yes, Codeigniter is an open source framework. However, I would advise against modifying the core of Codeigniter, as most files can be extended and rewritten safely without modifying the core files which will cause you headaches if you ever decide to update.
To extend a core class by default you would do this in Codeigniter. We'll extended the parser class for this example, but this applies to all classes pretty much. This link in the comprehensive user guide will give you all the information you need to extended and overload methods inside of a Codeigniter core class: http://codeigniter.com/user_guide/general/core_classes.html
Related
A partner has a website that needs to be rebuild from scratch as it simply can't cope with the large number of visitors (currently build using SilverStripe). The site should be able to deal with 5 million or more members using 20+ languages.
We were considering using CodeIgniter or YII because from research both appear to be excellent performers. However several people advised that we should consider the latest version of Joomla for this. For small websites we are happy to use Joomla but for a heavy load website our feeling says that we have to stay away from that. We are however not able to find any comparison between both from a performance point of view but we do require good arguments why Joomla would or would not at all be a good candidate for this. One comparison can be found here: http://vschart.com/compare/yii/vs/joomla/vs/codeigniter however this doens't tell me what to expect when the number of visitors is really high.
Can some advise how Joomla compares to CodeIngitor or YII considering that the site will receive a very high number of vistors and will use a 20+ languages (for silverstripe we build a translator module as the build in CMS was not usefull when using so many translators).
When you're dealing with a site of that scale, it's probably best not to shift to Joomla. Joomla can handle a fair bit, but I'd suggest that it would be far easier to have a Joomla site that large when the site has been adapting as the traffic increases.
Part of what makes your question hard to answer is that we don't know much about what your current site does.
Is it mainly a CMS? If so, Drupal may be a decent fit for you.
Is it a custom web application? It sounds like it could be, based on the number of translations you're handling.
Is it somewhere in-between? This could also be what you're dealing with.
If you're looking at either of the bottom two options, yes, shifting away from SilverStripe (but not to Joomla) sounds like it might be a good thing.
Given the volume of traffic you're dealing with, it sounds like you probably already have a revenue stream and a development team. In that case, it might be worth having a few of your developers play with CodeIgniter and Yii and see what they think.
I wrote up a detailed answer to a question about what type of framework to choose a while ago, which you can look over here:
https://stackoverflow.com/questions/10095906/yii-or-zend-or-other-frameworks-under-the-following-requirements/10115678#10115678
I'm a Yii fan, having checked out a bunch of other frameworks. Regardless of which framework you use, I'd like to offer one piece of advice that I've found key on all projects I've worked on.
You want to work with objects, not data arrays
The reason for the above is that your models (and the objects they produce) can end up having your business logic built into them. Doing this makes life far, far easier in the long run. A great book on the subject, aimed at manager's and quite high-level (there is no code, although there might be a few lines of psuedo-code), is Object Technology: A Manager's Guide. I'd highly recommend it.
Framework thoughts
CakePHP
I started dabbling with CakePHP until I found out it didn't hand back objects (just arrays), at which point I ran screaming.
CodeIgniter
Looking at what CodeIgniter has for database model support, I think you would quickly hit its limitations with a site of your size, so would recommend against it. And having EllisLabs deciding to leave CodeIgniter behind (see their website for more details) is not a good sign. The signs say stay away.
Of the PHP frameworks out there, these are the ones I hear the most things about:
Symfony 2
Yii (disclosure: I work with this one daily)
Laravel
Symfony
From what I can see of it, has been a huge stimulus to the PHP community and many best practices have come out of that community. Unit testing, Composer, pushes for PSR-1/2, the ideal of modularity of code (some of their core code is ending up in Drupal 8) are all great things that have spurred the PHP community into writing code that's better than spaghetti code. With that said, it feels kind of heavy and enterprise-y and looked to have a pretty heavy learning curve.
Yii
When I was looking for a framework, I had a lot of legacy code that needed migration. Yii's way of handling things, although opinionated at times, has done a lot for me as far as exposing me to good practices that are used heavily on the web. Highly recommended as well.
Laravel
When I was looking for a framework (2+ years ago), Laravel didn't exist. It's apparently quite slick and cutting edge (haven't looked at it yet, I've been busy landing new work regularly in the Yii world), but I am interested in dabbling with it. That said, here's a thoughtful article about Laravel and couple of considerations that I've wondered about.
The main developer, Taylor Ortwell, seemed to be a dominant force. That's a great thing while he's making money doing this and enjoying it. Not sure what would happen to the framework if he decided to do something else.
The speed of development on the framework is an awesome thing and means that all sorts of creative juices are flowing. It's a great place to go look at cool new things. That said, you're going to want your developers to be able to easily find information about the framework they're working with, which in 3-6 months may be severely out of date in the Laravel community. The Ruby on Rails community has the same type of good/bad problem when I've looked around over there; there is so much information about the new stuff that sometimes it's hard to find information about the version of the framework you're dealing with.
That said, there are lots of cool choices out there :-) I should probably wrap up, as this has gone on far longer than I'd intended. Let us know what you end up deciding and how it ends up going.
How big is the site really? Bigger than joomla.org?
Are you talking about big in terms of the amount of content in the database or in terms of the number of visitors.
Joomla really does not have problems with scale unless you are on an older version of MySQL in which case it slows down.
It depends on what kind of application you want.
If you want a CMS, Joomla is the way to go. Because this is what it was build for.
If you are about to create a real "custom" application Yii/Codeigniter is the way to go. (This is what yii was build for)
Regarding performance, from my expericnece Yii is a lot faster, because it comes with way less overhead. You can build the application just as you need it.
Well it's like compare green and salty. Really joomla is CMS, and Yii and CI are frameworks. If you considering make highload on joomla - it's not your job.
If you have high frontend load - maybe watch on js frameworks? Yii+backbone.js or ext.js for frontend is awesome, since you'll move alot to clientside.
CI is dead. I honestly like it, but its dead already. No extensions, no namespaces in future, nothing.
I can say + of Yii:
*faster then CI;
*have great documentation and wiki articles;
*have great and active community and developers;
What else i can add? Active record is good for small databases, but not usable for highloads. Also as i said on yii you can easily make js framework+yii composition. Yii have good caching system. Long time support of stable versions.
I personally manage highload now, but its more backend/api/database. 150+ thousands database records daily, 300+ thousands requests to api, 50 milions records data table. It works like a clock for more then 2 months already.
Choose what you like, or write on native php if its really big system - best choice from practice.
Joomla is an award-winning content management system (CMS), which
enables you to build Web sites and powerful online applications. Many
aspects, including its ease-of-use and extensibility, have made Joomla
the most popular Web site software available. Best of all, Joomla is
an open source solution that is freely available to everyone.
CodeIgniter is an Application Development Framework - a toolkit - for
people who build web sites using PHP. Its goal is to enable you to
develop projects much faster than you could if you were writing code
from scratch, by providing a rich set of libraries for commonly needed
tasks, as well as a simple interface and logical structure to access
these libraries. CodeIgniter lets you creatively focus on your project
by minimizing the amount of code needed for a given task.
Yii is a free, open-source Web application development framework
written in PHP5 that promotes clean, DRY design and encourages rapid
development. It works to streamline your application development and
helps to ensure an extremely efficient, extensible, and maintainable
end product.
Joomla can't compare with CodeIgniter / Yii. But, If you need any CMS for your project, you can use Joomla (or maybe Wordpress). If you want to create any web application, then you need to decide for any PHP Framework. I use CodeIgniter for years, and I like it. They have a huge community, and the best user guide. Yii also has a great community and a lot of features. So, you can decide depending on you demand.
I'm one of those classic native programmers that has spent most of his past with .exe's and .jar's. As of the past year I've thrown my self into the world of web frameworks and technologies that seize to impress me. As of the past 1½ month I have fallen In love with Go because of it's strictness, and also how 'stand-alone' it seems to be. So now to the real question...
Go app engine application, why do we need this?
What is the difference and reasoning to choose a wrapped application (framework)?
I assume its purpose is to load some of the communication off the application to the wrapper, but sadly I can't seem to figure out (through documentation and discussion) what the specific purpose behind this modulation is.
Best regards and cyber high fives in your direction!
These really are two different questions.
1. Why GAE?
It's up to you. GAE provides cloud-based hosting that you pay rental to use. It's a bit similar to Amazon Web Services. Your Go app would be uploaded to GAE, where it provides your web service and your users can do lots of wonderful things. Meanwhile you never need to know which actual server is doing the serving at any given time - the app can migrate across their servers dynamically. GAE provides a high uptime and a low effort for you in keeping the server secure, backed up etc. It will also be elastic to cope with surges in load.
You may instead prefer to rent a private server (e.g. at Rackspace) or just a virtual machine. You'd perferably need to be a Linux expert (get lots of help at Serverfault) and you'll have to do the backup, firewall etc all yourself. It may cost (much) less. Or more.
2. Choosing a framework?
The net/http API allows you to write HTTP server code to do pretty well anything you want. But you have to do quite a lot of hard work. At the opposite extreme, frameworks like Revel make rapid server development possible, as long as it does the things you want of it. If you stray into functionality beyond what it offers, you might have to do quite a lot of digging to find out how to extend the framework.
Other interesting toolkits include Gorilla, Gocraft Web and Goji. In terms of complexity, these sit about halfway between Revel and basic net/http.
To answer your second question, here are some pros and cons of using a framework (e.g., revel) vs. something simpler like a toolkit (e.g., gorilla)
In general, the pros of using a framework are:
it provides a lot of sub-packages to handle important web-related sub-tasks like templating, generating data in specified formats like json or xml, query escaping, etc.
it handles boilerplate http handling
it (hopefully) enforces best practices like escaping strings
it helps you manage complexity by enforcing a consistent design pattern in the way you handle requests
Cons of using a framework:
frameworks tend to be "opinionated," meaning you have to buy into their general philosophy and understand their core concepts before you can make use of them; for a lot of frameworks this can be quite a bit of mental overhead
extra layer of abstraction, meaning you're another step removed from what's really going on, and there will be more stuff to understand and debug if something goes wrong
it can be brittle and hard to do something that isn't a standard use case in the framework
future maintainability: most frameworks don't tend to have a super long lifespan. Django and Rails have been around for a long time, but there's a massive graveyard of frameworks that came before them. Hindsight is 20/20, but it's hard to pick the right horse from the outset.
Recommendation
It's hard to make the call upfront. So much depends on the specifics of your problem, but I'd say in the case of Go, opt for the simpler option. Much of the value-add of frameworks in other languages is the fact that they contain useful sub-packages that handle important tasks, but Go already contains a lot of these in its standard library (e.g., encoding/json, net/http, net/url, text/template). I've built a fairly sophisticated web app using just the Gorilla toolkit and the go standard library, and it's been amazingly good, and the best part is, it's incredibly easy to understand what the code does and I can explain it to someone else without requiring them to first read through the massive About page of some third party framework.
If you want to get a sense of how other people use Gorilla, you might try looking at real-world usage examples. Compare that to how people use more sophisticated frameworks and pick whichever you like better.
I've been reading up on several PHP frameworks, and reduced my candidates to CodeIgniter and Symfony (I know there are many more). Strongly leaning towards CodeIgniter, but have not 100% decided quite yet.
I'm not looking for a general "CodeIgniter vs Symfony" discussion.
One thing keeps coming up in comparisons: people say Symfony is for "advanced" coders and "bigger" sites; CodeIgniter is for "beginner" coders and "smaller" sites. But I have yet to see any technical proof of this. Everything I'm seeing about CodeIgniter feels right.
Can anyone explain structurally and technically where people are basing these statements on?
I want to understand all I can. Once I make a decision, I want to focus my attention on one framework.
Thanks,
Matthew
The biggest technical difference between CodeIgniter and Symfony (ver 1 and 2) is that Symfony is much easier to extend. This is especially true with Symfony2; you can replace entire parts of the framework as you see fit with custom code, or code from other libraries. You can even take any number of core components from Symfony2, and build your own framework on top of it. But, it's important to note that because Symfony is so 'advanced', it has a higher learning curve.
Here's how I see it: CodeIgniter is great when you have a small(ish) project that falls in the category of problems CodeIgniter is meant to solve. But when you want to do something your way, not CodeIgniter's way, you're going to have to fight the framework, which is never fun.
On the other hand if you're working on a Symfony2 project and want to do something your way, you can. It won't necessarily be quick, but it is possible. To me, that's the most important thing - you need to be able to make the framework do what you want it to do.
If you have time, read through the Symfony docs and cookbook - they should give you an idea of what Symfony is capable of and how to customize and extend it.
Everything I'm seeing about CodeIgniter feels right.
Then go with CodeIgniter. The most important thing is that you're comfortable with the framework/toolset. If you complete a project and find that it's lacking in features, you can always check out other frameworks.
I would recommend starting without a framework. If you have been programming awhile and are comfortable with concepts like MVC and why you might implement your code in this pattern, then frameworks start to make more sense.
Frameworks are good for larger projects where there are many programmers and you need a consistent method of building application layers, like MVC. The framework will likely provide some mechanism for object management and a consistent way for you to build application events (controller) and to separate the view logic from the model logic.
My PHP apps have been smaller, so I have not used any frameworks. When I used to code in Coldfusion, on larger apps, I used MachII, Model-glue, Fusebox and ColdBox. Each was good at something, each promoted consistency, but each had a lot of overhead and often times felt like it was in the way. I saw some developers get stuck because of the framework.
I did not start using any CF frameworks until I had build smaller apps without one.
If you like CodeIgniter better, for whatever your reasons, go with it.
CodeIgniter, because of the gentle learning curve and the great documentation. Give other frameworks a go if you ever feel you outgrow CI, which you may never do.
I started a small web project and used Drupal to build it. So far, so good: you can quickly set up a nice CMS oriented site, add social features via modules, and you have an extensive API to do the customizations in a nicely architected platform.
The problem comes now: the site is growing beyond what was originally planned for and I find myself in the situation of seriously starting write code for it. While I gained a new respect for PHP thanks to the Drupal project, I want to do it in Ruby. I'll feel more confortable, it'll be easier to maintain later and I can reuse it in other Ruby/Rails apps. Over time I suppose I'll rewrite the existing parts in Drupal in Ruby.
Based on this, the question is: has anyone integrated both (both a success or failure story)? It's quite a big decision, and I just can't find info about anyone who has done it on Google.
Sorry to be negative. This doesn't sound like a good idea to me.
I'll feel more confortable, it'll be easier to maintain later for me and I can reuse it in other Ruby/Rails apps.
I seriously doubt that. It will probably be more difficult to maintain/reuse in the future because of the extra code you will need to write to "integrate" Drupal and Ruby. The more the code, the more the likelihood of bugs. I'm assuming you're going to link the two together using REST/webservices/similar technology -- if that is the case you are writing so much extra code! Gluing the front end elements (which have to be in Drupal) with the functional elements (probably in Ruby) justs sounds so complicated to me.
I'm guessing its only you who is going to be maintaining the code. What if its someone else? Will you easily be able to find someone who has two skill sets (Ruby + Drupal) in your area/budget?
What about giving back to the Drupal community? If your code becomes something useful and its this big mess of Drupal + Ruby you really can't put it up on Drupal.org for others to build, improve and test.
I suggest two options
Use Drupal only.
Sounds like you're in love with Ruby or at any rate just too used to it. In that case: Find a Ruby based CMS! (Sorry I don't know any!)
To me its a classic dilemma: Should you do Drupal Custom Module development which will mean more short term pain cause you'll be out of your comfort zone.... or should you integrate Ruby + Drupal which will be easier in the short run but very painful in the long.
I would choose short term pain :-)
I think the term used to describe your idea is Polyglot Programming: http://memeagora.blogspot.com/2006/12/polyglot-programming.html
One of my criticisms of Drupal is that everything is in Drupal or PHP. Drush is an exception of course but it would be nice to see some development tools that don't use the Drupal stack exclusively. I have used Apache Ant on Drupal with some success (before the days of Drush).
I've also worked on a Drupal project that provided Software as a Service to a Java front end. That didn't work too well but the Drupal Services project has enjoyed some renewed development since then. I've also worked on several Drupal projects that interface with flash front ends (ugg!), google maps and mobile phone gadgets.
Are you thinking of a Service Orientated Architecture? If you're comfortable with that then you could be on the write track to writing truly agile software. I'd like to hear how you go!
However, if your only justification is that your feel more comfortable in Ruby (and I can see why) then, you should probably get yourself out of your comfort zone.
Right now I'm not sure...
I'd say yes. I'm using it. I know for a fact that Universal are using it on some of their (thousands of) sites. I will add some caveats, however:
There are serious problems with setting it up, especially if you want to debug into the libraries.
The helper functions favour prototype, as opposed to the more modern jQuery. This is changing rapidly, however.
The documentation is a bit chaotic, again the Castle Team are working on that.
I'm not guaranteeing every last "out-there" feature works, but the point of the system is actually to keep it simple.
Compared to vanilla ASP.NET, it's an absolute joy. I assure you that you won't miss viewstate.
We have been building a fairly large application with it for the past year and a half. Its been nice not to have to deal with the old ASP/Page based model and use the better Model/View/Controller design pattern.
To get the new stuff you really need to work off the trunk of development because they don't do releases very often. We have a lot of tests that get the framework involved so when an update in the framework breaks something we depend on we know about it immediately.
If you have to work in .NET this beats the heck out of the alternatives.
There is an overview on the monorail forum: http://forum.castleproject.org/viewforum.php?f=6
I'm using it for an application and haven't had any big issues with it.
The biggest problem is indeed find good documentation and examples.
I've had no problems setting it up. Julian, I don't think it is constructive to say things like "serious problems" without any further clarification or example.
Debugging into the libraries is trivial. Because it's open source, you can debug into the whole thing.
I've been using MonoRail for production for ages on many projects, as an employee, as an indie contractor, and for non-work related sites.
I know I'm biased on that, however I can whole heartedly promise that my positive usage experience is what lured me into contributing to the project, not the other way around.