Mental Branch

Ruby Apps Radiant CMS
1

If you’ve been watching the change logs lately, you might have noticed a
new branch in the repository–the “mental” branch:

http://dev.radiantcms.org/radiant/browser/branches/mental/radiant

It’s basically a place for the core team to play around with a few
architectural changes. The most significant change to date is that we
are experimenting with the idea of axing behaviors and moving to an
inheritance hierarchy for pages:

http://dev.radiantcms.org/radiant/changeset/126

If you have a moment, please download it and give it a try. Perhaps the
bold and daring among you could even convert a custom behavior or two to
page subclasses and tell me how you like the new architecture.

–
John L.
http://wiseheartdesign.com

2

If you’ve been watching the change logs lately, you might
have noticed a
new branch in the repository–the “mental” branch:

http://dev.radiantcms.org/radiant/browser/branches/mental/radiant

It’s basically a place for the core team to play around with a few
architectural changes. The most significant change to date is that we
are experimenting with the idea of axing behaviors and moving to an
inheritance hierarchy for pages:

Duckies!

I was just about to get into radiant work again (well, once I manage to
unpack enough stuff to actually be able to do anything - moving house
sucks), and it’s nice to see that I can throw away the majority of my
‘on crack’ changes and just take this branch to start off again.

The big reason that I was trying to push for this change was to be able
to introduce activerecord associations to the subclassed behaviors and
then modify the admin display for those behaviors.

To do this you’d need the following hooks into the admin interface to:
- modify the rendering of the page editing (mainly add new
fields, but maybe hide away/rearrange the existing fields?)
- intercept the saving process (to convert fields to
associations and verify those associations)

Looking over the plugin proposals, I’m not quite sure what the best way
to go about this is. The second part can probably be done just with
activerecord validations and extra methods on the behavior, though that
might be mixing the model with the view a bit. The modification of the
page editing might be achieved by something like:

def activate
routes.my_route “my/route”, :controller => “my_controller”, :action
=> “my_action”
admin.pageviews.add “My Handy Dandy Page”, “_my_page_view_partial”
page_classes.activate “My Handy Dandy Page”
end

Also, if behaviour pages have possibly different validations/fields,
then the PageController will need to make sure that it’s got an instance
of the correct class before it does an update.

I’ll hopefully be able to dive back in and explore this myself in a
couple of weeks, but I thought I’d get it out now before it slips my
mind. How do you see these ideas fitting in with the plugin model?

3

Daniel S. wrote:

The big reason that I was trying to push for this change was to be able
to introduce activerecord associations to the subclassed behaviors and
then modify the admin display for those behaviors.

Yup, this is a huge benefit the new model.

To do this you’d need the following hooks into the admin interface to:

  • modify the rendering of the page editing (mainly add new
    fields, but maybe hide away/rearrange the existing fields?)

I would like to eventually support this, but it’s probably not going to
be part of the initial plugin system.

  • intercept the saving process (to convert fields to
    associations and verify those associations)

This shouldn’t be difficult to support.

page_classes.activate "My Handy Dandy Page"

end

That looks useful. I was thinking to leverage partials for this as well.

Also, if behaviour pages have possibly different validations/fields,
then the PageController will need to make sure that it’s got an instance
of the correct class before it does an update.

True enough. It does open up a whole other level of complexity.

–
John L.
http://wiseheartdesign.com

4

Ollivier,

I intend to make Commentable into a page type with model(s) soon, but
I’m
kinda bogged down right now with other projects.

Sean C.
seancribbs.com

5

On 9/28/06, John W. Long [email protected] wrote:

Yup, this is a huge benefit the new model.

So, is this going to become the new trunk at some point? I’ve been
tracking it through svn/hg and it works fine… I’ve not modified any
behaviour^Wpage types so for me there is no difference yet.

[to all]
Are there any plan to update/rewrite the current Third Parties
behaviours into page types?

6

On 10/10/06, Alexander H. [email protected] wrote:

I would think that is the responsibility of the maintainers of Third
Party page extensions.

Agreed and that’s why it was addressed to all :slight_smile:

Now, for people to do that, the branch must gain some kind of status
like “this is where we want to go in the future” even though it is
still experimental.

Have you had time to track the Corex branch? It has some improvements
to page extensions.

I don’t check all the branches in the svn tree so no, I didn’t know it
existed.

The website is still down BTW, any news on that?

7

Now, for people to do that, the branch must gain some kind of status
like “this is where we want to go in the future” even though it is
still experimental.

Point granted. As soon as John has come back and has settled in again
we should see what our roadmap should look like to incorporate some of
the changes that have been made over the last month. You will find
some pretty significant improvements to the core (check the “corex”
branch; see below).

Have you had time to track the Corex branch? It has some improvements
to page extensions.

I don’t check all the branches in the svn tree so no, I didn’t know it existed.

I have tried to keep you guys up-to-date with my Annotated Changelogs
(
http://lists.radiantcms.org/pipermail/radiant-core/2006-October/thread.html
). I have sought feedback on the IRC channel as well. Maybe we just
missed each other on those occasions. I hope we can work together on
this more.

I am happy to answer any questions you guys might have regarding the
“corex” branch. Please feel free to comment on any issues or quirks
you encounter. An overall list of changes in the “corex” branch can be
found here: http://alxh.blogspot.com/.

–
Alexander H.
http://www2.truman.edu/~ah428

8

[to all]
Are there any plan to update/rewrite the current Third Parties
behaviours into page types?

I would think that is the responsibility of the maintainers of Third
Party page extensions.

So, is this going to become the new trunk at some point? I’ve been
tracking it through svn/hg and it works fine… I’ve not modified any
behaviour^Wpage types so for me there is no difference yet.

Have you had time to track the Corex branch? It has some improvements
to page extensions.

On 10/10/06, Sean C. [email protected] wrote:

On 9/28/06, John W. Long [email protected] wrote:
Ollivier R. -
Radiant mailing list
Post: [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site:
http://lists.radiantcms.org/mailman/listinfo/radiant

–
Alexander H.
http://www2.truman.edu/~ah428

9

On 10/10/06, Alexander H. [email protected] wrote:

I am happy to answer any questions you guys might have regarding the
“corex” branch. Please feel free to comment on any issues or quirks
you encounter. An overall list of changes in the “corex” branch can be
found here: http://alxh.blogspot.com/.

Any plan to have an RSS feed of svn changes? I have it on TextMate and
other
software I’m following and that would be nice to have.

Thanks,

10

On Oct 12, 2006, at 10:40 AM, Ollivier R. wrote:

On 10/10/06, Alexander H. [email protected] wrote:

I am happy to answer any questions you guys might have regarding the
“corex” branch. Please feel free to comment on any issues or quirks
you encounter. An overall list of changes in the “corex” branch
can be
found here: http://alxh.blogspot.com/.

Any plan to have an RSS feed of svn changes? I have it on TextMate
and other
software I’m following and that would be nice to have.

You can get just the corex feed here:

http://dev.radiantcms.org/radiant/log/branches/corex?
limit=100&mode=stop_on_copy&format=rss

Or a feed with all branches here:

http://dev.radiantcms.org/radiant/log/?
limit=100&mode=stop_on_copy&format=rss

Thanks,
Wes

11

On 10/10/06, Alexander H. [email protected] wrote:

Have you had time to track the Corex branch? It has some improvements
to page extensions.

Any migration path from the “normal” radiant? I’ve tried to import my
postgresql
data and corex fails with several errors like “content” tag unknown and
others.

Thanks,

12

On 10/12/06, Ollivier R. [email protected] wrote:

On 10/10/06, Alexander H. [email protected] wrote:

I am happy to answer any questions you guys might have regarding the
“corex” branch. Please feel free to comment on any issues or quirks
you encounter. An overall list of changes in the “corex” branch can be
found here: http://alxh.blogspot.com/.

Any plan to have an RSS feed of svn changes? I have it on TextMate and other
software I’m following and that would be nice to have.

Trac has this:

http://dev.radiantcms.org/radiant/timeline

Tweak to taste and subscribe.

-Tom

13

Any migration path from the “normal” radiant? I’ve tried to import my
postgresql
data and corex fails with several errors like “content” tag unknown and others.

With the creation of the branch I removed the old migration scripts
because I could not get Postgresql to work with these legacy
migrations. This change is only temporary but it means that you
currently cannot migrate your 0.5x data to the “corex” branch. Most
likely though, you current pages probably rely on Archive and other
behaviors anyway. Since those behaviors haven’t been ported yet I
decided the migrations are not on the top of the to-do-list.

But don’t despair. When you create a “pristine” copy of “corex” you
will be prompted as part of the migration procedure on what YAML file
you would like to import. Choose [2] and you’ll get the basic page
layout. I hope this helps.

–
Alexander H.
http://www2.truman.edu/~ah428

14

On 10/12/06, Alexander H. [email protected] wrote:

migrations. This change is only temporary but it means that you
currently cannot migrate your 0.5x data to the “corex” branch. Most

OK.

likely though, you current pages probably rely on Archive and other
behaviors anyway. Since those behaviors haven’t been ported yet I

Except for Archive which I just started using, I don’t rely on any
behaviour and no third-party one anyway so I expected to be easy. But
the first error I got is “content: tag unknown”… The real home page
of the site has several parts and I use this code:

<r:children:each by=“slug” order=“asc”>

-----

so you tell me this does not work anymore?

But don’t despair. When you create a “pristine” copy of “corex” you
will be prompted as part of the migration procedure on what YAML file
you would like to import. Choose [2] and you’ll get the basic page
layout. I hope this helps.

I will look at that.

15 
<r:content part="left" />
-----

Make sure the page type is StandardPage. That is, if you want to use
the standard tags (such as <r:content>, <r:children> … etc.) you
need to select in the admin interface the “Page Type” called
“Standard.”

Of course, you might have run into the problem that ArchivePage is a
subclass of Page (not StandardPage). If you want a “behavior” (let’s
call it
“page extension” that’s a better term) have access to the standard
tags you need to subclass StandardPage. In the case of ArchivePage the
class definition might look like this:

class ArchivePage < StandardPage
…
end

On 10/12/06, Ollivier R. [email protected] wrote:

behaviour and no third-party one anyway so I expected to be easy. But

> you would like to import. Choose [2] and you'll get the basic page

–
Alexander H.
http://www2.truman.edu/~ah428