Related
I am creating the cms for a relatively simple site - portfolio, some general content pages, custom blog etc.
What are some of the best patterns to consider before diving into the design.
I want the system to be as flexible as possible without being too complex.
I have looked for some good resources that discus cms and blog design but can't find anything too good.
My language is php but I suppose I am looking for more language independent advice.
Flexibility without complexity... nice program.
Maybe you're a genius and you will make something that feet your needs. But I think the biggest problem you will face is security and robustness. So really, take other advices on this page and have a look at wordpress, drupal, joomla and ezpublish. A lot of security stuff is already done. And not only security...
So, study some of these tools, track their flaws, check their security policy. Study how they handle caching, sessions, bootstrap, absolute & relative url managment, documents (images, videos, etc), ajax, authentification, identification, acl, user interfaces, rich-text editing, migrations, templating, page composition, content filtering (I try to remove the things you won't need, plugins, database abstraction, fine caching, css and js minification, all the extra-complex stuff not needed for a single instance simple CMS). Soon you'll have a 'picture' of the stuff they've done.
By doing this work, you'll certainly notice some big differences, and mistakes. You'll start going on irc and flaming developpers, telling them that others have done better choices. You'll start forgetting to shave. You'll maybe do some contributions. Some will be accepted, others won't. Old core devs doesn't like when someone explain why they made mistakes (and they make mistakes).
Now, comes the day you have a beard. Some of your contributions will start looking like forks. You will have ennemies, and friends, or followers. And you will start feeling the force.
And you will go on irc and tell god that the world is ugly and that you'll make the first CMS which will be flexible without being complex. And people will cry. And birds will run in circles. And you will be able to explain what are the design pattern of a CMS.
I am a user. I know what I want. Doing what I want will make user happy. I'm happy.
You shall not trust code from people with glasses
"MVC MVC MVC" : and the people responds 'that shall be done'
Seriously, There's still a place for a good CMS with disruptive innovation, the fork history has started long time ago with phpNuke (as far as I can remember). But some of the actual products are really fine for most tasks.
I'm probably risking the reputation here, but my experience shows that building your own CMS can be a very justified decision, especially when you get familiar with current opensource systems and understand what exactly they lack in terms of features, security or what not. Open-source often means a lot of backward-compatibility concerns and bad architecture decisions that cannot be easily changed.
I strongly suggest that instead of just taking on MVC you take a look at ideas that make it attractive.
One main problem with CMSes is the range of technologies involved in driving dynamic web-sites: imperative php for logic, declarative SQL for data queries, markup HTML for interface, imperative/functional javascript for dynamic interface, JSON for ajax calls etc. To keep the system manageable you have to keep these technologies in a controlled and understandable environment, but yet allow for smooth integration. Knowledge and best practices are out there. MVC is but one approach to manage this problem.
My choice at the time was to use the following principles:
Object-oriented code with static calling (php is a one-run thing, many instances of code objects are rarely justified), nothing except for one line of init code in global context
100% code-design separation with the use of XSLT and custom content processor
Custom router that can take any http request and reroute it to registered methods
Custom content processor that can take arbitrary method output and convert it into any usable format such as xhtml, xml, json etc. based on the request parameters (i.e. http://local/class/method.xhtml, http://local/class/method.json)
One copy of code for as many virtual web servers as necessary
SQL query builder (chosen for flexibility over ORM) for all database queries
Mandatory filtering of method input with filter_* functions
I believe you can choose a few that you like :) And good luck!
A good pattern to start with is the Model View Controller pattern, or MVC.
This pattern suggests to seperate your application's logic in the following layers: data logic(model), manipulation or business logic (controller) and display logic (view).
This is a good pattern to start with as you'll run into other problems (and thus patterns) along the way.
The following website explains the MVC concept quite well: MVC Principles
There is no point reinventing the wheel unless you are trying to better it in anyway.
THere are a lot of CMS available already. I personally have worked with ezpublish. There are other options such as drupal etc. This is the list of all open source cms avaliable - Click here
If you are just trying to learn then you can perhaps pick any one of the popular opensource and work on them to find its architecture and design.
Besides, I dont think anyone can give you a list of design patterns that would be best for a CMS tool. Because each design pattern solves some particular problem. And, you just have to choose a design pattern depending on a specific problem you want to solve in your project.
These days, writing your own CMS is a horrible waste of time. The usual open source solutions -- these days Joomla, WordPress and Drupal are popular -- are written by thousands of people and while you might loose a little flexibility by using on that's ready made this is by far offset by not needing to redo everything from scratch. If you go with Drupal, you can also enjoy high quality, massively scalable etc code :)
If Your rquiremnt is portfolio, some general content pages, custom blog only, Wordpress will be simple and Better.
In PHP so many CMS available , most popular one is Joomla.
Not as whimsical a question as you might expect - If you have an average web developer (we'll say his name is "Bob") with a fair amount of php/mysql/jquery/ajax/etc knowledge under his belt, and you wanted to recreate a site like as dynamic and as complex as SO from scratch, what are some best practices, and how long (hours or days) would you expect it to take to get it to a fairly stable beta?
I ask because I'm working on building a site (admittedly completely different, but the workload I imagine will end up being comparable), and it just seems like it's taking forever. It's been about a month working it no less than a few hours a night and it's coming along, but development just seems to escalate exponentially. Every new idea or button spawns a whole range of other work projects.
I try to use pre-made libraries and open source projects when I can, and I've looked into using CMS's like Drupal/Joomla, but honestly so much of custom sites are, well custom, that using a visual CMS just seemed to hold me back.
Being a paycheck to paycheck kind of person, I couldn't afford to pay someone else to help, so beyond volunteer work I'm more less on my own here to make the site. (We do have a microscopic community of willing testers)
Because I know it, because we aren't planning to charge any fees I've been building the site on top of PHPBB3. (provides the user registration/authentication, a database API plus functions for security and a full featured templating system and a plethora of other features.. Oh, and a FORUM, heh.)
I use libraries like jQuery+UI for the client side interactions.
I try to make things as modular as possible, so if I need to rewire the whole thing it wont be a terrible chore, but I worry that my lack of experience in major projects like this is going to be fatal to the site's success.
What lessons can folks who have been here offer, and what kind of timeline should I realistically expect to be looking at here?
but development just seems to escalate exponentially. Every new idea or button spawns a whole range of other work projects
This is what's causing it to take forever. You need to one or two things, preferably both.
Figure out your desired feature set, and stop there. Resist the urge to expand your workload with every new idea. It's hard, I know.
If you can't manage #1, then you need this even more. Release quickly and iterate. It's better to get something working done, and then consider the rest of it as improvements rather than original features. Even if the workload doesn't change, your mindset will, and you'll feel a lot better about it and more motivated. As an added plus, if you have users, they'll help you figure out which new features are actually worthwhile.
I wouldn't recommend a CMS. I'd recommend going with a framework instead, perhaps something like CakePHP or Codeigniter. They already include a ton of libraries built in and ready to be used. Makes things go way faster once you get the hang of it. You may still need a JS library or two, but as long as you use the framework as much as possible, you shouldn't have any trouble if proper practices are followed.
My advice: instead of building a new site from scratch, propose a new site within the Stack Exchange network, at http://area51.stackexchange.com.
There are a ton of PHP frameworks out there (i.e. Zend, Seagull, Symfony, CodeIgniter, CakePHP, Yii, Prado) that do a great job of implementing important pieces of a scalable/maintainable website, and I almost always pick one to start building client websites.
As of recently, I've started getting tired of providing constant development services to clients, and I'm looking at the possibility of writing more full-featured commercial scripts that can be resold over and over again in the hopes of finding that magical "recurring revenue stream" that you always hear about in fairy tales. Please note that I'm not talking about building extensions/plugins to CMS systems like Drupal or Joomla, but full blown website scripts.
So here's my multi-part question:
Is there any reason why I couldn't resell a script built on one of these frameworks as a full-blown turn-key solution (especially if the framework's licensing is something very flexible, like the BSD license)?
If not, why aren't others doing the same thing?
Have you ever seen a commercial PHP script that is based on a well-known open source framework?
I've wondered this for years, and no one I ask has ever really come up with a good explanation. It just seems like it is taboo to do so, and no one really knows why? I've seen commercial scripts that use third party libraries (i.e. jQuery, PHPmailer, etc), but never have I seen one built entirely on an application framework.
It really seems that a lot of people have missed the true nature of the question and even taken it as far as language debates (those never end well).
Is there any reason why I couldn't resell a script built on one of these frameworks as a full-blown turn-key solution (especially if the framework's licensing is something very flexible, like the BSD license)?
Assuming the framework license permits it then there's no reason you couldn't do this. You had mentioned Zend Framework so you may be interested in looking at Magento. While they offer a free community edition they also have a paid edition that works with the Zend Framework as well.
I recently worked with a file upload script that was offered commercially and it happened to be built on codeigniter (name escapes me at the moment).
If not, why aren't others doing the same thing?
My personal opinion is that it's a mix of quite a few factors really. The web based market for on premise applications (as apposed to SaaS) is already flooded with options and is starting to shrink in size. This makes less demand for an application that you would actually see the framework behind (with SaaS you most likely will never know what framework if any is being used).
A lot of the existing large players in the PHP market have been around for a while and already have their own code base that they have created and are familiar with. When you've spent years building your own libraries it's hard to justify moving to another framework.
A lot of the smaller players rarely educate themselves in proper application design and usually stick to procedural code. The big OOP features that exist in PHP today didn't come along until the 5.0 release. Mind you that was around 5 years ago but a lot of your programmers had started on their PHP tutorials and learning adventures before PHP5 was widely available and accepted on standard hosting accounts. As such most of our modern frameworks were not available CakePHP as an example didn't start until 2005. Zend framework wasn't around until 2007. These are all relatively new dates and I wouldn't expect to see a lot of commercial applications moving to them until the current generation of programmers that can write quality commercial applications age a bit (again just my opinion).
I have to heartily disagree with back2dos..
PHP's a solid, incredibly well used programming language for developing web apps. It can, of course, be used for commercial development and millions of people (me included) do just that. I'm not sure PHP bashing is really relevant here.
True, PHP is not compiled but if you really care about this you can use Zend Guard which can encrypt code. Personally I've always found open source code a plus point. Clients like to know they can get at the code if they really need to, it offers some reassurance.
There are lots of OS PHP apps, some great, some awful. Find a niche (like any business), something that has real demand, and develop for that.
So I think you're fine to develop commercial apps/scripts. Just make sure you give them decent support and documentation. You'll find people appreciate that and are willing to pay for it.
Finally on the point of your question, I agree they stand a much better chance of being used if they are based on an open source framework since you'll be opening yourself up to wider market. Zend Framework, as you may know, has a pretty open license which says you can sell anything you develop with it.
I think your most important question is point 2, why aren't others doing the same thing?
Well some people are. Vbulletin have been quite successful selling forum software, even though there's no end of free forum software available. I think their success can be attributed to a paid product, in part. As they're earning money, it's easy to fund further development. Open source, free projects usually require a dedicated team to keep development moving, as there's no money for motivation.
There's no shortage of turnkey solutions available on the web. eBay will have no end of $5 scripts available - they're usually rubbish and unsupported.
Where I work, we develop bespoke 'one-off' applications for our clients, but we're looking at selling the same applications to other clients as an opportunity to scale our business. In this case we're talking about large projects worth tens of thousands, but they're only sold to a handful of customers.
There's no reason why you can't sell a product for 50 or 100 dollars and make money - you'd just need to sell to 10, 100 or 1000 customers to start making a living from it.
And to succeed over the free open software? Produce something that isn't already available, or do something much better than what's available for free.
Finally, another model you may want to consider is software as a service. Take a look at Basecamp (37 signals) for example. Their product is not open source, you can't download it, but you register online and pay something like $10 for their lowest end offering per month.
They don't have to give out source code, and they have a solid recurring revenue stream. They have tens of thousands of accounts.
Yes of course you can sell it.
Most people don't just sell the scripts as normal people and businesses don't know what to do with them and so require a developer to install and configure the script. Developers won't then buy the script if there is an open source/free alternative. If the script performs a valuable task that is often done, then somebody is likely to copy it and create an open source version.
Your key to selling PHP code is to sell it as a service. This could either be the installation and configuration of it (like most web design/development agencies) or an on-demand version of it (think of any online business app).
My company writes and builds a lot of PHP software for businesses and as we get new clients and solve new problems we write our code in re-usable classes which we can then package up and sell to other clients without any further coding - which I assume is what you are trying to do. It's all possible, it just takes time and planning to write the software to make it re-usable for other projects.
Well in this case I think that codeigniter will be the best option because:
Don't need console access to configure
You just have to configure Database Connections
Fast, MVC, Cache, Logs, Good Documentation
Runs in PHP4, must of the people that buy this scripts have server restrictions to Upgrade PHP
Best Regards,
Pedro
As a PHP developer for over 5 years and selling scripts I never tried to developed a commercial script with a framework.It is just because Im not a good fan of any PHP framework.
Someone can say if you don't use framework you are a amateur as a developer.But I think its the a way any developer has rights to choose.
I think some companies don't use frameworks just because they just dont like to say this script based on 'ABC' to the customers.They want to boast about their scripts and only they can developed something like that.
I event seen any commercial web script that used any frameworks so far.
I can think of one reason against it: piracy. If your script is something a bunch of framework guys want, it will be pirated. If it is only for a rich niche, you can avoid this, but then you aint going to get any fairy-tale income.
It's not in the open source spirit of PHP. The trend is to give it away and then bill for the service. You might be better at marketing your script as such, and just charge people after they consult you and you hand them a script download and a manual.
i think, these are the key reasons, why it is not done:
the point of PHP was never building commercial applications (the original acronym means "Personal HomePage") ... it is an insecure, inconsistent language ... there are quite some good PHP frameworks ... nevertheless, the language is ... poor ... other server languages are cleaner, stricter, more secure, more powerfull, give access to a larger codebase and to better developement tools (notably java and the whole .NET stuff) ... i'd never use PHP if i had to built something really reliable ... (my favourite is this "overflow vulnerability fix" of chunk_split (line 1966)) ...
PHP is always open source ... ok, there are obfuscators, or even ways to distribute PHP in a binary form ... but the first is likely to break the code, if you do a lot of reflection/introspection, and the second usually requires some PHP extensions to be run, which is not really sexy ...
there are too many open source PHP projects around for any commercial software to succeed ... this was different before, but nowadays, you can simply get ANYTHING in PHP ... Typo3, Joomla, Mambo, osCommerce, PHPBB etc. ... frameworks as Flow3, symfony, CakePHP ... etc. ...
there are commercial sites running on PHP, but there is no good PHP software/framework i heard about, that i would pay for ... there's always a free alternative, and usually it is better ...
you will be having a hard time creating something, that is really worth buying ... and if you succeed, you will be having a huge community that will copy it, if it is worth buying ... either for personal commercial profit, or simply to provide a free solution ...
well, that's what i think ... :)
edit:
let me clarify my points
seems, i upset some PHP folks here ... that was not my intention (however i am quite disappointed, how biased you seem to be, given the fact that everyone contradicting me is a PHP developer and i seriously ask myself, what other languages you ever used) ... i myself started out with PHP on server side too and after moving through other languages, i came to see PHP in a different light ... explanation is provided ... whoever just does not want to read it, move on to point 2 ...i am not saying, PHP prohibits you from implementing a specific solution ... but it is being used to implement solutions it was never designed for ... it started out as >this< ... and it was constantly extended by many people, which produced:
an inconsistent API ... or does anyone else know a language, having a naming convention, where array_search, count and implode are all array routines? look at ruby, ecmascript or Haxe if you wanna see how beautiful core language APIs can be ... i'd say it's awfully designed ... but it's not designed at all ... it has simply been thrown together by numerous PHP contributors ... that's cool in the sense that you have a function for everything ... the point is, you probably won't find it ... ok, after a while, you will know it all ... probably ... but in other languages, for example, where arrays are objects, it does not take you long to know all core array routines ...
no real philosophy ... look at the languages mentioned above, look at Objective-C or functional languages, if you want, to see how consistent a languages semantics and philosophy can be, compared to PHP's "oh well, we'll just throw in another function, that'll solve the problem" ... also PHP arrays are the strangest data structure, i have ever seen ... something like a hyperpotent hash with internal order for keys and values ... and yet, it's not even an object ...
a lot of unsafe code (a lot of functions exposing overflow vulnerability or not being binary safe, or not escaping is documented, which could be used for XSS attacks) ... when i read an API reference, and it tells me what a function does, but the truth is, i have to take in account a lot of possibilities (long strings could crash my complete system or even inject ANY code, nullbytes could make escaping routines not work, but when printing out the string again, they disappear (this was a strip_tags vulnerability until not too long ago)), then that is what i call unreliable and dangerous ...
slow execution ... eaccelerator and similar extensions can reduce booting time signifficantly, but execution it self will still be slow ... the actual problem is, the language is far to permissive, which causes a lot of overhead ...
PHP was designed as a scripting language tying together a bunch of C functions ... it is often extended with further C functions, due to the fact that it is not the fastest language around ... this gives a nice speed up ... but how the hell do i know, whether a function is safe? who can tell me? i don't want to read through lines and lines of C to know ... so my two main points:
the API is a mess
what is behind that API can be a serious vulnerability for your application!!
in consequence, PHP is hard to trust ... i mean, i personally dislike both Java and ASP.NET, but i have to admit, they are trusted plattforms and trusted for a reason ... now problems arousing from the messy API are being solved by some frameworks ... but if a language requires a framework to wrap the core API in order to have something usable, that is a base for good, maintainable code, then something is wrong ...
how exactly do i use zend guard or ioncube on an arbitrary shared webspace?
really, best thing you can do, is write commmercial plugins for widely spread PHP software, but it seems this is exactly the opposite of what Lusid wants to do ... but hoping to find a niche, that is big enough that you don't need signifficant marketing efforts to reach you customers, that is small enough that you don't get crushed by copycats, simple enough to build as a standalone app and fits a number of other criteria that are prequisites for a commercial success, seems a little naive to me ...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am wondering why this framework (QCodo) is almost forgotten and totally unpopular.
I've started using it a few years ago and it is the only thing that keeps me with PHP. Yeah ... its development is stuck (that's why there is now more active branch Qcubed) but it is still very good piece of software.
Its main advantages:
Event driven (something like asp.net) no spaghetti code
Powerful code generation
good ORM
follows DRY
very simple AJAX support
is fun to write
Since then I wanted to be trendy and checked Django but I cannot write normal request-based web application (it just doesn't feel right).
Don't believe? chess.com is written with it and surely there are plenty others.
My 2 questions are:
Have you heard of it (PHP people)?
If you are using it what is your opinion about it (show us examples of your work)
Thanks
I've used PHP a lot for many years and never heard of it.
The creator(s) of Qcodo never really promoted the framework, and thus, didn't generate a large following. I believe they created it mostly for their own use, but also offered it up to others. It is awesome if you are looking for a code-generating framework. It does have a learning curve. So to get the most use of it, it's best to spend time studying the examples.
Qcodo has really had no active development for well over a year and there doesn't appear to be much chance that development will continue on Qcodo anytime soon. Qcodo appears to be dying a slow death.
Qcubed, a branch of Qcodo, is under active development and has been since Nov 2008. It was created by users of Qcodo who got frustrated with the lack of Qcodo progress. If you are just getting started, start here and not with Qcodo. But use Qcodo forums to search for problems/questions you may have.
Qcodo and Qcubed are fantastic frameworks. Don't discount or underestimate them just because you've not heard of them.
Emulating ASP.NET or Wicket in PHP is not a good thing to do. Moreover, the code style does not look good to me.
$this->btnSavePage = new QButton($this);
$this->btnSavePage->Text = "Save";
$this->btnSavePage->Visible = false;
$this->btnCancelEdit = new QButton($this);
$this->btnCancelEdit->Text = "Cancel";
$this->btnCancelEdit->Visible = false;
Hungarian notation? OMG. I need to create a big object to create a button? Heavy weight to me.
Yes, we do use it at Chess.com and overall have been very happy with it. It can get problematic trying to figure out how/where to store all those QFormStates when you're getting well over a million pageviews a day. Every page view is its own QFormState! We solved this by putting all of them into memcache! It does have a bit of a learning curve, but once you know it, you never really need documentation any more. I actually have moved away from using QQ entirely, and use all custom sql in our ORM files. QQ is just not powerful enough to do heavily optimized queries and highly tuned queries is more important than database abstraction. After all, the site needs to function and be fast. Here is one example ORM static method in our User class to load a random user from the database (we used to use this to show a random "user spotlight" on our members page). Notice how it uses the slave database, not our master (custom built function). It also uses memcache so that the randomized user only changes every 10 minutes (600s).
public static function LoadRandom($blnAvatarRequired = true, $blnForce = false) {
$strCacheKey = MyMemcache::QueryToKey("User->LoadRandom()");
if($blnForce || false === ($objUser = MyMemcache::G()->GetQuery($strCacheKey))) {
$objDatabase = QApplication::GetSlaveDbConnection();
$DaysAgo = new QDateTime(QDateTime::Now);
$DaysAgo->AddDays(-10); //make sure this is an active member
// Setup the SQL Query
$strAvatarReq = $blnAvatarRequired ? ' and u.has_avatar':'';
$strQuery = "
select
u.*
from
user u
where
u.is_enabled=1 and
u.create_date > '$DaysAgo'
$strAvatarReq
order by
rand()
limit
1
";
// Perform the Query and Instantiate the Result
$objDbResult = $objDatabase->Query($strQuery);
$objUser = User::InstantiateDbRow($objDbResult->GetNextRow());
MyMemcache::G()->SetQuery($strCacheKey, $objUser, null, 600);
}
return $objUser;
}
Qcubed and Qcodo are used by us in 3 projects and these ones are the cleanest and easiest to maintain projects we ever had! This is great stuff and easy to understand.
Just go into the code you won't need much manuals.
Qcubed community is much stronger at the moment so you might want to check in Qcodo forum for your answers on basic problems, but post on the Qcubed forum.
We will continue to stay with this fantastic product and community!
Regards,
tronics
http://www.twitter.com/qcodo
No, I'd never heard of it.
The main ones I've heard of are Zend, CakePHP, Symfony, Code Igniter, and one or two other ones I can't recall the names of right off the bat.
I've been doing PHP work on and off for about 3 years and have never heard of it. Ask anyone to name a PHP frameworks and you're gonna get the usual suspects: Code Igniter, Cake, Zend, etc.
Guess QCodo devs need to work on their marketing a bit!
I've been using QCodo for 2 years and now I'm with QCubed.
This is the nice way to develop and maintain web applications, as well as, the easiest way to deploy code and test it. Remember that QCubed is now growing in acceptance and it's good for all QCodo's Community.
I think that frameworks can save a lot of development time but it many cases it's not recommended for all yours web developments.
I started to use it two years ago. The pro:
code generation from the database
ORM object oriented
simple use of ajax
Cons:
qcubed community is not so skilled to carry on a project with new good ideas
the new code is not at the level of Mike Ho.
bugs in the state of qforms, the forms of qcodo/qcubed.
is not popular.
they do not want to go ahead and use DDD and forward engineering.
the forms only works with js enabled.
is written in PHP.
new plugin system poorly designed.
At the moment, Grails seems to be the best framework, very DDD oriented, with the possibility to use any existing Java code, good template library, possibility to use different js frameworks, built on Hibernate and Spring. With Grails is possible to write simple web app or financial application.
I hope not to use PHP in the future, but since I know Qcubed/Qcodo I will use it if it will be necessary. For newbies, I reccomend Symfony, bigger community, mre plugins, feature rich, it has a more secure future.
Updates:
No database migrations, no way to track database schema changes
No schema reflecting which tables are generated
It is not designed to real TDD, it is not easy to test models, controllers and views. They just added a testing framework to an unfriendly testing web framework
QForms still bugged and can loose status when using several controls and trigger Ajax error and blocking the application.
The ORM is very boring to use in the long term (lots of chatty/redundant code) and cannot be tested with a tool like Rails console, in the end it takes less time to use pure SQL and test it with phpMyAdmin.
Bugs in the ORM too, sometimes I get a string when I declared the field as integer (code-generated queries).
There is not a front controller and a routing system and the framework is inside the public path! The plug-ins are installed in the public path too!
Strange directory structure not similar to other MVC frameworks and they thing that the M stands for ORM only instead of model.
not link_to tag like Rails or Symfony and many other tags.
Over complex metacontrols that are useful to waste time only.
Framework focused in scaffolding when in Rails it is not used a lot since most of the developers use a user centric design instead of data centric one.
The views are full of object->render and JS and custom controls are a pain to be customized, and instead of staying inside a template are inside a class with logic session .. everything.
It does not work with PHP 5.3 (not tested but should be resolved) and on Quercus.
Rails/Grails has ton of plugin doing everything.
I could continue but I think you get the idea. Just learn Rails or Grails for few months then let me know what you think.
I am moving my Qcodo project to Rails and I have a wonderful environment, nice community and most of the innovation in the web is around Ruby and Rails. Rails has been voted several times as best web development tool and is the only one that can substitute Java or .net
While I have heard of it (Qcodo... not this fork) I never looked into using it. There are tons of frameworks and only so much need. PR and mindshare are hugely important in such a situation and Qcodo never really had either. Now that I am settled on a handful I have no time, nor inclination, to start learning a new framework.
This Swim Log uses it mySwimLog
I've been using QCodo since beta 2, and am now a core contributer of QCubed, so yes, I've heard of it.
What initially drew me to the framework was the code generation. I came from asp.net, and codesmith, and was very pleased to find a framework that gave me both the event-driven approach of asp.net and the code generation of codesmith.
I also love that it's all pure OO PHP, which means I don't have to learn a new language to develop my PHP app, and customizing any aspect of the framework that doesn't behave like I want is simple.
All of this has resulted in us being able to produce an easy to maintain and robust Learning Management System that we have sold to and host for numerous Fortune 500 companies.
There are some downsides, such as the runtime overhead of an ORM approach, but the readability and clean layout of the code results in the ability to more easily streamline other aspects of the application, and significantly reduces both development time, and the number of bugs produced.
Since QCubed is a community driven project, anyone is able to submit tickets, suggest improvements or discuss changes, it's very clear where the project is going, and very open to constructive feedback.
In defense of some of the negative things said here, I will simply point out that tickets for most of the supposed "problems" simply have never been created. And I would encourage anyone that does encounter any of them to please create a ticket for us to look at at http://qcu.be.
OK, Here is something I want to tell about this Qcodo / Qcubed thing:
Its brilliant. I just have no words about how great it is. You say CodeIgniter? Symfony? I say Qcubed.
It was when I wanted to start off the project I am working on and I looked into all those and through a Wikipedia article, landed on Qcodo site, and then on Qcubed...and I was surprised.
The features I loved the most:
No SQL queries needed. Of course, it can be done but most things are taken care of!
Speration of Templates from the core functionality.
Creating custom controls is a piece of CAKE (and its not CAKEPHP).
Totally Even driven. Saving states is like..."where does that happen?"
NO LEARNING CURVE. Just look at Yii or Symfony exmaples and then go for Qcubed examples. Its much simpler compared to others.
Full AJAX support. I love this.
No JavaScripting. Ask it to do something as a 'javascript' action, it is done by javascript. Change one word to 'QAjaxAction' and it goes to ajax. Change again, page reloads. What more do you want?
Autocomplete, typecasting (both automated and manual control) and what not!
Inline editing of almost anything!
yeah, there are a few cherries on the ice cream when it comes to Yii. But I think Qcodo has more inside.
You say Authentication support? Well, I created one to integrate with Qcubed in 1 day. It saved a week of lerning headaches with other frameworks. Qcubed rocks.
yes, I hate its slow development. But I think its near to complete! (may be I know too few things but anything I am capable of imagining seems to get solved through Qcubed).
I wish it was more popular...I would have saved me a week of search before landing on their pages.
I have used QCodo/QCubed for 1.5 years now. Started with my own framework, which at some point seemed messy. That's when I started looking for a more mature framework. Luckily I found QCodo. Since then I have never even considered looking for something else. The framework is so flexible and powerful, that you can do everything you want with it.
I had almost no experience with event-driven architecture. So, the beginning was somewhat hard, cause there was few documentation available. But community itself is very active and you probably get answer to your newbie questions in 1-2 days (sometimes even in hours). But currently the documentation level is way better and community is even more active :)
Nothing I can complain about. And if I have some problems/suggestions, I will try to discuss those with core developers. Whining about stuff without constructive discussion is lame imho.
I have used QCodo/QCubed for 3-4 successful projects now. The more I use it, the more I like it :) And also, I'm trying to help developing even better framework whenever I have spare time. And I can say, that I have had more than 10 people, who I have convinced to start using QC now ;) And I hope there will be many more.
QCubed totally rocks!
Never heard of it.
Been doing PHP on and off 4+ years
http://www.piranhamethod.com/2009/04/09/qcodoqcubed/
I have heard of it and I love it.
I also came from a dotNet / Codesmith environment. When I picked up a project that wanted to translate a dotNet site to PHP I looked for a framework that could best emulate the way the original application's logic was set up. What I found was either bloated frameworks or frameworks that did not completely fulfill the projects requirements.
I accidentally found QCodo while researching using the MyGeneration tool for PHP code generation. I have not looked back since. The ease of use, ability to quickly build complex applications and the true OO approach QCodo now QCubed uses makes it the best framework for my purposes.
I've been using QCodo, ZCodo and now QCubed for quite a while now.
I actually picked it as a replacement for CakePHP, which at the time of my need, wasn't mature enough to do the things I wanted.
I'm super happy with it as a framework; it abstracts things just enough, but not too much that you lose sight of the programming.
I plan on using it for any development project I'm responsible for in the future, and I'm looking forward to QCubed being the best community maintained framework for PHP5 out there.
The quick reason is that popularity and success do not generally go with what's technically best. I'm sure any techie can come up with numerous examples. There are numerous things that can promote mediocre solutions, like marketing, first-mover advantage, being a touch better in some area that catches people's attention, being used in some high-profile application, or just plain luck.
The other reason is that what appears technically best to you may not appear so to somebody who's doing something different.
I think that QCubed is great and mainly because of the way you can use Ajax (you dont have to write Jscript and you dont have to use jQuery).
One very useful document: http://www.qcodo.com/demos/QcodoClassLibrary.pdf
I chose QCodo 4 years ago to develop our product. I've never regretted - now we're 3 developpers on the thing, and any non-OOP solution wouldn't work. We have installed almost 50 customers with it - on Apache, IIS, my SQL and SQLServer platforms, Linux or W2003.
F
The design is brilliant, code-generation is great, and it's really easy to develop, extend, and maintain. I can't read any other code now...
Yes, marketing is quite poor, and the project used to depend just on the creator (Mike Ho). All of it moved to Git recently, and marketing should be better soon. And, now Mike Ho is back !!!
I have used it in few projects involving Flash remoting but I only use the ORM in the framework as I don't really like EDP stuffs like .NET. The flow doesn't seems right at all for stateless web. It's great if the ORM can be released as a separate component.
I never heard about it.
I didn't used it.
qcubed community is not so skilled to carry on a project with new good ideas
Nonsense
the new code is not at the level of Mike Ho.
Nonsense
bugs in the state of qforms, the forms of qcodo/qcubed.
??
is not popular.
So what
they do not want to go ahead and use DSL and forward engineering.
Your point? Every framework that doesn't want to go your route is wrong? I for one would not want the suggestions you have made
the forms only works with js enabled.
You have to be kidding right? If users don't have JS enabled, then they're in the stone age...
is written in PHP.
No comment
new plugin system poorly designed.
Based on what do you say that? I would say nonsense to this as well
Clearly there is some hidden agenda with this poster...I've also had a close look at Symphony - and I would go with QCubed over Symphony every single time. For big apps or small
I've been a PHP developer for many years now, with many tools under my belt; tools that I've either developed myself, or free-to-use solutions that I have learned to trust.
I looked into CodeIgniter recently, and discovered that they have many classes and helper routines to aid with development, yet saw nothing in the examples that I couldn't do just as easily with my own tools. Simple things like DB abstractions, Email helpers, etc. There was some interesting code relating to routes - mapping urls to the right controllers; but even that's not particularly difficult to code yourself if you've ever written an MVC style web app with pretty urls.
Even after looking through some of the other popular frameworks, I still see nothing that would be that much of a time-saver. Even looking at the forums, I see people struggling to get the tools to work for them. I do understand how they would be more useful for junior developers, since full system design skills take a while to understand and appreciate fully.
Yet, I'm often told that I should use an off-the-shelf framework to produce my solutions, but I still remain unconvinced. What's the real benefit to someone like myself? Am I just being elitist, or is this a common opinion?
Edit: Looking at some of the answers here, should I perhaps consider packaging up my toolset as its very own framework, writing some documentation and posting tutorials? If I'm hesitant to take on other's frameworks, would opening it up and getting more eyes on it help to improve my own skills/tools?
Frameworks have several advantages:
You don't have to write everything. In your case, this is less of a help because you have your own framework which you have accumulated over the years.
Frameworks provide standardized and tested ways of doing things. The more users there are of a given framework, the more edge cases that have been encountered and coded for. Your own code may, or may not, be battle hardened in the same way.
Others can be recruited onto a project with a standard framework and have access to the documentation, examples and experience with that framework. Your own snippets may or may not be fully documented or have examples of use... but isn't much chance that others are comfortable with them initially.
EDIT:
With regards to your idea of packaging up your own framework, the benefit of cleaning it up for public consumption can be larger than the benefit of getting others to use it.
The reason is simple: you will have to re-evaluate your assumptions about each component, how they fit together and how clear each piece is to understand. Once you publish your framework, your success will be strongly dependent on how easy it is to get up and running with.
Big wins with little effort are essential for adoption (those wins will encourage people to delve further into the framework). Ruby on Rails in an example of a framework that gives such big wins with little effort, and then has hidden layers of features that would have overwhelmed someone just getting started. (The question of the quality of RoR apps is not the point, the point is about adoption speed).
After people adopt a framework, it is about the ease of continued use. Little details like consistent parameter use patterns make all the difference here. If one class has many parameters on every method, while another has setters that are expected to be called before invoking methods, you will lose users because they can't get a "feel" for what is expected in a given case without resorting to the documents.
If both ease-of-adoption and ease-of-living-with issues are addressed properly, you only have to get lucky for people to adopt your framework. If those issues are not addressed properly, even an initial interest in the framework will wane quickly. The reason is that there are many frameworks: you will need to stand out to gain the advantages of having others using your kit (as they rightfully are as wary of your framework as you are of others).
Here's another reason not to create your own framework. Linus' Law - "Given enough eyeballs, all bugs are shallow". In other words, the more people who use a given framework, the more solid and bug-free it is likely to be.
Have you seen how many web frameworks there are for Java? Back in the day, it was fashionable for any half-decent developer/architect to write their own custom web framework. And at the end of the day, 95% of them looked like a custom implementation of Struts (the most popular Java web framework at the time). So they basically created a Struts clone that was: 1) proprietary; and 2) not as well documented and tested.
Let's face it - writing our own customer framework is fun, but what happens next? It becomes a maintenance burden to keep up with the framework yourself (or the poor soul who replaces you). And maintaining software is much, much more costly, especially when it comes to custom frameworks. Is the company in business to solve domain problems or in the business of maintaining frameworks?
I forget who said it, but I once heard a great quote - "The first rule to creating your own framework is: don't". Somebody else has probably gone through the effort of doing so and probably done the same work you would have done. Save yourself the time, effort, and testing.
There's many comments here as to the advantages of using a framework, and certainly I think in a good many cases they are perfectly correct.
HOWEVER
All frameworks come with the downside that they have a domain of problems that can be fitted into them. If your problem is well inside the scope of the domain then using a framework isn't an issue, and most of the time it's readily apparent if your problem is well outside the domain so you don't give it a thought. Issues arise when you try to force a problem into a framework that it just doesn't quite fit into or has some unusual non-standard feature - in which case you complete 90% of the code really fast then spend all the time you've saved figuring out how to bend or extend the framework so it can accomplish some obscure requirement. Because in these case your solution/extension has to plug into the framework it can often be more difficult to code than if you'd come to it independently.
In the wrong circumstances this can actually be disastrous. For example if a client asks for a project that you believe will fit into a framework solution and you quote accordingly, then after completing 90% you find the gotcha then you can be really up the creek, especially if it's some feature that the client is insistent upon (and it always is). These issues tend to arise because it is not always apparent from the word go where the gotchas might lie, particularly if you're using a framework you are less familiar with (and you have to from time to time).
This is really the same problem as arises with deploying any third party software in a project. Myself from experience I have no qualms about using frameworks or similar, but given the choice I will always go for the lightest, thinnest, wrapper I can find that will do what I need. That way I gain the advantages, whilst knowing that if issues do arise (and they are generally less likely to with a thinner wrapper) then figuring out how to work around them is likely to be simpler than learning an extensive code-base to the point where I can safely modify it.
The framework code is likely to be well-tested and relatively free of bugs. By using it you save yourself time testing/maintaining your own code to do the same thing.
And any time saved is good. Laziness pays off in programming.
One thing that you will be missing out on is all of the Validation that goes into a popular framework.
Your routines simply don't have the same exposure that the popular libraries have.
You may have a point.... however I wouldn't underestimate the power of many, as an example phpBB is as far as i'm concerned the bb solution to use. Why? Because there are many, many thousands of posts on their support boards and many people using it who are knowledgeable and can help people solve problems.
Therefore the only reason in your case to use a popular framework is the many others that use it, report bugs against it, fix it and support it. It'll be tricky to get the same coverage on your own libraries.
I would go against the grain here, and say, you should use your own custom framework, If the software you are building is the core of your business. As Joel would say, "Find the dependencies - and eliminate them". If you are just putting up a little website for your company, and you business isn't maintaining websites, then go ahead and use a framework. But when that website is your business, then you shouldn't depend on a framework from somebody else to let you get the job done.
I think the main reason is that when you use a common framework, there are a lot of people who are instantly familiar with your product.
Apart from that I think it's most important that whatever tools you use actually get the job done. If it happens to be familiar to other people, then that's a bonus.
I agree you should use your own custom framework. Not only is it easier for you to understand, but it provides the ultimate in job security!
Three reasons I can think of immediately:
A well-known framework will be familiar to other developers who may have to work on your project
A well-known framework will have resources like books, discussion boards, and other experts that can be used for finding out more information
Managers will often have a "don't reinvent the wheel" philosophy. In fact, existing solutions have probably solved the same problems that you'd discover if you create your own solution.
All of that said, there may still be a place for your own solutions. We wouldn't have so many frameworks (or scripting languages) to choose from if no one started something new.
Any experienced developer can build a framework -- the challenging part is convincing others that it's worth using. You'll need to create documentation and tutorials for it for those who plan to use or maintain it. You'll probably need to create a demo site to prove that its useful and actually works like it's supposed to.
That alone can be a considerable investment, not including bugs that could pop up in between. When its all said it done, it could be worth spending time learning another framework instead of making your own.
You mentioned CodeIgniter -- I personally feel like that's a pretty framework -- it doesn't get much more barebones than that.
What you essentially have is your own framework. So, it isn't a time-saver FOR YOU, because you have already spent the time to develop the framework. If you didn't have that to build from, it would certainly be easier and faster to use an existing framework than to roll your own.
What you need to look at is whether or not your framework is better than other options out there, and whether your familiarity with your own code outweighs having other eyes looking at it, and other people using it in enough different ways that the likelihood of any problems being found and corrected is much higher.
Also, if your framework is so much better than everyone elses', you might consider opening yours up to the community ;)
As you probably know: "time is money". So by using a popular framework with a lot of helpers, a lot of code examples on web and a big community you do more in less time.
Sometimes it if ok to use frameworks because you become more productive, but in some advanced and difficult projects it may happen so that the framework stays in your way and you have to find workarounds.
I think there is no definitive answer. You should put in balance the pros and cons and take the right decision for your project.
Usually I adopt popular frameworks very fast but not in critical parts of the projects and in time I extend their usage.
I think that if you don't see a need to use a framework then don't.
The reason I use a framework for example Django for python or Rails for Ruby or Webforms and MVC for ASP.net is because they make it easier and faster to write applications for them. In the case of Ruby and Python not using a framework for me would make me go crazy.
If you have something that works and don't see a need to use a framework I would say stick with what you feel is best. But, I would still keep up to date with frameworks.
I think they are more useful if you are starting from scratch and don't have the time to write your own. If you already have a codebase you developed over the years, they may be much less useful, but it may still be useful to take a look and see what they did.
For example, I am sure major game development shops are not using third-party tools, engines and frameworks, not because they are not sufficient, but they already have built their own since the 80's or whatever.
Plus, if you are using an off-the-shelf component, there is no way to exceed it in its particular area. If you need to be a market leader in a particular dimension, you should be building your own solution in that dimension, so you can lead. If you don't need this capability, using a third-party component that is just as good as yours may be a good solution as long as it is an easy transition. Time to train in the new tool and living with its idiosyncrasies may or may not be worth it though.
The other thing to consider is that if you can build something, you truly understand it. Otherwise, you don't. Now, you don't need to fully understand stuff to use them, so long as they "just work", but we all know how that goes... :)
Can you solve the problems you are given have with your code faster and more reliably than public frameworks?
If yes, then keep using your own.
If no, then find the framework that does a better job and run with it for that project.
It all comes down to which codebase gets the job done better(for the value of better given by the client. ;) )
Disadvantages.
Most frame works are not object orientated. (code igniter does show some promiss)
Most of the code is done via includes. trying to track down the problem is like pulling on a thread on a sweater, and having to unravel the entire garment to fully understand the creation.
Most frame works have poorly written documentation.
Most frame works try to do many many many things.
I find from my experience developing with frame works that it takes a good 3-6 months to get on top of the code base. And its only after that period of time that you will find out weather you are trying to fit a square peg into a round hole. Given that most php projects want to be finished before that period has elapsed, it will cost employers more to get any project using a big "frame work" to fruition.
Many of the php Frame works were written for php 4, and were written in a different enviroment. They have been extended greatly, but are showing their origins. The use of global constraints is particularly prevalent. I am hoping that php 6 puts most of them to death. Code igniter escapes most of this, but it is new, and has object orientated parts.
Some frame works have written code that is not needed, and causes problems.. eg: CAKE has a most excellent model view controller, but its session handling is a disaster. Unfortunately frame works are not written in a modular way. Often its an all or nothing option.
MOst programers "hack" the frame work to get it to do what they want. This leaves future programers sractching their heads. It also makes "upgrading" the frame work a impossibility.
I have yet to see a frame work that implements unit testing. (how do you know that you have not broken it).
give me a well written object any time. At least them you know the scope right off the bat.
Advantages are that it's already written and tested by multiple people therefore less likely to be bug prone.
Disadvantages are that it's not built specifically for your application and therefore will most likely perform worse.
All in all, I can't really see much reason to use one considering you already have your own...although it may be worth releasing that open source so others are able to bug check and recommend improvements.