On 27/02/09 13:02, somebody called Mohit Sindhwani (t...@onghu.com) wrote this: [snip] >>> >>> Sorry to nag, but - anyone? Bueller? >>> >>> In case this was somehow regarded as trollbait, I'm asking this as a >>> legitimate query...it really is quite important for me to know, and >>> time is >>> a factor for me ATM. >>> >>> To summarise the above verbiage: >>> >>> Why is Radiant delivered with all dependencies included? >> >> Why not? >> Including the dependencies means the instructions for getting started >> for new users will be much simpler. > Actually, I have found this quite useful since you don't always have > access to installing extra gems (or your host is already on different > versions, etc.) - just like you can freeze rails to a specific version > in your specific application, this provides you the ability to create a > "Radiant app" (similar to a Rails app) with the correct versions of > everything (except Ruby) already included. > > As long as you have a compliant Ruby version on your server, you can use > it straight away. > > That said, I think you are asking 2 questions without clearly saying it: > 1. Why is Radiant provided with all its dependencies? > I think the answer is that it reduces dependencies on external code and > different versions of things. Radiant itself uses a number of plugins > and gems (incl Rails) for its work. Out of box, you are assured that > what is provided is tested to work. > > Imagine if you had Textile 4 on the server and Radiant was tested only > with Textile 3.2 and for some reason, there was a conflict that > prevented it from working properly. Here, you know it will work because > it relies on a pre-bundled version. Or in another case, you may have > that Radiant is built with Textile 4 and your server only has Textile > 3.2 - so, Radiant fails! > > In that case, you'd end up with a situation where the installation > instructions go something like: > * Install Textile 4.0 (there are known issues with 3.2 which we will not > fix because we are on a newer version) > * Install acts_as_list (version xx.y) > * Install acts_as_authenticated (version xx.y) > ...and so on! > > You *must* see Radiant as a domain-specific Rails application (though > you can even see it as a domain-specific Ruby application that relies on > a gem called Rails) that provides everything that you need to run it. > > I hope that this clarifies this point. > > 2. I think your second question is more along the lines of why don't I > just get a Rails app, rather than a Rails app that looks like a gem? > This ties in with your comment about not being able to contribute > effectively to the code, etc. I get the feeling that you would prefer a > system where when you run "radiant my_site", you would get the standard > Rails directories, including app, app>view, app>controllers, etc. > > I think some of the Radiant core team can answer this better than me, > but I'll tell you what I *feel* about this structure. > a) It makes some things more difficult for the average Rails programmer > b) It makes many things much simpler for the average CMS developer > c) If Radiant works, my life is much simpler - I don't need to worry or > look at how Radiant is built to be able to use it effectively. > > Since you started by pointing to Redmine, my answer would be: Redmine is > a Rails application for project tracking, etc. It is not a "framework" > for building project tracking applications. IMHO, Radiant is a > framework for building CMS sites. Therefore, the base stuff is kept out > of your way while you can go ahead and build the other things you need - > content, markup, extensions and plugins. You don't use "radiant", you > use a site built using Radiant. > > In some ways, I could say that asking why Radiant is a gem with > dependencies is like asking: why is Rails a gem? Why isn't Rails just > distributed as a set of libraries that someone has to put together by > themselves. I don't know Rails internals, but the question is akin to > asking if all the internal parts of Rails should have been distributed > completely separately. > > Hope this helps. > > Cheers, > Mohit. > 2/27/2009 | 12:02 PM.
It does - thanks very much for your clear comments, and also for Jim's questions. The "application" vs. "framework" analogy was particularly useful. Thanks for taking the time. Jim, I haven't answered your questions since Mohit's answer clarifies a lot for me, and much of my opinions were/are based on little more than gut feel and a lot of IT experience. Were I to give any answers, they likely wouldn't say more than "I'd like it to be less surprising to someone who has experience with Rails development." Again - an opinion - which by definition can't always be (rationally) justified. I can't say I agree with everything that Mohit has stated - although I'll readily concede 2a and 2b! - but I understand a little better now. Again - thanks. Cheers, Mark __________________________________________________ Mark Glossop - lists <AT> cueballcentral <DOT> com _______________________________________________ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
