Re-Introducing: Page Attributes, Templates, ContentFromTempl

Greetings,

I am please to announced that I recenly came into possession of some
extra free time. And would like to tell you all about what I’ve been
up to with Radiant.

The Short Story:
demo: http://demo.kupenda.org/admin (user/pw = demo/radiant)
svn: http://208.78.96.155/svn/radiant_kupenda/trunk/radiant/
I need your help to make this into an extension!
http://dev.radiantcms.org/radiant/ticket/508

The Long Story:

I recently left my job as a software engineer at a “Professional
Services” organization. One of the main things we did there was
customize and deploy an in-house Java CMS for our clients. It wasn’t
very good, but the one thing it did have going for it were Content
Item types. For example: If you had a Jobs section on you website,
you would be able to create new Job-typed content. Instead of getting
just a title and single WYSIWYG content area, you would also get some
relevant fields to fill out like “date posted”, “manager’s name”
etc… Or maybe you would even be able to upload a PDF and attach it
to this Job Posting. The important thing was that the screen you saw
for creating a job looked different than the one you used for a
creating a normal page, it was customized specifically for Job
editing/creation.

The problem with creating this customization, was that it required the
developers to manually edit XML configuration files, create additional
database tables, write Servlets and Table-wrapping classes, etc,
etc… i.e. it wasn’t easy enough.

So I saw radiant and thought: Structuring a piece of content in Page
Parts is sorta-like structuring your own content item type for each
page. Although, you can only structure html content, you can’t
structure things like uploads, links, dates, strings, etc…

So I create Page Attributes. I added a tab to the Page editing
interface, and made it possible to create new attributes on a
particular page. (And then you can of course reference these
attributes with appropriate tags)

So this gave me the flexibility to create well-structured content, but
it exposed too much of that structure and gave too much power to
Content Editors who shouldn’t be allowed to change the structure.

The solution to this problem, was to create a second Tab in the admin
JUST for content. Content Authors wouldn’t be able to add or remove
parts or attributes they would just be able to change the values of
existing ones. And they wouldn’t be able to add or delete pages
either. Also, Content authors could only change the contents of page
parts that were specifically marked as editable by them (“[X]
template”).

Of course, this is too far, Content authors SHOULD be able to create
content, they just need some restrictions. They should only be able to
create content of specific pre-defined types. (like the Jobs-typed
content item)

Thus, 2 new pages types:
TemplatePage – a page that can be used for the basis of creating
new pages
ContentFromTemplatePage – a page created by a Content Author
based on a TemplatePage, pre-populated with all the needed parts and
attributes.

To further facilitate this process I gave all pages an attribute of
“inherits from page”. When a new ContentFromTemplatePage is created
it’s set to “inherit from” the Template it was created from. This
allows layout-oriented non-editable page parts to remain in the
TemplatePage, and when edited to affect all relevant
ContentFromTemplatePages.

So now the Content Admin was setup so that you can create new pages
anywhere there’s a TemplatePage to create on from. And you can delete
pages only if they are ContentFromTemplate pages.

This sort of setup allows the technical developer and the
non-technical content author to find a balance between who has control
over what. If a content author wants to edit or change something that
is beyond their control, the developer can enable or create a page
part just for that particular piece of content. It’s all about
finding a balance for this user in terms of giving them just enough
control to do what they want to do, without adding anything extra that
would confused or frustrate them.

So anyway, I’ve released a public demo of what I’m describing (see
above), which is basically a dump from the live site www.kupenda.org
in which I as the developer am actively working with the content
author (Kupenda’s founder) to provide the best possible
most-customized content editing interface.

Absolutely no ruby code was written to customize this structure
specifically for Kupenda. It’s all possible through the admin with
attributes, page types, and the additional tags.

So now I need your help, and your voice, to make the Core Radiant
extensions system capable to handling the modifications I’ve made. I
don’t think they had what I’m doing here in mind when they created the
extensions system. Please take a look at what I’m trying to
accomplish in: http://dev.radiantcms.org/radiant/ticket/508

This is only going to become a real extension if people are willing to
help make it happen.

thanks,

Jacob

On 06/06/07 04:39 PM, Jacob B. was heard to say:

Thus, 2 new pages types:
TemplatePage – a page that can be used for the basis of creating new pages
ContentFromTemplatePage – a page created by a Content Author
based on a TemplatePage, pre-populated with all the needed parts and
attributes.

Hi Jacob:

This looks interesting, good job. I am wondering how many
changes/mixins are necessary to the Radiant base system to make it
work or is most of it encapsulated in separate classes? A diff of your
SVN against Radiant trunk looks like you had to change a lot to make
it work. I am interested as I would like to adapt your page types as
generic content classes for my abstract content model branch of Radiant.

I am certainly looking forward to the extension.

Cheers,
Oliver