Radiant as an Engine?

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

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

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

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.

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.

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.

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

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

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…

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 :slight_smile:

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs