My notes/ideas on Page editor extensions

Ruby Apps Radiant CMS
1

I really mean to write this for myself. But if I write it here then
maybe it will be of use to someone else as well.

I’ve been working on moving the additions I made to Corex into
extensions for Mental. I’ve added a lot of functionality (and plan to
add more). To the page edit screen.

I have an idea from an interface perspective.

Imagine a set of tabs aligned vertically along one of the side of this
page edit screen. The main tab contains the existing Page edit screen.
Extensions could add tabs to this page edit screen.

For instance, there might be a tab for using a particular WYSIWYG editor

For instance, there might be a tab to manage comments on the Page being
edited. (as in the case of a blog post) This tab might only appear for
certain page types.

I my case:

There will be a tab to manage all of the Page Attributes of a page:
A Page can have a number of named attributes. There are different types
of attributes such as UploadedFileAttribute, and different tags for
referring to them (i.e. <r:image attribute=“logo”/> would output an
image tag referencing the file that was uploaded as the “logo”
attribute)

There will be a tab for managing which parts of a page are layout
oriented. (contain multiple radius tags) And which parts of a page are
content oriented. (These parts are the parts that a client of an already
setup CMS would be interested in) Also in this tab, you can manage an
attribute called “Inherits from Page”, in which you can select any page
as the parent page. (Not parent as in site hierarchy, but parent as in
template) If a particular tag does not resolve on a particular page.
(i.e. there is an <r:content part=“header”/> but there is no “header”
page part) Then the processor should look for and use a page part from
the “parent” page if it is available. Inherits from page supports 2 new
page types (Selectable from the normal page edit interface).
TemplatePage and ContentFromTemplatePage. A shortcut will be made for
creating new ContentFromTemplatePages based on an existing TemplatePage.
The new page will have only the page parts that were marked as “content
oriented” on the TemplatePage it inherits from.

There will be a tab simply for editing those page parts that have been
marked as content oriented. This tab would be displayed in place of
regular editor tab for TemplagePage typed pages.

This means I intend to submit a ticket with the changes to core to
support an ability for extensions to add these page-editor tabs… if I
ever get around to it…

If anybody else is interested in helping me develop (the code or the
interface) for these half-coded ideas, let me know and I’ll send you my
hacked up version of Corex.

2

page edit screen. The main tab contains the existing Page
edit screen.
Extensions could add tabs to this page edit screen.

I think from a usability point of view, you’d typically not want your
extra options hidden away in an extra tab.

For instance, on articles on my site, there’s an extra exposed ‘Author’
field, as the site contains contributions from a wide variety of people

  • the author field should have the same level of visibility as ‘Title’
    does. I’ve got other fields for selecting the thumbnail image to
    represent the article, which needs to be grouped with the images and
    ‘related comics’ section, as the thumbnail could come from either
    source.

I think the first step needs to be breaking down the existing parts of
the edit page into partials so that the actual edit page itself contains
barely anything except a list of includes. From that point, you could do
a lot of editing of the interface without getting out of step with any
additions to the core features.

Dan.

3

Daniel S. wrote:

I think the first step needs to be breaking down the existing parts of
the edit page into partials so that the actual edit page itself contains
barely anything except a list of includes. From that point, you could do
a lot of editing of the interface without getting out of step with any
additions to the core features.

Can you make a pass at that?

–
John L.
http://wiseheartdesign.com

4

Can you make a pass at that?
Doing so now - it’s pretty much just what I did in my admin_parts
extension.

Dan.

5

Can you make a pass at that?
Checked in. I’ve made the extended_metadata partial accept and array of
other partials to include, and I’m not sure if I should split up the
layout/type/status settings into three separate partials or not.

Also thinking about a possible interface for extensions to use:

admin.page_edit_parts.remove ‘Name’

admin.page_edit_parts.add ‘Name’, ‘partial_name’, optionss

with options:
:after => ‘other_Name’
:before => ‘other_Name’
:within => ‘other_Name’ (to get passed into the
extension as :locals => { ‘partials’ => [‘partial_name’]=)
:locals => {hash of ‘locals’ to be passed to partial}
:pages => [array of page types to render for]

Or, alternatively, the page_edit_pages array could by stored against the
Page type, allowing subtypes to manipulate it.

We might need to figure out where to put the hooks for letting a page
get to the extra params that get passed in - the @page.attributes =
params[:page] call will be able to deal with the simple additions, but
might fall over for more complex ones - I guess we’ll cross that bridge
when we come to it…

Dan.

6

Daniel S. wrote:

I think the first step needs to be breaking down the existing parts of
the edit page into partials so that the actual edit page itself contains
barely anything except a list of includes. From that point, you could do
a lot of editing of the interface without getting out of step with any
additions to the core features.

Can you make a pass at that?

Oh yeah. Liking this one. I’ve actually been thinking about this a lot
lately.

Just so you know John I have an app that needs to store meta tag stuff
like keyword, description, and some other custom fields with each page
– much like Dan does. I suspect this is a common need (except
different folks will need different fields).

Is there any way we can not only make it easy to customize the page edit
template but standardize a way to add basic fields (I’m defining a
“basic” field here as any one-to-one relationship to a page)? A
standard could then allow for things like having your up-and-coming
import/export feature (http://dev.radiantcms.org/radiant/ticket/301)
auto-recognize and import or export these custom fields.

7

Just so you know John I have an app that needs to store meta
tag stuff
like keyword, description, and some other custom fields with
each page
– much like Dan does. I suspect this is a common need (except
different folks will need different fields).

The way I do thinks is have an extension with a custom table
(groggy_article_metadatas), all I need in my page is:

class GroggyArticlePage < Page

has_one :groggy_article_metadata, :foreign_key => ‘page_id’
validates_associated :groggy_article_metadata

delegate :article_type, :article_type=,
:author, :author=,
:feature, :feature=,
:to => :metadata

def metadata
self.groggy_article_metadata ||= build_groggy_article_metadata
end

def after_save
metadata.save
end

end

class GroggyArticleMetadata < ActiveRecord::Base
belongs_to :page
end

(I’m not sure that the after_save is needed - that might have been
paranioa).

Then, in my page/edit page, I can just pick up whether the page is a
GroggyArticlePage and add the normal rails helpers for input.

There might be some call for a ‘metadata’ helper, so that it could be
reduced to just:

class GroggyArticlePage < Page
metadata :groggy_article_metadata, :article_type, :author, :feature
end

(though you could probably even inspect the metadata class to get those
delegate properties without specifying them).

Dan.

8

extension as :locals => { ‘partials’ => [‘partial_name’]=)
:locals => {hash of ‘locals’ to be passed to partial}
:pages => [array of page types to render for]

My admin_parts extension
(http://soxbox.no-ip.org/radiant/svn/extensions/admin_parts) now
implements that interface (with the exception of the :pages option for
now). (anybody that may have been using my admin_parts extension in the
past for some reason, you’ll want to pin to version 121 of my
repository).

My part_attachments extension has also been updated to make use of the
new admin_parts.

Any comments welcome.

Dan.