On 27/02/09 13:02, somebody called Mohit Sindhwani (t...@onghu.com) wrote
>>> 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.

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

Reply via email to