views:

495

answers:

5

The debate is that I need a PHP Framework/Drupal with the flexibility to add custom features to a potentially large application (web and with an api).

However, with a framework, like Kohana, I see myself tackling and re-inventing the wheel with the simple stuff like account management and cms stuff. Account management and quick data collection, like fast form creation, are tedious in Kohana but appear incredible simple in Drupal. On the other hand, based on my limited Drupal experience, I doubt building rapid custom "features" and allowing users to create "groups" and to manage their own roles within those groups is something Drupal can easily accomplish.

To simplify, is Drupal capable of true Web Applications; where the application is a service and provides custom results to each user? Can it provide a dashboard-like interface for users to change their settings or preferences? Can it aggregate data from particular users to provide better results/info to others?

If so, please point me to some knowledge :-)

A: 

There is no impossible thing to accomplish. The question is do you want to work with someone else code and try to figure out how to dig inside and extend so it can fit your needs or you want to go with a light framework like Kohana or maybe CodeIgniter(my personal favorite) and drive your own car, although you might need to "invent" some of the wheels.

Go ahead and research what plugins are there to your framework of choice as there are a lot of frameworks providing very good solutions which can provide you with these wheels.

In my personal opinion the time you will spend studying Drupal will be equivalent to the time needed for you to create your basic CMS functionality, but the nerves you will use dealing with stuff out of your control like the core Drupal code will shift the scales in favor of Framework.

Ivo Sabev
But then once you've learned how to write/modify modules and work with core Drupal you'll be able to do similar things much more quickly in the future. IMHO for someone who's planning to be doing this sort of thing as more than a one-off, Drupal wins.
intuited
@intuited I disagree, since once you learn how to do stuff in a Framework and have your base classes you have a foundation to go and go whatever you want. If someone needs flexibility he should have as much own code as possible in his app, otherwise it is kind of nightmare.
Ivo Sabev
@Ivo Sabev: It depends on what you will be doing.. if it's in Drupal's ballpark (and a lot of stuff is), it will end up being faster to do it in Drupal, especially once you get over the initial learning curve of how to extend Drupal beyond its basic capabilities. Drupal basically *is* a framework, but higher-level and more specific than most.
intuited
@intuited my experience with systems like Drupal and Joomla is that they try to accomplish 1000 things in the most generalized way which needs significant amount of unspecialized code which makes them very bloated in my opinion. I will every time go with a framework like CodeIgniter and build my own stuff. It is like buying a suit, you can ordere it at a taylor shop or buy it from a store, guess which one will fit you best.
Ivo Sabev
+1  A: 

The fun stuff about Drupal is what the community calls jokingly rule #35: there is a module for it. Unless you want to do something really tricky, you will often find that the functionality has already been implemented and you just need to configure it.

chx
There is even a drupal module that adds to each node a picture of someone installing that module in their underwear.
intuited
A: 

As a newbie web developer, I can tell you that you need to analyze the use cases for your web application very strictly. If you are able to cover at least 75% of the use cases you foresee, that's a good start.

With that done, you need to figure if Drupal/Joomla/CMS(x) will give you all of that and with another potential unknown 5-10% feature creep. If so, you maybe better off getting in with Drupal etc.

Else, I think CodeIgniter or Symfony are great PHP frameworks to jump in with. Both offer solid tutorials, video and otherwise, and a helpful community. Kohana, which I am working on, I think you should get into if you really understand PHP and its flaws and realize that speed will be a critical factor. Those are the two big strengths that KO3 brings to the table and you should really need them to use it.

Hope this helps.

Abhic
+2  A: 

I'll admit right away I'm a big fan of Drupal and I have never used Kohana, so this post will be one-sided.

In the company I work for they use Drupal or Zend Framework for pretty much all projects (Drupal being in the majority). Many ZF-oriented people dislike Drupal as it's structure is so far from the object oriented ZF-stuff, and Drupal is "just an CMS". As I see it Drupal is more of a Framework than "just" a CMS, and the best part being that it is incredibly flexible: everything is possible.

And yes there is indeed a module for everything. To be more specific:

On the other hand, based on my limited Drupal experience, I doubt building rapid custom >"features" and allowing users to create "groups" and to manage their own roles within >those groups is something Drupal can easily accomplish.

I can only guess what you mean with rapid custom features, but imo it's easy to expand Drupal with your own modules. Most features are available as (free, community contributed) modules, and many advanced looking features can be easily created for example with the "views" and "cck"-modules. http://drupal.org/project/cck http://drupal.org/project/views

Creating groups: "organic_groups" ( http://drupal.org/project/og)
"og_user_roles" ( http://drupal.org/project/og_user_roles )

These modules together are what you need to create groups that have group spefic roles (and roles having specific rights). There are probably other ways than using "og_user_roles", but I'm advertising it because I've made a few patches for it a few years ago. The problem is usually a bit too many options.

If you want to extend group specific options you could code your own module, but most likely you don't need to because there already is a module for it. For example, there are at least 120 modules that integrate somehow with the "organic_groups"-module: http://drupal.org/taxonomy/term/90?page=19

To simplify, is Drupal capable of true Web Applications; where the application is a >service and provides custom results to each user? Can it provide a dashboard-like >interface for users to change their settings or preferences? Can it aggregate data from >particular users to provide better results/info to others?

In short, yes. There are so many ways to achieve something you described. But probably they would involve at least the excellent "views"-module. I think of views as some kind of ultimate abstraction SQL layer and UI for anyone. And there are over 300 modules that somehow integrate with Views... ( http://drupal.org/taxonomy/term/89?page=55 )

This sounds that Drupal is all about the modules.. and I know some of my collegues even dislike it for that, because you never get to code fun stuff because it's already been done. At least you can look at the module code and learn from that. Or laugh at it, there's lots of badly programmed modules around too.

When you get to coding modules, you'll probably need lots of time to get used to the Drupal API, Forms API, Module hooks, the Theme override system, and the endless options from contrib modules. But it's worth the trouble.

I find this site very usefull to find a module for some specific need. The site shows the same module info as Drupal.org, but also user feedback/ratings, to find the best option: http://drupalmodules.com/

If it's unclear, my answer would be go with Drupal :)

PS: D7 should be out very soon. Some might wait for it instead of starting with D6. During D5 people would wait a long time before upgrading to D6 because of missing modules. I believe for D7 the most important modules will be available for D7 very fast. Some research at the moment (04.12.2010):

About 190 modules promise to have a Drupal 7 version the day D7 is released: http://drupal.org/project/modules?solrsort=sort_title%20asc&text=d7cx&display=table

About 130 modules are already available for D7 (most are included in the previous link): http://drupal.org/project/modules?filters=drupal_core:103&solrsort=sort_title%20asc&text=d7cx&display=table

EDIT: As a newbie I'm only allowed to post one link, so, I removed http:// from the drupal.org-links

Ilmari
I have to admit the link about "organic groups" is compelling. But I also wonder if there is a severe impact with Drupal module's running out-of-date when drupal core upgrades, leaving "custom" fixes incompatible with upgrades.
Andres
Patching can cause problems yes, and most feature-rich Drupal projects tend to need a patch or two. However, you most likely will never have to patch the core modules (than come with the D6.x installation). While using the previous Drupal 5-version I sometimes even had to patch core (a big no-no) to get through some issues. But D6 is more evolved and so extensible and thus I haven't had to hack any core module ever after D5, in over a dozen D6 projects. Minor core version upgrades, like 6.15 -> 6.16 are smooth: they're just bug/security fixes and modules still work.However...[text limit]
Ilmari
... Major releases like 5->6 are however not compatible: all modules need an upgrade-version, and sometimes there is none (or you have to switch to an alternative). Patched modules will need to be re-patched.The upgrade used to be a pain in the ass, for example one D4 to D5 upgrade took me months of planning (a popular site that was live, and I was Drupal-noob back then.. excuses). But that was because it had lots of custom modules and patches. And Drupal wasn't as popular back then (less modules). D5->D6 upgrade is very easy compared to that, and D6->D7 should be even easier. [text limit]
Ilmari
... To get to my conclusion: yes, patching contributed modules is best avoided, and if you have to do it, you should create an issue to the module's issue queue at Drupal.org. The developing community is really helpfull and fast increasing, and getting your own patch committed isn't that hard. I for example posted 2 patches last week and they were fixed within 24h :).Most of the issues are overridable without patches. All text output is translatable, all output is also overridable in themes, forms can be fully overwritten etc (in theory at least).One warning: too manu modules => slowness.
Ilmari
+1  A: 

I worked with both Drupal and Kohana.

In my insight it really depends what you want to do. If you are going to make a web application that needs to grow a lot and should be flexible for it's growth then I recommend using Kohana. Kohana is made to keep your codebase clean and supporting in DRY (Don't Repeat Yourself). While it likely doesn't have as many modules as Drupal it does have some Auth and ACL modules.

If you want to be done fast and you don't mind making your application out of others their modules Drupal will get your work done fast. But keep in mind that when you are going to extend you will most likely run into problems that come from modules you don't know. Also it takes a bit flexibility from you.

Ultimately it's your choice. But I recommend using a MVC framework if you are going to write it from scratch.

RJD22
Thank you! Have you worked with KO3? I'm at crossroads between KO2 and KO3. Any thoughts on CodeIgniter 2.0?
Andres
"But keep in mind that when you are going to extend you will most likely run into problems that come from modules you don't know."I fully agree. You can lessen the problems with modules though, by simply learning via their sources. Also, choose the best modules, there are usually many alternatives. I usually go with what sounds most robust and has most users.In the end knowing the various API:s of the major modules, and how they integrate together, needs looking into. If you go with Drupal you should consult someone with a few years of experience to save you from learning it the hard way.
Ilmari
@Andres: I only worked with Kohana 2.x. Kohana 2.x applies the MVC pattern. This pattern should be good enough for most projects. Also another pro of 2.x that there is better documentation available. Kohana 3.x applies the HMVC pattern, which can make your application a lot more modular and easy to manage. I also really supports the DRY method (google). Take a look here to make your choice:http://kerkness.ca/wiki/doku.php?id=what_version_of_kohana_should_i_use
RJD22