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.
