Radiant + ACL + Portlets + 1.0

Ruby Apps Radiant CMS
1

Hello Developers,

We are planning to use Radiant as groundwork for a commercial project
and decided to ditch j2ee + jsr portlets in favor of rails + radiant.

Would you please inform us about the current status of:

  • ACL
  • User/Group/Role management
  • Authentication
  • Assigning roles to extensions
  • Extensions
  • Portlets: Using extensions as “Portlet” replacement e.g. associating
    extensions with roles
  • Versioning: Using different versions of an extension at the time
  • State: “Maintainence”, “Disabled”, …
  • i18n
  • Localized content
  • Detecting the currently used language (browser)
  • Web-Services
  • Replacing the rails model with a web-service
  • e.g. extension -> controller -> soap/rest web-service -> backend
  • Version 1.0
  • Do you have a schedule?
  • Architectural impact?

Thanks for your time and help!

Best regards
Erik Nijkamp

2

On Dec 3, 2007, at 11:08 AM, Erik Nijkamp wrote:

Would you please inform us about the current status of:

Radiant is really focused on a much smaller domain than what you are
describing below. It’s a content management system designed for small
teams. Extensions are intended to give you that extra 20% of what
Radiant doesn’t provide out of the box, but if Radiant doesn’t do 80%
of what you want already it’s probably not a good fit for your
project. With that in mind I’ll do my best to answer your questions
about the features below.

  • ACL
  • User/Group/Role management
  • Authentication
  • Assigning roles to extensions

Right now the ACL is very primitive and will probably stay that way.
I’m open to suggestions about a way to make it pluggable so that
extensions can swap in their own variation, but it’s probably pretty
difficult to do that right now.

It shouldn’t be that hard to create new roles for the current system.
I’m not sure if anyone has ever done it, but you should be able to add
a question mark method to the User model for the particular role that
you want to use. For example. To add an editor role:

def editor?
…
end

The easiest way to do this is just use Rails’ support for boolean
attributes in a migration:

add_column “user”, “editor”, :boolean, :default => false, :null =>
false

Then in your views you can use:

  • Extensions
  • Portlets: Using extensions as “Portlet” replacement e.g. associating
    extensions with roles
  • Versioning: Using different versions of an extension at the time
  • State: “Maintainence”, “Disabled”, …

Associating an extension with a role is up to the extension author.
You cannot use multiple versions of an extension at the same time.
There is no support for putting the site into a maintenance or
disabled mode.

  • i18n
  • Localized content
  • Detecting the currently used language (browser)

If you need a localized admin interface, the jargon branch might be
worth looking into. Otherwise the standard Radiant solution for
localized content is the language_redirect extension.

  • Web-Services
  • Replacing the rails model with a web-service
  • e.g. extension → controller → soap/rest web-service → backend

I’m really not sure what you mean by this.

  • Version 1.0
  • Do you have a schedule?

Nothing definite. Right now we are trying to get 0.6.5 out the door.
Here’s the tentative roadmap that the core developers are presently
working off of:

0.6.5 - Rspec Refactoring

  • Support for RSpec in extensions (?)

0.6.6 - Restful Refactoring

0.6.7 - Updated Extension System

  • additional support for customizing the UI

0.7 - Full Featured Blogging Engine

  • commenting system for every page
  • additional helps for RSS?
  • tagging for pages
  • search?
  • import scripts for other major blogging engines?
  • support for MarsEdit and other APIs?

0.8 - Assets and Attachments

0.9 - Drag and Drop

  • drag and drop sortable page view
  • <r:next /> and <r:previous /> tags for siblings

1.0 rc1 - Workflow: Version Control and Permissions

  • simple version control
  • additional roles: publisher, ?writer?, ?editor?

After 1.0

  • true multi-lingual support?
  • Architectural impact?

We often make changes that break existing extensions. This is
primarily because monkey patching is the current method for making
core changes to the way Radiant works. If your extension requires that
you fiddle with Radiant internals then it is naturally more brittle
and may break when we update the code base. I’m not sure that there is
much that we can do to fix this problem. We are working to standardize
ways of extending radiant with the extension system, but that is a
work in progress.

–
John L.
http://wiseheartdesign.com

3

Erik,

Radiant may not necessarily be a good fit for your needs. Radiant is
very focused on textual content that is essentially static (i.e. not
customized-per-visitor) and has a very simple administration scheme.
Take into consideration whether your content editors are familiar with
HTML, CSS, etc, as Radiant exposes this almost directly to the editor.
Also consider the size of the editing team and whether they will often
step on each others’ toes when working, as Radiant has no versioning yet
(optimistic locking prevents basic overwrites, but doesn’t save older
versions).

If you’re still considering Radiant, let’s look at your needs.

ACL - There are two “groups/permissions/roles” in Radiant, “developer”
and “admin”. Only admins can view/edit which extensions are installed
and active. Your extension controllers can easily specify who can
access what actions and who can see what tabs. Users may also be
“plain” users, or rather, have neither of the above roles.

Extensions - Please describe in more detail what you mean by portlets.
When I read that word, I think of content “components” that can be
selected and arranged in a page by the visitor. If this is what you’re
looking for, Radiant is NOT portal software, and I suggest you look at
other available options. If you just need to integrate with some
proprietary data services, Radiant extensions can handle the job, but
won’t deliver the “portlet” idea necessarily.

You cannot have multiple versions of an extension installed at the same
time. Why would you want this?

Please describe what you mean by “Maintenance”, “Disabled”, etc. Does
this refer to “portlets”?

i18n - There are already some efforts at internationalizing Radiant.
Search the mailing list for discussions of the “Language Redirect”
extension and other strategies for serving content in multiple
languages. Regarding translating the administration interface, there is
some work done in the “jargon” branch that you may find useful.

Web Service - You could easily create or consume a SOAP API using
ActionWebService. However, the design and implementation of this is out
of my scope of knowledge.

Version 1.0 - We have a rough schedule, yes. However, Radiant is
already successfully being used on many sites (see the RadiantUsers wiki
page), and the core is relatively stable. There is no stigma to using
it pre-1.0. And honestly, I don’t see 1.0 arriving in less than a
year. We have many more hurdles to overcome before then. If you want
1.0 to arrive faster, I suggest you consider contributing well-tested
improvements to the core. While the core team contributes their own
fixes and enhancements, much of the code has also come from the
community.

We cannot predict the architectural impact of 1.0 because it’s not even
on the radar. I can assure you there will be many changes between now
and then, but we will likely have near-complete backward compatibility
or at least a sensible upgrade path.

Hope this helps!

Sean C.
(Radiant core team)