# Radiant as an Engine?

**URL:** <https://www.ruby-forum.com/t/radiant-as-an-engine/64370>\
**Category:** Radiant CMS\
**Created:** [June 24, 2006, 8:46pm UTC](https://www.ruby-forum.com/t/radiant-as-an-engine/64370 "2006-06-24T20:46:12Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![Andrew\_OSBrien](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d6d6ee/32.png) [@Andrew\_OSBrien](https://www.ruby-forum.com/u/Andrew_OSBrien)\
**Post date:** [June 24, 2006, 8:46pm UTC](https://www.ruby-forum.com/t/radiant-as-an-engine/64370/1 "2006-06-24T20:46:12Z")

</div>

Hi, I just started playing around with Radiant (looks pretty sweet –  
well done). I was wondering (and forgive me if this is a dumb  
question or has been covered already) would it be feasible and/or  
advantageous to package Radiant as a Rails Engine?

Being relatively new to Engines, I don’t know too much about them  
other than they supposedly allow you to override pretty much  
everything in the standard Rails install while keeping the codebases  
separate from each other. It seems like this would be a good way to  
keep in sync with new Rails releases while also allowing Radiant to be  
upgraded easily while it’s in development.

Thoughts?

Thanks,  
Andrew

---

<div class="post-metadata">

**Author:** ![Andrew\_OSBrien](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d6d6ee/32.png) [@Andrew\_OSBrien](https://www.ruby-forum.com/u/Andrew_OSBrien)\
**Post date:** [June 24, 2006, 9:30pm UTC](https://www.ruby-forum.com/t/radiant-as-an-engine/64370/2 "2006-06-24T21:30:09Z")

</div>

Personally, I like this idea. I was thinking of starting an effort to  
package it as an engine myself. Maybe if pull it off we can put it in  
the Radiant repo so we can actually do merges from the standalone to  
the engine version?

It’s one of those things that I don’t think the team is willing to  
spend time on because it’s not necessary for the milestones at hand,  
but if somebody else was willing to make it happen they’d be all for  
it.

-jeff

---

<div class="post-metadata">

**Author:** ![Andrew\_OSBrien](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d6d6ee/32.png) [@Andrew\_OSBrien](https://www.ruby-forum.com/u/Andrew_OSBrien)\
**Post date:** [June 24, 2006, 10:37pm UTC](https://www.ruby-forum.com/t/radiant-as-an-engine/64370/3 "2006-06-24T22:37:43Z")

</div>

Andrew O’Brien wrote:

> upgraded easily while it’s in development.
> 
> Thoughts?

Right now I’m not personally interested in packaging Radiant as an  
engine. I’d like to encourage people to use the `radiant` command and  
write plugins if they need custom controllers or model objects.

–  
John L.  
[http://wiseheartdesign.com](http://wiseheartdesign.com)

---

<div class="post-metadata">

**Author:** ![Andrew\_OSBrien](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d6d6ee/32.png) [@Andrew\_OSBrien](https://www.ruby-forum.com/u/Andrew_OSBrien)\
**Post date:** [June 26, 2006, 7:51am UTC](https://www.ruby-forum.com/t/radiant-as-an-engine/64370/4 "2006-06-26T07:51:48Z")

</div>

Except for this creates a dependency on the engines plugin which is  
‘monkey patched’ into the rails internals so that most major revisions  
break it. Not only that but the core team on the core mailing list have  
made note of their distaste for engines due to their high level of  
functionality and the way it hooks into rails. Rails and rails plugins  
should be about small building blocks and not huge chunks of prebuilt  
functionality. This is just one of the reason rails succeeds where  
others fail.

If you are going to package an application (like radiant) then package  
it as an application. It is a mistake to become so enthralled with  
modularizing everything that you lose site of what your product really  
is. It will make it easier for most people to install if it’s a) a gem  
that creates a system command and b) generates an entire directory  
structure including the plugins it needs. In reality 80% of people are  
going to use it that way out of the box and then modify it instead of  
trying to drop it into a pre-existing rails application directory.

Just my two cents.

Josh F.

---

<div class="post-metadata">

**Author:** ![Andrew\_OSBrien](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d6d6ee/32.png) [@Andrew\_OSBrien](https://www.ruby-forum.com/u/Andrew_OSBrien)\
**Post date:** [June 26, 2006, 6:40am UTC](https://www.ruby-forum.com/t/radiant-as-an-engine/64370/5 "2006-06-26T06:40:24Z")

</div>

> Right now I’m not personally interested in packaging Radiant as an  
> engine. I’d like to encourage people to use the `radiant` command and  
> write plugins if they need custom controllers or model objects.

I’ve never looked at engines until about 5 minutes ago, but from what  
I’m seeing radiant is pretty much an ideal fit as an engine - it’s  
exactly how I had imagine radiant should be packaged, but I thought the  
reason it wasn’t done that way is because it was hard.

I don’t think that packaging up radiant as an engine would in any way  
harm your ability to provide exactly what you’re already providing. The  
radiant command, instead of setting up a rails environment with all the  
radiant stuff in app directory, it would set up an environment with  
everything in the vendor/plugins/radiant\_engine directory.

When you’re making an application based on radiant, radiant is not your  
application - your behaviours, your controllers, your models are your  
application. With the way radiant is currently deployed it’s very messy  
trying to sort out what is what - especially with version control.  
Ideally radiant would be an svn external in your plugins and everything  
else is yours.

It would also make my job easier in trying to extend radiant - instead  
of taking the existing codebase and tearing it apart and rebuilding it,  
I could just build another engine on top of it to provide the extra  
functionality that I’m after.

---

<div class="post-metadata">

**Author:** ![Andrew\_OSBrien](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d6d6ee/32.png) [@Andrew\_OSBrien](https://www.ruby-forum.com/u/Andrew_OSBrien)\
**Post date:** [June 26, 2006, 8:39am UTC](https://www.ruby-forum.com/t/radiant-as-an-engine/64370/6 "2006-06-26T08:39:31Z")

</div>

> Except for this creates a dependency on the engines plugin which is  
> ‘monkey patched’ into the rails internals so that most major  
> revisions break it.

That’s the bit I hadn’t investigated yet - the quality of the engines  
project. From reading the overview of what it does, it sounded like  
something that should be possible with only some manipulation of  
‘require’, but there’s a lot of hacking required because of the way in  
which rails loads the views (there were other changes there, some of  
which seemed like they were just changing internals for fun, but view  
loading looked like it took up most of it). Introduction of a dependency  
that you don’t trust as stable is a good enough justification for me.

> Rails and rails plugins  
> should be about small building blocks and not huge chunks of prebuilt  
> functionality. This is just one of the reason rails succeeds where  
> others fail.

I think, however, that you’re arguing that radiant should be monolithic.  
Radiant as it stands is a big chunk of prebuilt functionality. If you’re  
arguing that radiant should be more like rails in order to succeed,  
Engines, or something similar, sounds like the right direction to go  
down.

> It will make it easier for most people to install if it’s  
> a) a gem  
> that creates a system command and b) generates an entire directory  
> structure including the plugins it needs. In reality 80% of  
> people are  
> going to use it that way out of the box and then modify it instead of  
> trying to drop it into a pre-existing rails application directory.

It’s easy to _install_ at the moment, but I’m not sure about the ease of  
maintainence - there’s no clear seperation between what belongs to  
radiant and what belongs to your site. People for the most part aren’t  
going to dump this into an existing site, but people are going to want  
to build extra bits around it and make some customisations. Radiant is a  
component of my application, not the other way around. I think that’s  
something that needs to be kept in mind when thinking about the  
extensibility of radiant.

Mainly for me, it’s about the fact that if I want to keep my site’s code  
under version control, I’m going to have to create a vendor branch of  
radiant and merge changes in, because I can’t just do an svn:externals  
to grab radiant in.

I would like a way to have radiant seperated from the application - I  
might still have a play at what’s needed to create a radiant engine - If  
it’s just the case of restructuring directories and adding a config file  
or two, then creating an engine could be done by just setting up a bunch  
of svn:externals.

Dan.

---

<div class="post-metadata">

**Author:** ![Andrew\_OSBrien](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d6d6ee/32.png) [@Andrew\_OSBrien](https://www.ruby-forum.com/u/Andrew_OSBrien)\
**Post date:** [June 26, 2006, 3:29pm UTC](https://www.ruby-forum.com/t/radiant-as-an-engine/64370/7 "2006-06-26T15:29:54Z")

</div>

On 26-Jun-2006 01:50 -0400, Josh F. was heard to say:

> Except for this creates a dependency on the engines plugin which is  
> ‘monkey patched’ into the rails internals so that most major revisions  
> break it. Not only that but the core team on the core mailing list have  
> made note of their distaste for engines due to their high level of  
> functionality and the way it hooks into rails. Rails and rails plugins  
> should be about small building blocks and not huge chunks of prebuilt  
> functionality. This is just one of the reason rails succeeds where  
> others fail.

There is one big disadvantage to plugins: they don’t support controllers  
or  
views out-of-the-box and require mixins with the Rails core to make them  
work. While that is not a problem when you add features to an  
application  
you are going to develop, it is significantly less useful if you want to  
extend an existing application such as Radiant. I myself have a hard  
time  
to develop a plugin system for Radiant which supports custom  
controllers,  
models and views, where views are actually the most difficult parts. I  
know  
this thread is about Radiant as being an engine, but I just want to  
emphasize that Rails plugins are not the solution to any extension  
problem.

Cheers,  
Oliver

---

<div class="post-metadata">

**Author:** ![Andrew\_OSBrien](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d6d6ee/32.png) [@Andrew\_OSBrien](https://www.ruby-forum.com/u/Andrew_OSBrien)\
**Post date:** [June 26, 2006, 2:21pm UTC](https://www.ruby-forum.com/t/radiant-as-an-engine/64370/8 "2006-06-26T14:21:07Z")

</div>

Daniel S. wrote:

> I’ve never looked at engines until about 5 minutes ago, but from what  
> I’m seeing radiant is pretty much an ideal fit as an engine - it’s  
> exactly how I had imagine radiant should be packaged, but I thought the  
> reason it wasn’t done that way is because it was hard.

Again, it’s more my personal preference about the way I would like  
people to use Radiant.

The `radiant` command in Subversion allows you to create a new project  
that references another Radiant code base (a Radiant “instance”  
project). The code base can be either stored as a gem on your system or  
checked out into another directory.

I feel that it’s better to encourage people to create a Radiant  
“application” (a subset of Rails applications), than to encourage them  
to run Radiant as a library (which is the engine concept). If you get to  
the point where you feel you need to do a substantial amount of  
customization to Radiant in order for it to meet your needs, you may be  
better off starting from scratch and creating your own Rails  
application.

> I don’t think that packaging up radiant as an engine would in any way  
> harm your ability to provide exactly what you’re already providing. The  
> radiant command, instead of setting up a rails environment with all the  
> radiant stuff in app directory, it would set up an environment with  
> everything in the vendor/plugins/radiant\_engine directory.

If you’d like to package and distribute Radiant as an engine separately,  
I’d encourage you to do so.

> functionality that I’m after.  
> Use a instance project and write a plugin that adds the functionality  
> you need?

–  
John L.  
[http://wiseheartdesign.com](http://wiseheartdesign.com)

---

<div class="post-metadata">

**Author:** ![Andrew\_OSBrien](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d6d6ee/32.png) [@Andrew\_OSBrien](https://www.ruby-forum.com/u/Andrew_OSBrien)\
**Post date:** [June 26, 2006, 4:20pm UTC](https://www.ruby-forum.com/t/radiant-as-an-engine/64370/9 "2006-06-26T16:20:40Z")

</div>

Has anyone had any succes getting the Mailer behaviour to work? I  
keep getting an error:

protected method `get\_class\_name’ called for #\<MailerBehavior:  
0x409b6698\>

The instructions are a bit sparse so I might just be doing something  
wrong…

---

<div class="post-metadata">

**Author:** ![Andrew\_OSBrien](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d6d6ee/32.png) [@Andrew\_OSBrien](https://www.ruby-forum.com/u/Andrew_OSBrien)\
**Post date:** [June 26, 2006, 9:38pm UTC](https://www.ruby-forum.com/t/radiant-as-an-engine/64370/10 "2006-06-26T21:38:28Z")

</div>

Unfortunately after a last round of modifications, it seems that both  
the mailer and password protection plugins from Matt are working any  
more with the current radiant release. I’m looking to him for further  
news on this subject 🙂