I'm a rails developer of about 1 year. I've come to a point where I can quickly produce features in hours and days, not weeks or months. UI design is another strong point of mine so building interfaces that flow and look good doing it aren't hard for me. However, as a web developer for a university forced to use to Drupal, I still don't see how this tool (drupal) is better than rails for developing web apps to manage content.
The star feature of most content management systems are user role/group management. The ability to control how and what content people are allowed to produce. The fact is, I can produce that same feature(s) in rails. And, in the same amount of time it takes to download, setup and configure drupal. Building content management isn't hard in and of itself. Its just when you want to build a one-size fits all solution that really starts to get complicated.
I honestly believe Drupal is a great tool for content producers who need more flexibility than that of your run of the mill blogging tools (i.e., Wordpress or MovableType). But when I really want to-the-tee functionality with the highest adaptability, drupal loses appeal.
So I guess my only question is where does drupal gain its appeal for people like myself who understand UI design, content management and user role management enough to roll their own CMS? I'm a hard case, so come packing.
[thread locked - http://drupal.org/node/102269#comment-272701]
Comments
I'm not really qualified to answer but I will anyway
Here is my personal path to Drupal that happens to have started with Ruby on Rails. I'm really not a hard core programmer but I have some done quite a bit of database programming and a little asp.net/C# so I have some experience.
Here's the path:
Heard about Ruby on Rails - probably first time on the Web 2.0 podcast - and decided it was worth a look. I wanted to get my website into the 21st century and it seemed to be the programming approach with all the buzz.
I bought and read the Pragmatic Programmer Ruby and Rails books. Loved Ruby. Loved Rails.
Downloaded Ruby and Rails, got the servers going and started messing around with it. Still in love at this point.
Decided I needed to implement blog functionality as a key element of the new website so I started looking around the Ruby/Rails community for something canned that I could either use or adapt. There was Typo and one other, don't remember the name. I tried them out but found them very limited in capability, not terribly stable and generally just unsatisfactory.
So, I took a look around the blog community to see if there was some standard blogging software out there that I could work into an otherwise Ruby/Rails website. Surprise, surprise. There is a ton of it and I settled in to take a look at WordPress since it seemed to be as close to the industry standard as I was likely to find. I liked it. I considered abandoning Ruby/Rails and just building a website around WordPress. But ... it really didn't have the full up multimedia kind of capability that I was after.
So, I kept looking and discovered this strange new thing call CMS. What the heck is CMS? Yes, I know this seems terribly naive to your average Drupal user but I just hadn't been paying enough attention.
And ... the path from discovering Content Management Systems is only a Google search or two away from the best of them and it's name is DRUPAL. And once you have discovered that people are giving away $1,000,000 software that will do everything you can imagine and that there are hundreds of developers working night and day to add to the already fabulous capablity then this, as they say, was an easy sale.
The bottom line is that yes, you probably can do a Drupal equivalent via Ruby on Rails but you won't have the development community behind you that Drupal does. Ruby on Rails is growing fast and the R on R community is too. But when I had to pick, I picked Drupal.
Drupal vs Rails
Sure you could code up the basics of a CMS in Rails, but you would be doing more of the work yourself.
Drupal has hundreds of addon modules for all kinds of different bits of functionality that more or less just slot straight in - you would only need to do tweaking rather than writing from scratch or any heavier integration work. Also these other features are maintained and improved without you having to do all that yourself. You can just one day think "hmmm, I'd like to add X to my site(s) now..." and chances are you could just download and install something to do X without having to code it.
Its a matter over leveraging the work of a community instead of redoing it.
Yeah, PHP can be a bit painful compared to better (IMO) languages like Ruby or Python. But I think the community of developers around Drupal is its biggest asset. As open source CMSes go, Drupals core design is really good and allows people to add generic reusable functionality easily - and then share it with the community.
--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ
Cookie Cutter at Best
Yes, but this doesn't allow for much flexibility. All your work becomes at the hands of other developers and not you. In a way your projects end up working for drupal instead of the other way around.
Personally I dislike basing my projects off cookie cutter representations of what I want. It seems tacky in a lot of ways. One module may have been developer by a seasoned code who's worth their salt while another may be developed by an intermediate newb. Then my "application" is based varying standards and thats just not cool.
So go switch your university to your custom CMS then
We don't really care. Although the university might if you are the only person responsible for supporting/maintaining/updating it etc.
In terms of convincing anyone, we don't have to convince you of anything. If you want your university to switch to your unproven hypothetical cookie cutter free CMS, you are the one that needs to do the convincing. After all it could be a nice cushy lifetime support gig for yourself - it would be well worth doing a decent sales pitch.
--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ
Just answer the question at hand
The whole purpose of this post was to aggregate different perspectives cause my own is clearly biased. Your attitude is nothing short of useless to everyone here. The usual standard is if I'm dealing with these kinds of decisions then plenty others probably are as well. If you don't care, then contribute to a different topic.
You don't realize there are still plenty more options to explore here. Drupal just happens to be one of those. Because the response time for the Drupal community is top-notch, I presented the question/perspective here. The least you can do is be objective and express your perspective on the issue.
I did answer the question at hand
I gave my opinion on why working with a community rather than going it alone is a better option. But your responses basically indicated that you would still prefer to reinvent wheels rather than use other peoples inferior code that would give you cookie cutter sites.
That's fine, I don't have a problem with that. But to complain that your dismissive response provoked an equally dismissive one back at you is a bit rich. If you are expecting people to repeatedly butt heads with you until you finally get our point(s), well we've probably got better things to do.
If you had replied asking for further clarifications, elaborations or other useful info you would've got it.
--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ
Have you read my latest
Have you read my latest reply toward the bottom?
I did afterwards
And I realised your were more open minded than your first reply indicated (to me at least).
As you no doubt already know Rails and Drupal are quite different. Both could be described as frameworks - one is a web development framework and the other is a CMS/online community framework than just happens to include a basic no frills CMS/online community site out of the box. Both 'frameworks' are automating stuff for web developers. Rails automates all the tedious low level (and some higher) web development stuff, while Drupal aims more at providing a pluggable site skeleton for automating (or centralising really) a lot of the higher level aspects of an online community site.
I can understand why Rails is more tempting than Drupal - I've been toying with Turbogears myself. If it wasn't for Drupal, I probably wouldn't touch PHP.
But to really have a Rails alternative to Drupal, you would need to look at a CMS framework built on top of Rails in my opinion - and no doubt they already exist even if they might not yet be as mature as Drupal. Creating and maintaining/improving an adaptable CMS is a lot more work than it seems at first and joining forces with another viable project is a far wiser approach. While each little feature doesn't look difficult by itself, they quickly start stacking up and getting harder and harder to all integrate together smoothly.
After all wouldn't you rather be dealing with higher level site design stuff than the lower level parts of the sites infrastructure?
--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ
This smug, childish, and
This smug, childish, and generally irrelevant attitude is exactly why I have left Drupal.
It is rampant among the community, from the random user all the way up to the top developers.
When speaking with other clients and developers who also have had past experience, it is the #1 reason they also cite for leaving.
Your response was no better than that of a toddler, and unfortunately, it isn't rare either. Which is sad, considering Drupal strives to be taken seriously among professionals.
Are you sure...
...that the occasional strong opinon is why you left Drupal? Surely it would need something more than that?
In terms of this thread, wouldn't a fairly hostile Rails user appreciate Opinionated Software when looking for a CMS?
Lets face it, this person isn't the same sensitive soul that a web neophyte installing their first open source CMS would be, and I treated them differently
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
That was an example of a
That was an example of a "hostile" user?
Looks to me like someone who figured out the problem wasn't the software but their understanding of it, and was capable of admitting to that mistake. In turn, they even shared their experience and a little advise, in a non-offensive way, and helped the community.
Had you provided the link as example of what a "helpful" Drupal post might look like, I'd whole-heartedly agree.
thread locked
An almost year old thread was revived to engage in this name calling.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
All your work becomes at the
This is a "not invented here" mentality, and it's an extremely difficult strategy at which to succeed. No matter how much better you may be than other developers, no matter how much more productive or higher quality you may be, the numbers are stacked against you. One great programmer may be able to be as productive as ten average programmers, but not 100 (not that I'm suggesting the core Drupal developers are merely average). Sure, you may be able to produce something better, but can you produce it in time for the next deadline?
The law of averages is against you. One a project involves two people, the quality becomes the average of the two. The bigger the project, the more likely it is to be average.
Just look at how hard it has been to succeed in the computer business. Microsoft is king with mediocre stuff and copy-cat technology, IBM survived on sheer size, HP on diverse business lines, while DEC, Wang, and most of the BUNCH are memories. Apple struggled for years, in spite of having superb products, until they branched beyond personal computers into consumer electronics. Even then, they've been forced to go with the Intel architecture, in spite of whatever technical superiority Motorola may have had.
None of this means you shouldn't follow your strategy. Just understand how slow and difficult it will be.
Gary Feldman
Rails is a framework, not a CMS
I have been grappling with the same exact question over the course of several projects. The outcome was different for each and for me, frankly, it really depended on the use case. First though, I really have to take issue with your assertion that building a CMS from scratch in Rails isn't hard. I would know because I tried it. I grant you it's certainly a lot easier going than it would be in Java, or even PHP if I were starting with nothing, but if you believe that then either a) your application is of an extremely, almost degenerately simple nature or b) you haven't really thought the thing through. If a) then Drupal is probably overkill and that's that. If b), trust me when I tell you it's more work than you think.
Yes, there are Rails plugins for authentication and authorization. But if you need fine-grained, instance- or class-level permissions; if you need to do any sort of user management; if you need roles; if you need modal / continuation-like login support--if you need any of these things, you're going to find yourself spending a substantial amount of time implementing them, because they mostly don't exist out of the box for Rails right now. (Yes, I am aware of several different auth generators, but in each case I found them lacking and wound up writing a lot from scratch.)
Yes, Rails technically supports file uploading. Clearly a pretty crucial operation in the context of a CMS. But does it support it well? Notice how scaffold treats a BLOB column, for example. Validation and file management are left pretty much up to the coder. Do you store files in the FS or in the DB? Is your storage method secure? How do you handle access rights and ownership for uploaded files? It would be nice if convention over configuration worked so well that you could just say
has_many :images, but in my experience it largely doesn't, and you're going to end up doing lots of it by hand.These are but two examples; there are lots of other things that are a real PITA to write yourself that I found myself missing in Rails. Searching. Workflows. Multi-part forms. Better I18N.
Again, I'm not saying all these problems are intractable in Rails; it's probably easier to implement them in Rails than with other frameworks and, indeed, progress appears to be being made on lots of them. But the fact remains you'd be largely reinventing the wheel by doing so. I recently designed a site for an enviromental nonprofit who were very budget constrained and wanted to be able to update the site themselves, without contracting a web guy. While I could have easily pounded something out in Rails that would fit the bill, I just bunged my templates into Drupal and about 3 hours later had a working prototype that I could train people on. And I got full-text searches, dynamic menus, navigation, etc. etc. for free. And, I spent 0.0 hours coming up with an intuitive UI for it all--don't underestimate how involved that process is.
Now I'm working on a simple web shop for a local artisan. She wants to be able to post products, photos, descriptions, etc., plus all the fun e-commerce stuff. Could I write that in Rails? Yes. Would I? Hell no.
I agree with you that to-the-tee functionality and adaptability are Rails' strong points, and clearly there are some cases where only this will suffice. If you're writing applications that have little to do with CMS, then Rails is hands down your best bet for non-enterprise stuff. BaseCamp is a shining example--surely would have been a bear to write that in Drupal/PHP (in fact I think DHH tried, thus Rails.) But if your site is at its core content management with some other stuff thrown on, I believe it will always be easier to hack Drupal.
asdf
I just did the same and thought you might want to take a look. http://www.met-studios.com (aviation art). I made use of the image.module, watermark.module, ecommerce.module and a custom module to hold information about the art. Need to do some clean-up, due to the watermark module degrading the image quality, but the Artist I did this for is pleased.
I would have still been working, had I been using ror.
Have fun and check my Drupal Profile: http://drupal.org/user/519
You present great points...
Well you hit it on the nail. I really don't want to match Drupal feature by feature cause I don't feel all those features are necessary. I truly believe a lot of what Drupal offers get in the way of getting things done for developers (not all of them). I know Drupal isn't a framework, but its vast module/plugin system makes it one in a loosely fit sort of way. I have seen several modules that were built and because of recent enhancements to drupal (i.e. 5.0) they stop development on that module or take an unusually long time to upgrade. This scares me, cause if you do in fact upgrade the Drupal core you lose previously working features. In rails I have not had to deal with this. Maybe a few code changes here and there.
I guess I'd rather build a contextual CMS as opposed to using an everything-to-everyone CMS. For example, a cms for universities, or for churches or for non-profit organizations. Something that actually fits perfectly with a given group or set of tasks. I guess its a matter of perspective.
Excellent questions
As I like to say, I drank the Drupal kool-aid a while back and I'm not really qualified to say much about RoR. I've tinkered with it briefly, and it looks very powerful, especially the clean way tht it handles database schemas, etc.
RoR is a language and a framework, as many others have noted. Drupal lives halfway between 'framework' and 'cms.' The advantage isn't necessarily in the inherent design or implementation of Drupal, though I prefer it to the other packages I've worked with. The benefit comes from leveraging the work that other developers do in the same space. In the past two months, more times than I can count, I've looked at my to-do list for client sites, than looked at the CVS checkins and realized another Drupal dev solved the problem I would've had to pour a couple days into.
That's not something unique to Drupal -- any active community of developers can generate the same positive effect. But I've found it here. It's good stuff. :-)
--
Lullabot! | Eaton's blog | VotingAPI discussion
--
Eaton — Partner at Autogram
Hard Case or Not
I downloaded Rails (that was easy), and I ran it in Windows and OS/X (also easy). It wouldn't run on my AIX 4.3.3 though. All versions of Drupal run anywhere, anytime.
And that does it for me.
Drupal compared to a real programming environment
I'm a Perl guy, so in somewhat a similar relationship to Drupal. Personally, I chose Drupal because it has so many pre-built plugins especially ones aimed at social networking and at community-based organizations, because it has a community of people interested in the issues of social networking and community organizing, because it gets most of the UI issues right. I absolutely *love* Drupal for those features and don't know of anything else that has all of them.
The things I find horrifying about Drupal are:
I realize that both of these are hard given a need for backward compatability with older PHPs and older MySQLs, but IMNSHO, Drupal won't be a real programming environment until it has these features.
P.S. But that won't stop me from using Drupal when it's the right tool for the job. :-)
Agreed.
Agreed.
In fact the real topic of
In fact the real topic of this issue is whether Drupal can and should be designed as a scriptable environment, a system that something akin Microsoft's Visual Basic or ROR's command line can be applied to.
The more I use Drupal the more I realise how much I am dependent on a pointy-clicky environment which defeats the whole purpose of what programming is about - issuing commands to an interpreter to carry out tasks, although in fairness to Drupal that is what popular computing is about today.
I think Drupal developers should develop some kind of object oriented guidelines that module developers have to adhere to using strict setter and getter interfaces and it probably requires its own little language. I have a feeling that the basics are already in place and once something like that is started it will become easier and easier as time goes by.
e.g if I want to enable a theme for instance I should be able to issue a command such as themes.bluemarine.enable.
If I want to make a Autologout visible in bluemarine I can try something like theme.bluemarine.EnableWidget(Autologout). If I want it the right side bar then that would be theme.bluemarine.PositionWidget(Autologout) = right_side_bar. If I have a number of site I could simply keep a store of these snippets and apply them easily there as well.
I have a funny feeling that Ruby programmers with a good knowledge of Drupal's internals can come up with something like that pretty quickly. Alas I am neither a Ruby nor a Drupal expert.
I've got to start hacking
Before going down a
Before going down a discussion of object-oriented programming, please read the canonical article Drupal Programming from an Object-Oriented Perspective. It should come as no surprise that this subject has been much discussed in the past.
Don't confuse syntactic sugar with object-orientation. This syntax is neither more nor less object-oriented than themes_enable("bluemarine"), at least for the way object-oriented gets used outside the Smalltalk community. That doesn't mean syntax is irrelevant, but it's a different issue.
Gary Feldman
I have previously read that
I have previously read that article, but if you read my comment in this article Drupal considered dangerous for startups? (which I see you also had some comments on) you will see where my interest lies.
I feel however a module can have separate object-oriented interface which may or not be within the .module file itself, and should really be the basis on which hook interface itself should be constructed. It could be optional and more knowledgeable developers (or those with more time in hand) could create their modules on such a basis.
They can then be invoked to perform tasks outside the GUI front end, with the support of a little language, which does not necessarily have to be PHP.
In fact if Drupal abandons the direct to SQL oriented design, and uses an ORM system in the future this alone can go along way to making Drupal easier to manage.
If Drupal is gets more oriented towards developers than end users (which it appears to be) this approach will be better in the long term for developers and end users alike. Making things easier for developers allows them to make things easier for end users as Microsoft's success testifies.
Yeah, I know that Microsoft is not a name open source guys like to hear, but that is one of the main foundations of their success.
I don't know how well Drupal is oriented towards such an approach, but it is something to consider.
Short answer - it doesn't
where does drupal gain its appeal for people like myself
Short answer: it probably doesn't. But it does appeal to your employer (in a good way) and I thought I might be able to help shed some light on why for my first post here on drupal.org.
I can totally empathize with your outlook - - I've been in the same situation many times myself. Once you've experienced the power that comes from being truly adept at a particular platform/language/framework and rolling your own solutions, it can be very difficult to "settle" for a standardized solution that offers less than what you want in a particular case (and, btw, I am also a big RoR booster myself.)
That said, I thought I'd offer you a business gal's perspective on this, since that's my primary role these days.
The long and the short of it: if I were your boss, and the business requirement was primarily CMS-oriented, I would probably make you use Drupal too.
There are too many reasons to list them all here, but a lot of them revolve around the following four:
1) Standardization and maintainability. What happens to your custom RoR app when you want to move on to bigger and better things or, God forbid, get hit by a bus? Individual developers always love to handroll, using their tool of choice, but as soon as your code needs to be supported by a 3rd party, the more standard parts, the better - - no matter how well documented your custom code might be (and we all know what a rarity decent documentation is in the real world.)
2) Robustness/confidence/real world testing - as long as you are judicious in your selection and application of modules, you can have a high degree of confidence that things will work. Not true for a handrolled solution. You might believe it will work under high stress and a large number of different use cases, but it's another thing entirely to _know_ that it will, based on thousands of hours of real world testing.
3) Portability - I imagine you're running your own servers right now, but the overwhelming direction for IT departments long term is outsourced, managed hosting. Here again, standardization is your friend. Sure there are many hosts that offer RoR now, but service levels and packages vary widely due to it's new-ness. PHP and MySQL are EVERYWHERE, and Drupal is so popular that many of those hosts offer 1-click installs. They are also willing to provide much more extensive support for a Drupal site than a completely handrolled one (this gets back to standardization and maintainabilty, of course.)
4) Power of leveraging an existing codebase. I spend a lot of my days reining in coders who want to write custom code for a given requirement, rather than leverage existing stuff. It's become a truism at this point that this is typically the case, because generally speaking, code is easier to write than read. It's also less creative to re-use something than to build something new, and most coders are very creative - that's why they became coders! (the good ones, anyway.)
However that doesn't change the fact that with a project like Drupal, you have an army of developers working for you - 24 hours a day, 7 days a week - for free. If you make the investment of time and effort to truly leverage that, the ROI can be potentially enormous.
one girl's perspective, fwiw.
MJ
I guess Drupal would be more appropriate
Your response is definitely a nudge in the right direction. All those points are very smart and right on point for what I was expecting. I feel as though my eyes have been opened a little bit. However, I must admit that I will never be able to retain the same passion for Drupal as I have for rails. But your response does indeed give me new insight and even a spark of desire to attain happiness using Drupal.
Thanks again.