Hello all, Maybe the $subj is a little bit weird (i.e. apples vs oranges) but it is a situation i am facing at the moment: We are developing a small web site which will be mostly a CMS (more or less) and my colleagues is arguing for drupal, and i am for RoR. Maybe i can formulate the question in a different way: when to use a CMS (not necessarily drupal but e.g. Radiant CMS) and when to use Ruby on Rails? I think if you *really* want just the usual functionality of a CMS, i.e. like WordPress for blogging, then you can do well with drupal/radiantCMS/WordPress/whatever. That means you install it and use it. But if you want a little bit of this, a little bit of that later (and i think that''s exactly our case, maybe it won''t be even a little but rather a bigger set of features) then i think in the long term it is better to go for Ruby on Rails. What do you think? Where is the border? We are both Java coders by trade so coding is not a problem. Also when we go for drupal, if i will have to change something, i will have to hack !!PHP!! PHP! Ouch. To cite DHH: ''PHP is the devil''. Well, who i am to argue?! ;-) Please try to figure out some good arguments against drupal ;-) It is not enough (for me absolutely, but not for my colleague) that it is PHP - i need something better. Thx, Peter
Peter Szinek wrote:> Hello all, > > Maybe the $subj is a little bit weird (i.e. apples vs oranges) but it is > a situation i am facing at the moment: We are developing a small web > site which will be mostly a CMS (more or less) and my colleagues is > arguing for drupal, and i am for RoR. > > Maybe i can formulate the question in a different way: when to use a CMS > (not necessarily drupal but e.g. Radiant CMS) and when to use Ruby on > Rails? > > I think if you *really* want just the usual functionality of a CMS, i.e. > like WordPress for blogging, then you can do well with > drupal/radiantCMS/WordPress/whatever. That means you install it and use > it. > > But if you want a little bit of this, a little bit of that later (and i > think that''s exactly our case, maybe it won''t be even a little but > rather a bigger set of features) then i think in the long term it is > better to go for Ruby on Rails. What do you think? Where is the border? > We are both Java coders by trade so coding is not a problem. > > Also when we go for drupal, if i will have to change something, i will > have to hack !!PHP!! PHP! Ouch. To cite DHH: ''PHP is the devil''. Well, > who i am to argue?! ;-) > > Please try to figure out some good arguments against drupal ;-) > It is not enough (for me absolutely, but not for my colleague) that it > is PHP - i need something better. > > Thx, > PeterHi Peter, I think you have to have a look at http://www.railfrog.com ( a next generation CMS with Rails) What they are trying to do seems really great for me. I know that a Drupal core developer is also part of the Railfrog core developper. Railfrog is current at 0.51, I hope the 0.6 will be soon for the public. Regards, Brice -- Posted via http://www.ruby-forum.com/.
> I think you have to have a look at http://www.railfrog.com ( a next > generation CMS with Rails) > What they are trying to do seems really great for me. I know that a > Drupal core developer is also part of the Railfrog core developper. > Railfrog is current at 0.51, I hope the 0.6 will be soon for the public.Thx for the reply! I will take a look at Railfrog for sure. However, the second facet of my question is still open: Where to draw the line between CMS and a DIY RoR app (a the function of the aditional features, i.e. if i want the functionality of a CMS +1-2 small things, then an existing CMS, but if i want 10 big fetures which would be cumbersome to do with an existing one, i would go for RoR. The question is this number - what is the critical mass of the additional features where you already say ''ok i won''t hack RailFrog but rather roll my own code''...? Cheers Peter
Drupal comes with a ton of features. How many of those are you going to use? You have to determine how long it will take you to recreate those features in RoR. Then you have to determine what the next 10 features are. If they are pie in the sky type features that you may not ever get around to then you may want to go with Drupal. I would negotiate a compromise here... I would say, put up drupal, but any new features that we want must be written in RoR. That way both parties get what they want. Your partner gets a site up fast with Drupal and you can use RoR to build new functionality. At some point in time RadiantCMS or Railfrog can replace Drupal and you will be in a pure RoR environment. On 5/12/06, Peter Szinek <peter@rubyrailways.com> wrote:> > > I think you have to have a look at http://www.railfrog.com ( a next > > generation CMS with Rails) > > What they are trying to do seems really great for me. I know that a > > Drupal core developer is also part of the Railfrog core developper. > > Railfrog is current at 0.51, I hope the 0.6 will be soon for the public. > > Thx for the reply! I will take a look at Railfrog for sure. > However, the second facet of my question is still open: Where to draw > the line between CMS and a DIY RoR app (a the function of the aditional > features, i.e. if i want the functionality of a CMS +1-2 small things, > then an existing CMS, but if i want 10 big fetures which would be > cumbersome to do with an existing one, i would go for RoR. The question > is this number - what is the critical mass of the additional features > where you already say ''ok i won''t hack RailFrog but rather roll my own > code''...? > > > Cheers > Peter > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Carl Fyffe wrote:> Drupal comes with a ton of features. How many of those are you going > to use? You have to determine how long it will take you to recreate > those features in RoR. Then you have to determine what the next 10 > features are. If they are pie in the sky type features that you may > not ever get around to then you may want to go with Drupal. > > I would negotiate a compromise here... I would say, put up drupal, but > any new features that we want must be written in RoR. That way both > parties get what they want. Your partner gets a site up fast with > Drupal and you can use RoR to build new functionality. At some point > in time RadiantCMS or Railfrog can replace Drupal and you will be in a > pure RoR environment.I see. This sounds very good and most probably acceptable for both parties. The problem is i never did something like this - i.e. to integrae new Rails functionality into an existing workframe - how is this done in practice? Web services? If you could post some pointers on this (not WS or other generic technique as i did such stuff in Java already, but addressing the concrete ''how could drupal-RoR or Railfrog-RoR work together'' problem), i would be very thankful. In fact, i am already because of this cool idea ;-) Cheers, Peter
> The problem is i never did something like this - i.e. to integrae new > Rails functionality into an existing workframe - how is this done inerrata: to integrate into a framework ;-)
On 5/12/06, Peter Szinek <peter@rubyrailways.com> wrote:> If you could post some pointers on this (not WS or other generic > technique as i did such stuff in Java already, but addressing the > concrete ''how could drupal-RoR or Railfrog-RoR work together'' problem), > i would be very thankful. In fact, i am already because of this cool > idea ;-)I have one question. Is this for you, internally, or for a client, externally? I have *never* seen a "common" CMS work well without headaches for a client. They will always eventually want something against the CMS''s abilities. Then you are stuck developing the custom framework you should have developed in the first place and then migrating data to it (or at best hacking a framework that was never meant to do what you''re needing it to do and you don''t know intimately enough to quickly do). You could reimplement the core of drupal in a decent amount of time in RoR.
On Fri, 2006-05-12 at 15:52 +0200, Peter Szinek wrote:> Hello all, > > Maybe the $subj is a little bit weird (i.e. apples vs oranges) but it is > a situation i am facing at the moment: We are developing a small web > site which will be mostly a CMS (more or less) and my colleagues is > arguing for drupal, and i am for RoR. > > Maybe i can formulate the question in a different way: when to use a CMS > (not necessarily drupal but e.g. Radiant CMS) and when to use Ruby on > Rails? > > I think if you *really* want just the usual functionality of a CMS, i.e. > like WordPress for blogging, then you can do well with > drupal/radiantCMS/WordPress/whatever. That means you install it and use it. > > But if you want a little bit of this, a little bit of that later (and i > think that''s exactly our case, maybe it won''t be even a little but > rather a bigger set of features) then i think in the long term it is > better to go for Ruby on Rails. What do you think? Where is the border? > We are both Java coders by trade so coding is not a problem. > > Also when we go for drupal, if i will have to change something, i will > have to hack !!PHP!! PHP! Ouch. To cite DHH: ''PHP is the devil''. Well, > who i am to argue?! ;-) > > Please try to figure out some good arguments against drupal ;-) > It is not enough (for me absolutely, but not for my colleague) that it > is PHP - i need something better.---- I''m not sure why you are fighting PHP. Drupal is a fairly extensive CMS system whereas RadiantCMS and any other CMS type system for rails isn''t going to be nearly as complete or as polished. Thus, to get a site up and running, you should be able to do that in far less time using Drupal and PHP. The only issue where rails would make more sense would be where you had to do custom programming to add features that aren''t present in Drupal. Craig
> I have one question. Is this for you, internally, or for a client, > externally? I have *never* seen a "common" CMS work well without > headaches for a client. They will always eventually want something > against the CMS''s abilities. Then you are stuck developing the custom > framework you should have developed in the first place and then > migrating data to it (or at best hacking a framework that was never > meant to do what you''re needing it to do and you don''t know intimately > enough to quickly do). You could reimplement the core of drupal in a > decent amount of time in RoR.Yep, exactly my thoughts. One small question to the last sentence: what do you think how much is ''decent amount of time'', if we consider really just the very core of drupal (or similar -and build up the other features later) Cheers, Peter
> I''m not sure why you are fighting PHP.Are you kidding? This is a RoR forum ;-) Well, because i like Ruby and Rails much-much-much more than PHP. I like to code in Ruby/Rails very much, whereas PHP coding is more like a punishment for me ;-) Np offense, this is just my opinion. If PHP is your stuff, cool, but i will stick with Ruby/RoR until something better appears (candidates are not yet on the radar, at least not on mine)...> Drupal is a fairly extensive CMS system whereas RadiantCMS and any other > CMS type system for rails isn''t going to be nearly as complete or as > polished.I believe you. But in my case it is the similar analogy as of Microsoft Word and Writely. Writely offers everything i will ever need to write MY documents, so although it is true MS Word has more feats, i won''t use it just because of that, but i will take different points into consideration. This point in my case is Ruby/RoR.> Thus, to get a site up and running, you should be able to do that in far > less time using Drupal and PHP. The only issue where rails would make > more sense would be where you had to do custom programming to add > features that aren''t present in Drupal.Well, exactly this is my situation: We will need some (lot?) of features in the future sure which are not offered by a CMS, and then it is easier (for me) to hack RoR than PHP. Cheers, Peter
On 5/12/06, Peter Szinek <peter@rubyrailways.com> wrote:> Yep, exactly my thoughts. One small question to the last sentence: what > do you think how much is ''decent amount of time'', if we consider really > just the very core of drupal (or similar -and build up the other > features later)Honestly, I tried to install Drupal once and hacked at it for a day and got virtually no where. So I have some...predetermined angst...which is unfair. After wasting a *lot* of time searching for the One CMS to Rule them All, have lost much faith in the cookie-cutter-ness of CMS solutions. They are great for the core of a community website, and I think good for open-source communities. But I feel they are not good for the corporation (or software development shops). (Personal opinion only, flamewars abound, your mileage may vary.) Looking at the feature overview (http://drupal.org/features) of Drupal doesn''t look to be incredibly impressive honestly. Much of it is built into (or highly trivial) with a bit of RoR experience. User Management / Authentication = 4-8 hours Content Management / Polls / Static&Dynamic = 8-16 hours Blogging / Syndication / etc = 8 -16 hours (less if you use other code or a plugin) Honestly all other "features" there are basically built in or so trivial it''s not even worth mentioning... Logging... Please... A Log model can easily accomplish that in RoR (1 hour)... And it could be implemented as a plugin so you can call it from *any* other Model / View / Controller... I would say it would take 1 - 2 weeks to get a better system that will be more easily extensible and do what you want it to do, and only what you want it to do. CMS''s are too bloated, get feature creep from the community, and are convoluted... But that''s just my humble opinion. :) They have their uses, but I''ve given up on them for "external" or "client-based" development. (Conversely, if you are familiar with one and have successfully implemented a few sites, then go for it... But you need to study them fairly well and understand how they do things to apply them to a project.) We have also created a "core" application (in three flavors, mostly authentication schemes--pluggable) that we use as a basis for all our Rails apps... So we basically have a CMS core without the bloat and feature-creep to start from. I recommend all software shops do something similar that works for them. You made it, you know it. I would also like to mention the fact that our core flagship clients are J2EE clients. And we are mostly disgruntled Java programmers. Just kidding, Java has its uses, but I can see many places that RoR is a great fit. PHP has its place too... But you have to apply things where they fit, and I think RoR and Agile Web Development is a better fit for dynamically changing things like client websites. When was the last time you heard from a client "perfect! We''ll *never* need anything beyond this..." And if you do hear that, just expect the call next week... :) Java can stay on the back-end... But RoR should belong on the front-end. (I don''t know enough about Ruby itself yet to contribute much to the Ruby on the back-end discussion.) I personally, would be thrilled to never write another JSP page. :)
Curtis wrote:> On 5/12/06, Peter Szinek <peter@rubyrailways.com> wrote: > >> Yep, exactly my thoughts. One small question to the last sentence: what >> do you think how much is ''decent amount of time'', if we consider really >> just the very core of drupal (or similar -and build up the other >> features later) > > > Honestly, I tried to install Drupal once and hacked at it for a day > and got virtually no where. So I have some...predetermined > angst...which is unfair. After wasting a *lot* of time searching for > the One CMS to Rule them All, have lost much faith in the > cookie-cutter-ness of CMS solutions. They are great for the core of a > community website, and I think good for open-source communities. But > I feel they are not good for the corporation (or software development > shops). (Personal opinion only, flamewars abound, your mileage may > vary.) > > Looking at the feature overview (http://drupal.org/features) of Drupal > doesn''t look to be incredibly impressive honestly. Much of it is > built into (or highly trivial) with a bit of RoR experience. > > User Management / Authentication = 4-8 hours > Content Management / Polls / Static&Dynamic = 8-16 hours > Blogging / Syndication / etc = 8 -16 hours (less if you use other code > or a plugin) > > Honestly all other "features" there are basically built in or so > trivial it''s not even worth mentioning... Logging... Please... A > Log model can easily accomplish that in RoR (1 hour)... And it could > be implemented as a plugin so you can call it from *any* other Model / > View / Controller... > > I would say it would take 1 - 2 weeks to get a better system that will > be more easily extensible and do what you want it to do, and only what > you want it to do. CMS''s are too bloated, get feature creep from the > community, and are convoluted... But that''s just my humble opinion. > :) They have their uses, but I''ve given up on them for "external" or > "client-based" development. (Conversely, if you are familiar with one > and have successfully implemented a few sites, then go for it... But > you need to study them fairly well and understand how they do things > to apply them to a project.) > > We have also created a "core" application (in three flavors, mostly > authentication schemes--pluggable) that we use as a basis for all our > Rails apps... So we basically have a CMS core without the bloat and > feature-creep to start from. I recommend all software shops do > something similar that works for them. You made it, you know it. > > I would also like to mention the fact that our core flagship clients > are J2EE clients. And we are mostly disgruntled Java programmers. > Just kidding, Java has its uses, but I can see many places that RoR is > a great fit. PHP has its place too... But you have to apply things > where they fit, and I think RoR and Agile Web Development is a better > fit for dynamically changing things like client websites. When was > the last time you heard from a client "perfect! We''ll *never* need > anything beyond this..." And if you do hear that, just expect the > call next week... :) > > Java can stay on the back-end... But RoR should belong on the > front-end. (I don''t know enough about Ruby itself yet to contribute > much to the Ruby on the back-end discussion.) I personally, would be > thrilled to never write another JSP page. :) > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >If the site you are talking about is mainly used like a CMS go with typo3, why the heck Drupal ??? There is absolut no problem to add new extensions/functionality to it in no way. The best of all this CMS is the BE, with all the rightsmanagement for editors, etc If you need all that you will have a hard time to rebuild that with RoR, also it isnt good practice to reinvent the wheel. If yo would decide to port type (or Drupal) into something based on RoR, at least it should be better...otherwise it makes no sense....and typo3 for example has 7 years in front, how much will it take you to port it to RoR, not taking in count I am talking here about developingtime...menyears would be 7 multiplicated by number of coreteammembers and helpers...so probably there are 20, 30 or more years of work in ?? I dont know... If you not need nor 10 of the "thousands" of features typo3?s BE is coming with, then do it in RoR, probably taking one of those packages who started allready as a RoR CMS as a base But the way you argue and reply to mails here, I have the impression you allready have taken your decicion, so this is kind of "virtual talk", isnt it ?? In any way its much to abstract to be responded correctly from anyone here as everything depends...noone knows better than yourself Good luck Matthi PS: i would be really happy to see something like typo3 made "in" RoR one day for sure, but I doubt we will see such thing soon...
On 5/12/06, matthibcn <matthibcn@gmail.com> wrote:> If you need all that you will have a hard time to rebuild that with RoR, > also it isnt good practice to reinvent the wheel.True. My only point was that I have been part of and seen too many times where instead of reinventing a wheel that fits, people will find any five tires and bolt them with square lugnuts to a semi... Well, if you want the trailer to move, you need more than five wheels. And you usually don''t find out about the trailer until two months after the project for the truck is finished. And I personally don''t like being in the position of *then* reinventing the wheel... All 18 of them... But again, YMMV... If you know you''re going to have requirements beyond what the existing packages will offer, why implement one knowing you''re going to have to rearchitect it? Why not save time initially and just create the whole thing custom. (Preferably drawing on a core of something else, but if you don''t have that, then you will have to write it at one point... If you do it intelligently you can utilize it to get the next project off the ground even more quickly.)
Curtis wrote:> einventing the wheel... All 18 of them... But again, YMMV... > > If you know you''re going to have requirements beyond what the existing > packages will offer, why implement one knowing you''re going to have to > rearchitect it? Why not save time initially and just create the whole > thing custom. (Preferably drawing on a core of something else, but if > you don''t have that, then you will have to write it at one point... > If you do it intelligently you can utilize it to get the next project > off the ground even more quickly.) > _______________________________________________You probably allways will have, and good luck its that way, but thats it where consultancies make money from Short answer, as this is still the RoR list and I am the last who wants to change that ;) If you need a couple fo new features BUT also all the features a package as TYPO3/Drupal (I dont know it though) has, then you just cant reinvent that wheel, cause it would take you years, meanwhile extending the former in any direction ( I repaet it here at least for typo3: IN ANY DIRECTION) is a matter of hours/days/weeks...depending on what you need, but still you would have also developmenttime in RoR for the "new" features, and even if this would be 30 times faster than just those 10s, you wont earn the years you would need to rebuild what "others" build over years in front, that is why you wont do that. And..imagine you come up at 2015 with your own TYPO3/Drupal etc...you client is leaving happily the door as a new one enters. It turns out, he needs similar thing to the one before, but you would have to add stuff to fit the new ones needs...dont tell me you would start off again just cause you know his requirements are beyond of the former clients one... Cheers Matthi
Curtis wrote:> On 5/12/06, matthibcn <matthibcn@gmail.com> wrote: > >> If you need all that you will have a hard time to rebuild that with RoR, >> also it isnt good practice to reinvent the wheel. > > True. My only point was that I have been part of and seen too many > times where instead of reinventing a wheel that fits, people will find > any five tires and bolt them with square lugnuts to a semi... Well, > if you want the trailer to move, you need more than five wheels. And > you usually don''t find out about the trailer until two months after > the project for the truck is finished. > > And I personally don''t like being in the position of *then* > reinventing the wheel... All 18 of them... But again, YMMV... > > If you know you''re going to have requirements beyond what the existing > packages will offer, why implement one knowing you''re going to have to > rearchitect it? Why not save time initially and just create the whole > thing custom. (Preferably drawing on a core of something else, but if > you don''t have that, then you will have to write it at one point... > If you do it intelligently you can utilize it to get the next project > off the ground even more quickly.)Well, i can absolutely agree with you Curtis (maybe because he told me the things i wanted to hear ;-). During my career so far i have reinvented the wheel a lot of times, especially in my ultra-young-and-enthusiastic days (which is a bad practice in general, of course) but i believe this is a question of granularity: if you are doing something small (e.g. quicksort) it is almost sure you are reinventing the wheel. If you move towards something bigger, we can not always talk about pure reinventing, but rather reimplementing with some customization. And if you are onto something really big (like a CMS) it is almost certain that you are not going to do *exactly* the same thing somebody already did, but at least a very customized one, or maybe even a very different stuff at some places. That''s why imho it we can not always throw something into the ''reinventing the wheel'' bag, especially if it is something bigger. And i believe this is exactly my case ;-) Anyway, thanks for all the replies so far, it was really good to hear how others are thinking about this problem and know that i am not alone with my thoughts... I am still undecided but at least much better equipped for a discussion with my drupal colleague. Thx again! Cheers, Peter
Peter Szinek wrote:> >Anyway, thanks for all the replies so far, it was really good to hear >how others are thinking about this problem and know that i am not alone >with my thoughts... I am still undecided but at least much better >equipped for a discussion with my drupal colleague. Thx again! > > >Yeah, and by the way point him to typo3.org ;) We all know, the dude who invented the first wheel was an idiot. The one who invented the other 3 was a real genius... So maybe one comes up one day with the missing 3, hopefully in RoR, I wouldn?t stop anyone from trying Good luck with your project Matthi
On 5/12/06, Peter Szinek <peter@rubyrailways.com> wrote:> Anyway, thanks for all the replies so far, it was really good to hear > how others are thinking about this problem and know that i am not alone > with my thoughts... I am still undecided but at least much better > equipped for a discussion with my drupal colleague. Thx again!:: snipsnipsnippperoonie :: I agree, in summary, with the core of the discussion. And I probably have some current angst because it feels like nearly everything I''ve been doing outside of Java lately has been helping to correct badly-written PHP code. (Disclaimer: I am by no way saying that PHP programmers, by definition, write bad code...it just seems to me that the majority of bad code I see nowdays is PHP scriptkiddies code.) A real developer can take any language and make it sing. It''s easier to make some languages sing than others... RoR is like being given a nice fat opera singer to work with; PHP is more like being given Clay Aiken... But you can make either work. In my experience, every time I''ve dug into a prepackaged CMS, it''s a nightmare to get some things to work the way you want. Integration sucks...but it''s a goal we all have. And I''ve hacked phpBB into more "CMS" apps than I want to admit... Typo3 is a pretty well-written package. But also, those people are working on these apps for years; but it''s usually a labor of love, not money; so of those years, usually weeks are only spent writing. If you have 40 hours a week, you can put a decent CMS together in a short amount of time; even in PHP... I''m not advocating reinventing every wheel. Or that anything is the One Silver Bullet. There is no Holy Grail of programming. There never has been, there never will be...things are just too complex. But part of being a developer is knowing the shortest, best path to solve a problem. And RoR goes a *long* way in that for a large core of things. Personally, I never want to see PHP again, unless I''m hacking it apart and rebuilding it in RoR. ;) I maintain that anything PHP can do, RoR can do better and faster. This includes a CMS. And I''ve seen some cool stuff coming out of the RoR CMS projects. I can''t wait to see them after a stable run...a little more maturity. But still...they will be a general CMS and not always the solution. I await the day that Slashdot switches to RoR. :: grins evilly :: That should stir up some people...
I wish people would stop calling Drupal a Content Management System, its a canned community (or "Community Management System") that happens to give you the ability to edit and categorize some content. It is very weak in the workflow department, nor does it support content outside of the Web paradigm very well (to this day, there isn''t even a decent File/Document Management component). In fact, 90% of the Web-based CMSs are Community Management Systems -- and they''re not much better. Each piece of the puzzle has rough edges or is tightly-coupled to a set usage: it really is a shame that so much of the community development process is wasted on very un-DRY-like activities, like writing an Amazon booklist widget or a "shoutbox"... 27 times, in 27 different PHP CMSs. On the other end of the spectrum, you''ve got the Java "scientists", writing Portlet and Framework specifications with barely a functional forum component to show for. In fact, there are more frameworks than features meaning you''re pretty guaranteed writing everything from scratch or following some obtuse specification down a dark tunnel, for reason unknown to you, except that "its the way its supposed to be done". I think RoR is the sweet spot here. Writing a site with the usual suspects -- simple categorization/taxonomy engine, authentication engine, dynamic menus, and basic CRUD content entry -- is pretty much done with a handful of RoR community components and built-in RoR functionality. Create it. Display it. Secure it. Thats really the tri fecta of every interactive Web site nowadays and almost out-of-the-box, you can accomplish all of this with RoR. To me, RoR comes much closer to the UNIX philosophy of "many small programs doing one thing very well" and the community seems to be getting that -- you don''t see as much conflicting agendas and alot of overlap between components. And even if there is, I''d wager that the RoR/OO train of thought puts interop and loose coupling at a premium meaning that things tend to play nicely together. Unless you''re building a canned community, I''d choose RoR. On 5/12/06, Curtis <cuspendlove@gmail.com> wrote:> On 5/12/06, Peter Szinek <peter@rubyrailways.com> wrote: > > Anyway, thanks for all the replies so far, it was really good to hear > > how others are thinking about this problem and know that i am not alone > > with my thoughts... I am still undecided but at least much better > > equipped for a discussion with my drupal colleague. Thx again! > > :: snipsnipsnippperoonie :: > > I agree, in summary, with the core of the discussion. And I probably > have some current angst because it feels like nearly everything I''ve > been doing outside of Java lately has been helping to correct > badly-written PHP code. (Disclaimer: I am by no way saying that PHP > programmers, by definition, write bad code...it just seems to me that > the majority of bad code I see nowdays is PHP scriptkiddies code.) > > A real developer can take any language and make it sing. It''s easier > to make some languages sing than others... RoR is like being given a > nice fat opera singer to work with; PHP is more like being given Clay > Aiken... But you can make either work. > > In my experience, every time I''ve dug into a prepackaged CMS, it''s a > nightmare to get some things to work the way you want. Integration > sucks...but it''s a goal we all have. And I''ve hacked phpBB into more > "CMS" apps than I want to admit... Typo3 is a pretty well-written > package. But also, those people are working on these apps for years; > but it''s usually a labor of love, not money; so of those years, > usually weeks are only spent writing. If you have 40 hours a week, > you can put a decent CMS together in a short amount of time; even in > PHP... > > I''m not advocating reinventing every wheel. Or that anything is the > One Silver Bullet. There is no Holy Grail of programming. There > never has been, there never will be...things are just too complex. > But part of being a developer is knowing the shortest, best path to > solve a problem. And RoR goes a *long* way in that for a large core > of things. Personally, I never want to see PHP again, unless I''m > hacking it apart and rebuilding it in RoR. ;) > > I maintain that anything PHP can do, RoR can do better and faster. > This includes a CMS. And I''ve seen some cool stuff coming out of the > RoR CMS projects. I can''t wait to see them after a stable run...a > little more maturity. But still...they will be a general CMS and not > always the solution. I await the day that Slashdot switches to RoR. > :: grins evilly :: That should stir up some people... > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
GravyFace wrote:> I wish people would stop calling Drupal a Content Management System, > its a canned community (or "Community Management System") that happens > to give you the ability to edit and categorize some content. It is > very weak in the workflow department, nor does it support content > outside of the Web paradigm very well (to this day, there isn''t even a > decent File/Document Management component). >So then have a decent look of typo3, and you are proofed wrong.> In fact, 90% of the Web-based CMSs are Community Management Systems -- > and they''re not much better. Each piece of the puzzle has rough edges > or is tightly-coupled to a set usage: it really is a shame that so > much of the community development process is wasted on very > un-DRY-like activities, like writing an Amazon booklist widget or a > "shoutbox"... 27 times, in 27 different PHP CMSs. >Yeah, that is what most people are missing in typo3, the community stuff. And the same un-DRY activities pop up here in the RailsCommunity, otherwise you canT explain the various activities and starting CMS packages all over the web based on RoR, out of my head I could call at least 3 or 4 yet. None of them will have only the chance to compete with something as typo3 for the next couple of years. Period. Anything prooving me wrong is very welcome, cause I would also prefer rails over php, but one has to be pragmatic, not ? How many authentication/login systems do we have, how much globalisationProjects are on its way...etc pp This repeated stuff isnt the fault of php nor of RoR, its based on the fact, that pl think they are faster, better if they reinvent the wheel cause their needs are going beyond of what they get right now....> On the other end of the spectrum, you''ve got the Java "scientists", > writing Portlet and Framework specifications with barely a functional > forum component to show for. In fact, there are more frameworks than > features meaning you''re pretty guaranteed writing everything from > scratch or following some obtuse specification down a dark tunnel, for > reason unknown to you, except that "its the way its supposed to be > done". > > I think RoR is the sweet spot here. Writing a site with the usual > suspects -- simple categorization/taxonomy engine, authentication > engine, dynamic menus, and basic CRUD content entry -- is pretty much > done with a handful of RoR community components and built-in RoR > functionality. > Create it. Display it. Secure it. > Thats really the tri fecta of every interactive Web site nowadays and > almost out-of-the-box, you can accomplish all of this with RoR. > > To me, RoR comes much closer to the UNIX philosophy of "many small > programs doing one thing very well" and the community seems to be > getting that -- you don''t see as much conflicting agendas and alot of > overlap between components. And even if there is, I''d wager that the > RoR/OO train of thought puts interop and loose coupling at a premium > meaning that things tend to play nicely together. > > Unless you''re building a canned community, I''d choose RoR. >Unless you dont have to deal with various editors once the site is running, or even various levels of editors, decent rightsmanagement for each step in the publishing process unless you dont need clever multilanguagesitesetup and contentmanagement, unless you dont need..go with Rails, and make sure to post us an URL for the project once you have finished it So, just to avoid any confusion: I dont argue against RoR at any point, I dont argue for php either, I would prefer RoR over any phpsolution, BUT "he" was looking for a CMS TODAY, "he " wasnt asking what happens, if one farday he would need to use a CMS but also extend it probably...this is all that vague...I think this whole discussioon was quite useless as the starter left us assuming , assuming, assuming...instaed of sketching out his needs in detail and asking based on that, but I wonder if he has sketched his needs for himself yet... Anyway, I am out of this discussion at this point... There must be a difference between pragmatic and fanatic at some point, and for sure one could (re)build phpbb or oscommerce in RoR, but then, who will, how long will it take...and better, where is this TODAY ?? Regards Matthi
matthibcn wrote:> So then have a decent look of typo3, and you are proofed wrong.Actually he said "most" so if one is really good, then "most" still qualifies.> None of them will have only the chance to compete with something as > typo3 for the next couple of years. > > Period.I wouldn''t be so sure. Open Source projects have a history of moving at different speeds. As I mentioned in a previous post, the time scale in OSS compared to real life is flawed. It''s like "dog years". Perhaps we should call them OSS years or something. A project that''s been alive for 10 years hasn''t been in steady development by a large number of people for the same timeframe. :: shrug :: There is nothing stopping someone from commercially creating an RoR framework and releasing it to a degree as OSS. Unlikely maybe, but putting absolutes on it is silly.> > How many authentication/login systems do we have, how much > globalisationProjects are on its way...etc pp > This repeated stuff isnt the fault of php nor of RoR, its based on the > fact, that pl think they are faster, better if they reinvent the > wheel cause their needs are going beyond of what they get right now....This proves my point. A component doesn''t work for what *I* needs, so I write one that does. It doesn''t matter if there is more than one way of doing something. It''s doing the *exacty* same thing twice that''s silly. There is some duplication of that sort likely, but that''s human frailty...none of us are perfect. :)> So, just to avoid any confusion: I dont argue against RoR at any > point, I dont argue for php either, I would > prefer RoR over any phpsolution, BUT "he" was looking for a CMS TODAY, > "he " wasnt asking what happens, if > one farday he would need to use a CMS but also extend it > probably...this is all that vague...I think this whole discussioon > was quite useless as the starter left us assuming , assuming, > assuming...instaed of sketching out his needs in detail and > asking based on that, but I wonder if he has sketched his needs for > himself yet... >Actually, he specifically stated that they would have to add a fairly significant portion of functionality not provided by Drupal at a future point. Thus my entire suggestion for rolling their own instead of utilizing a PHP framework. It was the basis for my statements about trying this in the past and having nothing but nightmares. I now know a few PHP frameworks fairly well (well enough to develop modules for them). It is a nightmare, particularly PHPNuke. I couldn''t even get Drupal working on a development laptop. I probably missed something simple, but the second time I followed the installation instructions precisely (I rarely have to RTFM--with Drupal I did and still didn''t get it working). :: shrug :: There is too much "hack something to avoid reinventing the wheel" talk in software development for me...and it annoys me. If there isn''t a wheel that fits...write one. You''re not reinventing it, just redesigning and reimplementing something you won''t have to hack later.
>None of them will have only the chance to compete with something as >typo3 for the next couple of years.I''m not sure what this sentence means (sorry), but I''m assuming it''s implying that typo3 is something good. Please, if you value your time, do not use typo3. It''s a black hole, it''s quicksand. It''s ugly. I''ve been making Typo3 sites for about a year. The documentation is terrible. Recently the documentation was made even worse when the Typo3 guys redesigned their site and all their links broke, and I still can''t find half of the docs that I was finding useful. The API isn''t documented. There are no message boards, the mailing list was almost impossible to find. Some of these problems would have been alleviated if the code was structured in an easily intelligible fashion, like RoR is, but Typo3 code isn''t. Trying to find its crappy html to alter it and make it standards compliant is like wading through a Vietnamese jungle.>There must be a difference between pragmatic and fanatic at some point, >and for sure one could (re)build phpbb or oscommerce in RoR, >but then, who will, how long will it take...and better, where is this >TODAY ??I''d like to think that one could NOT rebuild oscommerce in RoR. That''s a whole nother nightmare. Ew. In conclusion: don''t go with Typo3. Daniel -----Original Message----- From: rails-bounces@lists.rubyonrails.org [mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of matthibcn Sent: Saturday, May 13, 2006 12:25 AM To: rails@lists.rubyonrails.org Subject: Re: [Rails] Re: Drupal vs. Ruby on Rails GravyFace wrote:> I wish people would stop calling Drupal a Content Management System, > its a canned community (or "Community Management System") that happens > to give you the ability to edit and categorize some content. It is > very weak in the workflow department, nor does it support content > outside of the Web paradigm very well (to this day, there isn''t even a > decent File/Document Management component). >So then have a decent look of typo3, and you are proofed wrong.> In fact, 90% of the Web-based CMSs are Community Management Systems -- > and they''re not much better. Each piece of the puzzle has rough edges > or is tightly-coupled to a set usage: it really is a shame that so > much of the community development process is wasted on very > un-DRY-like activities, like writing an Amazon booklist widget or a > "shoutbox"... 27 times, in 27 different PHP CMSs. >Yeah, that is what most people are missing in typo3, the community stuff. And the same un-DRY activities pop up here in the RailsCommunity, otherwise you canT explain the various activities and starting CMS packages all over the web based on RoR, out of my head I could call at least 3 or 4 yet. Period. Anything prooving me wrong is very welcome, cause I would also prefer rails over php, but one has to be pragmatic, not ? How many authentication/login systems do we have, how much globalisationProjects are on its way...etc pp This repeated stuff isnt the fault of php nor of RoR, its based on the fact, that pl think they are faster, better if they reinvent the wheel cause their needs are going beyond of what they get right now....> On the other end of the spectrum, you''ve got the Java "scientists", > writing Portlet and Framework specifications with barely a functional > forum component to show for. In fact, there are more frameworks than > features meaning you''re pretty guaranteed writing everything from > scratch or following some obtuse specification down a dark tunnel, for > reason unknown to you, except that "its the way its supposed to be > done". > > I think RoR is the sweet spot here. Writing a site with the usual > suspects -- simple categorization/taxonomy engine, authentication > engine, dynamic menus, and basic CRUD content entry -- is pretty much > done with a handful of RoR community components and built-in RoR > functionality. > Create it. Display it. Secure it. > Thats really the tri fecta of every interactive Web site nowadays and > almost out-of-the-box, you can accomplish all of this with RoR. > > To me, RoR comes much closer to the UNIX philosophy of "many small > programs doing one thing very well" and the community seems to be > getting that -- you don''t see as much conflicting agendas and alot of > overlap between components. And even if there is, I''d wager that the > RoR/OO train of thought puts interop and loose coupling at a premium > meaning that things tend to play nicely together. > > Unless you''re building a canned community, I''d choose RoR. >Unless you dont have to deal with various editors once the site is running, or even various levels of editors, decent rightsmanagement for each step in the publishing process unless you dont need clever multilanguagesitesetup and contentmanagement, unless you dont need..go with Rails, and make sure to post us an URL for the project once you have finished it So, just to avoid any confusion: I dont argue against RoR at any point, I dont argue for php either, I would prefer RoR over any phpsolution, BUT "he" was looking for a CMS TODAY, "he " wasnt asking what happens, if one farday he would need to use a CMS but also extend it probably...this is all that vague...I think this whole discussioon was quite useless as the starter left us assuming , assuming, assuming...instaed of sketching out his needs in detail and asking based on that, but I wonder if he has sketched his needs for himself yet... Anyway, I am out of this discussion at this point... Regards Matthi _______________________________________________ Rails mailing list Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails