# Radiant + ACL + Portlets + 1.0 **URL:** \ **Category:** Radiant CMS\ **Created:** [December 3, 2007, 5:09pm UTC](https://www.ruby-forum.com/t/radiant-acl-portlets-1-0/121985 "2007-12-03T17:09:34Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Erik\_Nijkamp](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/97f17d/32.png) [@Erik\_Nijkamp](https://www.ruby-forum.com/u/Erik_Nijkamp)\ **Post date:** [December 3, 2007, 5:09pm UTC](https://www.ruby-forum.com/t/radiant-acl-portlets-1-0/121985/1 "2007-12-03T17:09:34Z")
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 ---
**Author:** ![Erik\_Nijkamp](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/97f17d/32.png) [@Erik\_Nijkamp](https://www.ruby-forum.com/u/Erik_Nijkamp)\ **Post date:** [December 3, 2007, 5:43pm UTC](https://www.ruby-forum.com/t/radiant-acl-portlets-1-0/121985/2 "2007-12-03T17:43:04Z")
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 - \ and \ 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](http://wiseheartdesign.com) ---
**Author:** ![Erik\_Nijkamp](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/97f17d/32.png) [@Erik\_Nijkamp](https://www.ruby-forum.com/u/Erik_Nijkamp)\ **Post date:** [December 3, 2007, 5:50pm UTC](https://www.ruby-forum.com/t/radiant-acl-portlets-1-0/121985/3 "2007-12-03T17:50:41Z")
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)