Jim Gay wrote:
On Feb 26, 2009, at 10:22 PM, Mark Glossop wrote:
On 26/02/09 05:58, somebody called Mark Glossop
([email protected])
wrote this:
Hi all - first time poster here [didn't want to hijack the thread about
Dreamhost, so started a new one...I have a very specific question,
related to
the OP about Dreamhost.]
It's good to be hearing this about Dreamhost now, especially when
I'm looking
to deploy this weekend. Only started with Radiant about a week ago.
Doing my
dev work on local box, and have been a little concerned about the
sorcery that
it may take to get everything moved over onto Dreamhost's "special"
environment. I'm deliberately doing all the dev locally since that's
how I'm
used to doing Rails dev work; no developtestduction here! :-)
Anyhow - this whole issue brought something back to me...something that
initially made me steer away from Radiant as a CMS when I was
looking around
at various CMS options. I liked Radiant, but didn't like the way it was
packaged up. Evidently that's not enough of a reason for me to _not_
use it,
but the question remains:
Why is Radiant delivered as a gem with "all the dependencies
included"? Or,
put another way, why is it not delivered as a Ruby gem with external
gem
dependencies, that generates a "standard" Rails app structure when
invoked?
Some clarification (please note, all of the following are IHMO):
* Some much larger apps [Redmine comes to mind] don't use this
approach and
are actually simpler to deploy than Radiant. Really.
How so?
* Yes, I know "standard" isn't exactly well-defined AFA Rails is
concerned.
* "gem unpack" is not a valid answer/workaround.
Why not?
You can also "rake radiant:freeze:gems" or "rake radiant:freeze:edge"
Or you could clone the repository and modify it just like any other app.
* The closest rationale I have found for this question is in the
Radiant FAQ -
"Gems: Versions of any required libraries are built-in. So that
means that you
don't need to have the rails gem installed: the radiant gem comes
bundled with
a particular version."
Right...
* It also makes it harder to consider contributing code to Radiant.
How so?
Apart from my own curiosity, my business partners will want to know
why I have
chosen Radiant for the CMS I am working on. This info helps me with
them.
If the full reasoning behind this design decision is already online
somewhere,
please just point me there, as my Google-fu has obviously not been
working.
Thanks!
Cheers,
Mark
*bump*
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.
_______________________________________________
Radiant mailing list
Post: [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
