Interestingly, in one of your later posts, you define “Developer” and
“Designer” separately where “Developer” was working outside of the
Radiant UI (including RoR and DB tasks). And where Developer got into
(x)html or css, the role overlapped with your definition of “Designer”
It kind of made my point.
Actually, that was my post
Anyway, I’d be inclined to keep such a delineation - leaving the lowest
level being content-only. Having a tier for content, a tier for design
and a tier for configuring plugins/extensions (and dipping into Radiant)
and a root tier for user management (and any fundamentals that may
crop up in the future UI).
I’d be quite keen to see a moved from the checkboxes, to a hierarchical
approach. Keeping the potential for extensions to insert new roles, a
weighted inheritance index could be a simple solution:
1 Content
25 Designer
50 Developer
100 Admin/Root
Or, just go granular. A checkbox for every function, with extensions
inserting their own granular function control. Implementation fairly
simple, with a key/value table:
Whatever happens, and I seem to be banging on about this one, Snippets
should be moved to the same level as Layouts. The lowest level (akin to
Content-only) then needs to be feature-stripped further, even perhaps
down to specific CRUD functions.*
Jon.
I’ve already had problems this week - a customer project manager is
having trouble with content management staff making changes to the
snippets (which I fixed with a patch) and with deleting/renaming pages
and page-parts (which I’m lacking a solution for).
The problem here is that some sites use snippets extensively for content
and writers need to create and edit those in order to create pages.
That’s the beauty of snippets, they’re versatile. But like you noticed,
when snippets hold Layout or other design-level content, it gets hairy
because writers have permissions to those snippets.
I once suggested that there could be Page Snippets and Layout Snippets
(or Content Snippets and Design Snippets) but you run into the
complication-factor. At some point we’re sliding down the slippery
slope to WordPress or some other massively-featured CMS.
-Chris
True, the last thing we need is an open-source version of Vignette!!
We could always tag the Snippets with a simple “content only” or
“structural” boolean, and only show those snippets that are appropriate
to the user level? Or perhaps, only show the edit controls for those
that are tagged (allowing users to see the names of the Snippets
available to use in pages)?
Whatever happens, and I seem to be banging on about this one, Snippets
should be moved to the same level as Layouts.
The problem here is that some sites use snippets extensively for content
and writers need to create and edit those in order to create pages.
That’s the beauty of snippets, they’re versatile. But like you noticed,
when snippets hold Layout or other design-level content, it gets hairy
because writers have permissions to those snippets.
I once suggested that there could be Page Snippets and Layout Snippets
(or Content Snippets and Design Snippets) but you run into the
complication-factor. At some point we’re sliding down the slippery
slope to WordPress or some other massively-featured CMS.
I think we need core extensions that handle these problems. Tools like
Drupal and ExpressionEngine of PHP fame handle de-coupled functionality
very well. I think RadiantCMS retains a well-defined code base and
development platform. With that said, I think focus should be shifted to
extension development.
Extensions can provide all the granular functionality and control one
would need. The Page Group Permissions extension definitely is a great
example.
We have core developers for Radiant itself, but I think Radiant could
use some core developers for just extensions. I think the community and
the promotion of Radiant could benefit greatly from that.
I think we need core extensions that handle these problems. Tools like
Drupal and ExpressionEngine of PHP fame handle de-coupled functionality
very well. I think RadiantCMS retains a well-defined code base and
development platform. With that said, I think focus should be shifted to
extension development.
Extensions can provide all the granular functionality and control one
would need. The Page Group Permissions extension definitely is a great
example.
We have core developers for Radiant itself, but I think Radiant could
use some core developers for just extensions. I think the community and
the promotion of Radiant could benefit greatly from that.
What do you guys think?
Good idea. There are still numerous issues I think need to be sorted at
the core, but a lot of functionality could come in the form of bolt-ons.
My only issue, is the complex setup to ensure everything you need is in
one place (unzip some, SVN some more and GIT the rest), and the
complexity with updating multiple projects. How about even deploying
extensions as gems (still doesn’t solve updates, but one step at a
time…) and requiring them in a environment file (like the Rails 2.1
gem handler)?
I’ve got a number of useful tool extensions I’ve built, including text
manipulation (upcase, downcase etc), truncation, redirection and so
forth. Could be persuaded to OS them…
