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, appview, appcontrollers, 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
