Rails 3

[Jim Gay]

Hey everybody,

Radiant development has been quiet, but it's still under development.

I'm currently on a project using Radiant and planned to do a lot of
development to move it forward. Unfortunately the project I've
inherited had a lot of serious problems that need some major surgery.
This has kept me from pushing code for Radiant.
I've been doing some work to get to a place where we can move to Rails 3 faster.
Tonight I'll be hacking with others at Arlington Ruby
(http://arlingtonruby.org) and will be working with people interested.
I've shared ideas about CMS with Patrick Peak of BrowserCMS and he'll
be there helping me move things along.

My current plan is to make a new clean project and pull things into
the engine to eventually feedback to Radiant proper. I'll update the
mailing list with details soon.

-Jim

--
Write intention revealing code #=> http://www.clean-ruby.com

Jim Gay
Saturn Flyer LLC
571-403-0338

[Jim Gay]

Yeah. I gave up because I'm just trying to get things to a working state.

I jumped the gun on pulling it in, but here's what I'm up to (I've
been meaning to write this out for a while now):

I've created a shell engine where I'm just moving code over from the
radiant repo to get tests to pass.
Adding ancestry was something I hadn't looked at yet and had some
failing specs, so I just backed it out to handle later.
This exercise has shown me just how tightly coupled our code and tests
are but I'm not planning to refactor. I just want to get things
working as an engine and move from there.

I'd like to be able to remove users and layouts and only have the
minimum needed to manage pages from an existing app. So if you already
have your own users, Radiant would just require that you hook into it
to make the association.
Likewise, layouts could be something different entirely and I'm
working with some ideas with this code
https://github.com/dissolved/radiant-file-system-resources-extension

Things have been slow and I was trying to think of the best way to
open the code up to the community. We can fork my repo to the radiant
organization and manage things there.
I started with new code just so I could have a clean slate.

Advice and contributions are welcome, but what do you think we ought
to do with this project on github? Should I make a clean branch having
no history in radiant/radiant? Or should I fork it and create
radiant/radiant-refactor?

On Mon, Apr 30, 2012 at 7:12 PM, Benny Degezelle
<be...@gorilla-webdesign.be> wrote:
> hey Jim,
>
> Nice to hear that! I found radiant-refactor in your githubz, and notice that
> you gave up on has_ancestry pretty early, may I ask why?
> I think I can spend some time on radiant in the coming weeks, any pointers?
>
> Regards,
> Benny
>
> Op woensdag 18 april 2012 21:41:34 UTC+2 schreef Jim Gay het volgende:

[Jim Gay]

I forgot to mention this: I'm doing what I can to drop dataset. It's a
test dependency that seemingly noone else uses and I have no desire to
maintain it myself.

[Johannes Fahrenkrug]

Hi Jim,

+1 on dropping dataset! It was a good idea at the time but seems to be
outdated now.

About the repo: While a clean repo sounds appealing, you lose all the
history of the test and models and whatever else we will keep
more-or-less as-is. So either a branch or a fork that we can later
merge with the main repo would be nice, I think.

- Johannes

> --
> Radiant CMS Dev Mailing List
> Post:        radiant...@googlegroups.com
> Unsubscribe: radiantcms-de...@googlegroups.com
> Group Site:  http://groups.google.com/group/radiantcms-dev/

[William Ross]

On 1 May 2012, at 03:08, Jim Gay wrote:

I forgot to mention this: I'm doing what I can to drop dataset. It's a
test dependency that seemingly noone else uses and I have no desire to
maintain it myself.

Good plan. It's a nice syntax but we're on our own there.

Agreed about users too, but layouts I think we need to keep. I've been trying different approaches to the embedded CMS and I find you often need an intermediate wrapper between the application layout and the managed content. These days I think of layouts as a way to keep page editing simple enough for users.

I am strongly in favour of a test rewrite, too: they're far too integrated, as you say, they take too long and rspec under rails 3 is a much nicer place than it used to be. Slimming down the tests would force us to describe a new API.

I have been working on rails engines of different kinds for other projects and I'm nearly ready to start working on this, but I have three big questions:

1. what is the place of a radiant extension in this new ecosystem? I think it goes two ways: the bigger extensions like event_calendar or taggable are pushed out to engines. They can interact with radiant through a published API. The smaller ones like mailer and dashboard remain as functionality patches and a nursery for new approaches. 

2. how much does radiant === radius? Personally I've come to loathe radius and its baroque opacity but I think that's more because of the way I have abused it than from any fundamental quality. It's very good at the basic job of mentioning pages on other pages, but too slow and clumsy for anything else and I wonder whether we should strip it back a bit. I would like to see radius as one of several supported template languages, alongside mustache, liquid, markdown and textile.

3. Is radiant really needed? Refinery is doing an adequate job for the full-CMS requirement and there are several developing candidates for the pluggable-CMS-engine role, the best of which currently seems to be Comfy Mexican Sofa (which is clearly inspired by radiant in architecture if not interface).

If this was a commercial project we would have a hard look at radiant's strengths and weaknesses, compare those with its possible future roles and then write a spec for version 2. Then we'd face the really difficult question: can we provide an upgrade path, or is radiant 2 a new creature?

In my never-humble opinion radiant is worth continuing but only in a thoughtful way. It needs proper documentation, a slim new test suite, a decent website, a clear mission and a willingness to discard old habits that are no longer beneficial. Without those, no point. With those, it could be very useful indeed.

If we can sort out the strategy, I'm happy to give the staff time.

best,

Will

--
Radiant CMS Dev Mailing List
Post:        radiant...@googlegroups.com
Unsubscribe: radiantcms-de...@googlegroups.com
Group Site:  http://groups.google.com/group/radiantcms-dev/

__________________________

 

William Ross

Director, Spanner Ltd

wi...@spanner.org

wrross on Skype, wrr...@me.com on iChat 

Office: +44 1229 588098

Mobile: +44 7771 562745

[Jim Gay]

On Tue, May 1, 2012 at 4:16 AM, William Ross <wi...@spanner.org> wrote:
> On 1 May 2012, at 03:08, Jim Gay wrote:
>
> I forgot to mention this: I'm doing what I can to drop dataset. It's a
> test dependency that seemingly noone else uses and I have no desire to
> maintain it myself.
>
>
> Good plan. It's a nice syntax but we're on our own there.
>
> Agreed about users too, but layouts I think we need to keep. I've been
> trying different approaches to the embedded CMS and I find you often need an
> intermediate wrapper between the application layout and the managed content.
> These days I think of layouts as a way to keep page editing simple enough
> for users.

I think there should be hooks for layouts, but there's no need to
require that they be in the database. The bare-bones feature of
Radiant is to manage content and rendering it is almost secondary. The
current strategy for rendering is very specific. What if I like
Radiant but know that I will only really need a single layout and
using a file, checked into my source control, is the best thing for my
project?
I think Page should provide a layout method, but the actual database
requirement should be broken out into a different extension.
Page already has this concept anyway: if there is no layout, it just
renders the body.

>
> I am strongly in favour of a test rewrite, too: they're far too integrated,
> as you say, they take too long and rspec under rails 3 is a much nicer place
> than it used to be. Slimming down the tests would force us to describe a new
> API.

If EVERYONE is on board with that, great, I'm all for it. But we've
been moving slowly and "the big rewrite" can be seriously bad news for
continuing the project with any momentum. My current approach is to
just get it working in Rails 3. That's a big enough challenge in and
of itself without major rewriting just to refactor.

I believe that we'll be better served by Page not being an
ActiveRecord model at all, but I'm not going to tackle that yet
because then I'd be starting from scratch.

>
>
> I have been working on rails engines of different kinds for other projects
> and I'm nearly ready to start working on this, but I have three big
> questions:
>
> 1. what is the place of a radiant extension in this new ecosystem? I think
> it goes two ways: the bigger extensions like event_calendar or taggable are
> pushed out to engines. They can interact with radiant through a published
> API. The smaller ones like mailer and dashboard remain as functionality
> patches and a nursery for new approaches.
>
> 2. how much does radiant === radius? Personally I've come to loathe radius
> and its baroque opacity but I think that's more because of the way I have
> abused it than from any fundamental quality. It's very good at the basic job
> of mentioning pages on other pages, but too slow and clumsy for anything
> else and I wonder whether we should strip it back a bit. I would like to see
> radius as one of several supported template languages, alongside mustache,
> liquid, markdown and textile.

I think we can make the tag system more pluggable...
I have rewritten the <r:content> tag to use an object instead of a
giant procedure and plan to merge that in and continue with ALL of the
rest of the tags. Altering the behavior of a tag would then only
require the alteration of an object's behavior and not the complete
rewrite of a procedural method.
But again, first things first, Radiant doesn't run on Rails 3.

>
> 3. Is radiant really needed? Refinery is doing an adequate job for the
> full-CMS requirement and there are several developing candidates for the
> pluggable-CMS-engine role, the best of which currently seems to be Comfy
> Mexican Sofa (which is clearly inspired by radiant in architecture if not
> interface).

For existing Radiant projects, yes. For the future, yes! There are a
lot of great things we can do with Radiant and I plan to do them. And
of course, steal great ideas from others along the way.

>
> If this was a commercial project we would have a hard look at radiant's
> strengths and weaknesses, compare those with its possible future roles and
> then write a spec for version 2. Then we'd face the really difficult
> question: can we provide an upgrade path, or is radiant 2 a new creature?
>
> In my never-humble opinion radiant is worth continuing but only in a
> thoughtful way. It needs proper documentation, a slim new test suite, a
> decent website, a clear mission and a willingness to discard old habits that
> are no longer beneficial. Without those, no point. With those, it could be
> very useful indeed.
>
> If we can sort out the strategy, I'm happy to give the staff time.

Radiant is always there. If developers and businesses are willing to
support it, there is nothing stopping that effort.
I'll move my refactor project to a proper branch and we can go from there.