Radiant More

[Kunal Shah]

Hello Everyone,

 A number of awesome commits have recently been made to keep Radiant in sync with the latest and greatest features in Rails. That's fantastic, and I'm also happy that Radiant has received some well deserved press, accurate or not. I think the majority of people on the list are pleased with the simplicity of Radiant core but all recognize that customizations to that base is where interesting (and profitable) work is done.

So It appears we let the "Radiant more" discussion die out. I'd like to bring it back into the forefront but with a framework for this discussion.

Michael Kessler threw out a few points in his last email, which I'll reiterate (via copy and paste):

- less time to setup for people who needs more functionality than what  
comes with Radiant "Core"
- better cooperation of different extension (e.g. reorder and copy  
move, both essential but not working properly in all cases together)
- bundling our integration (development) power to have Radiant "More"

At Digital Pulp we've developed several extensions, from asset management to content templating, which greatly extend core functionality. Each extension has been developed in isolation. I'm glad to say (and to my colleagues credit) that integrating them into a superproject has been relatively pain free.

But along the way, we've all dealt with dependency management issues and discovered our own patterns for handling them - as you all have as well. Establishing / agreeing to a single pattern for dependency management seems to me to be one of the largest issues to tackle in making Radiant more a reality.

In no particular order I'd like to bring up a few issues on my mind.

Gem Dependencies

Tackled by Josh French and implemented in edge: http://github.com/radiant/radiant/commit/322aaf13558b093ef539bdf6483db10baf6743d0

View Hooks / Region Sets

Extension A loads before extension B, however A wants to add/modify a region set B creates. Because B hasn't loaded and the region set isn't yet created, the activate method fails.

Can the Region Sets be refactored to gracefully handle such situations? (should they be?)

Can the Admin UI create a shell for region sets that are referenced but don't yet exist?

config.extensions / Load Order

Obviously a problem which exists outside of Radiant, and a pitfall of dynamic languages.

Can the "Radiant More" team build/refactor extensions in such a way that config.extensions does not need to explicitly set?

Extension Co-Dependencies

Michael described two rather essential extensions, "reorder" and "copy move", which have problems working with each other. It also has problems fluently existing in the presence of multi site, but thats another issue. The problem we're discussing is the position column retaining its value after a move.

I agree that these are both essential extensions. While it may make sense to not solve this problem in Radiant more, and to just to assume that both extensions will be present and therefore update the position column explicitly, I think that would set a bad precedent. It would require two branches of code and prohibit users of "More" from swapping out extensions.

(My solution - have the ReorderExtension create a before_save hook on the Page model that watches for changes to parent_id and adjusts the position column accordingly, I'll submit that shortly)

The trickier problems exist where you need to check if another extension is active and make changes accordingly. I for one am not happy with our solution, e.g:

!!defined?(MultiSiteExtension)

The problem is I'd like "More" to never assume the presence or state of any extension so that individual extensions in stock 'more' may be swapped out

Note this problem was partially addressed in aforementioned commit by Josh, which allows for a better way to check for an extension. But what patterns can we institute that'll prevent the need?

Can anyone suggest a pattern for handling this in "More"?

Extension #deactivate

I know the deactivate method is long deceased, but humor me for a minute and consider that it could maybe - just maybe be useful with a few ground rules.

Deactivate demigrates any changes it made to the database. The database signature after a migrate-demigrate cycle must be identical for inclusion in Radiant more.

Deactivate also triggers an (optional?) application reload thereby removing references to it's classes and its views from the view path.

Perhaps in this manner, "More" is a subset of all the extensions that abide by certain rules.

Initial "More" Extensions

The first iteration of "more" should include a small list of well spec'ed extensions that represents a cross section of common CMS functionality.

To that end: Reorder, Copy Move, Page Preview, File System (?), Paperclipped, and FCK (or Wym) Editor... Am I missing some?

--------

The opinions here are my own, and I'm sure many will disagree, please do so.

I'm continually shocked how differently each one of us uses and develops for Radiant (that's a good thing) so the usage considerations I missed are very welcome.

Kunal Shah

Developer, Digital Pulp

[Marak Squires]

Kunal -

Thank you for the research! I look forward to hearing the responses to these questions. We should think about organizing a hack day / weekend sometime in August to pull this all together. 

I think one of the best benefits of having Radiant More will be for users to quickly install a well featured, well tested, Radiant CMS instance. A lot of people get turned off by Radiant because they do not understand the nature of the core / extension system. Users will go to http://www.radiantcms.org/demo/ and think that is the only functionality. 

-Marak

[Adam van den hoven]

I think that the best way to handle this is not by creating some "new" thing but rather by using what already exists. Specifically, I would use the Rails 2.3 templates to wrap up all the functionality. It would require adding some Radiant Specific code (notably for installing extensions and setting Radiant::config values. You should be able to overcome a lot of the problems with this approach. For example, extension dependencies are "easily" resolved by setting the load order in the config. Well "simply" write things in such a way that you explicitly set the load order to match the install order in the script.

This also allows you to more easily freeze to specific tested copies of extensions, for example.

Adam

[john muhl]

On Fri, Jul 17, 2009 at 8:08 AM, Adam van den
hoven<adam.van...@gmail.com> wrote:
> I think that the best way to handle this is not by creating some "new" thing
> but rather by using what already exists. Specifically, I would use the Rails
> 2.3 templates to wrap up all the functionality.

that sounded like an interesting idea so i tried to throw something together.

the rails template stuff pretty much takes care of gems, plugins,
manipulating environments or whatever. i tried to use super_export and
import_export to save the page, sns, snippet and layout content but
couldn't get that to work. you can use whatever you want to install
extensions; script/extension install, ray etc.

it's a bit rough since it has to transform a rails project into a
radiant project and override rails' template_runner environment method
to make its gem method work with radiant. if radiant had a
-m/--template option that mirrored rails (and maybe extended it with a
little radiant specific stuff) it could probably be nicer.

if you have the rails 2.3.2 gem and git you can get a radiant blog
(with a bunch of blog related extensions) by running

rails blog -m http://gist.github.com/149713.txt
cd blog
script/server

>> On Thu, Jul 16, 2009 at 5:27 PM, Kunal Shah <ku...@digitalpulp.com> wrote:

>>> ...

>>> Initial "More" Extensions
>>> The first iteration of "more" should include a small list of well spec'ed
>>> extensions that represents a cross section of common CMS functionality.
>>> To that end: Reorder, Copy Move, Page Preview, File System (?),
>>> Paperclipped, and FCK (or Wym) Editor... Am I missing some?

i'm confused on what "more" is supposed to be.

is it a repository of "blessed" extensions? or to provide integrated
setups for common uses (blog, corporate, portfolio etc)?

my attempt with templates (and the impression i got from adam's
message) is aiming at the latter.

[Sean Cribbs]

Did you try `radiant -m sometemplate.rb`? It might just work.  All the radiant command does is invoke a generator.

Sean

[john muhl]

On Sun, Jul 19, 2009 at 2:35 PM, Sean Cribbs<seanc...@gmail.com> wrote:
> Did you try `radiant -m sometemplate.rb`? It might just work.  All the
> radiant command does is invoke a generator.

comes back with an "invalid option" error, but if it's just calling
the rails generator it seems like it'd be easy enough to get it to
recognize the option.

[Jim Gay]

On Jul 19, 2009, at 7:52 PM, john muhl wrote:

On Sun, Jul 19, 2009 at 2:35 PM, Sean Cribbs<seanc...@gmail.com> wrote:

Did you try `radiant -m sometemplate.rb`? It might just work.  All the

radiant command does is invoke a generator.

comes back with an "invalid option" error, but if it's just calling
the rails generator it seems like it'd be easy enough to get it to
recognize the option.

Beet is more flexible than Rails templates 

http://jackdempsey.github.com/beet/

I haven't tried it out for Radiant yet.

Jim Gay

http://www.saturnflyer.com

[Kunal Shah]

How can / do Rails templates (or Beet) handle existing applications?

The ideal implementation of "more" (for me) means extensions can be dropped in or removed without breaking the app or better yet, without changes to code or configuration (say for instance environment.rb).

Kunal