On 28-Oct-08, at 12:06 PM, Tim Gossett wrote:

On Tue, Oct 28, 2008 at 11:57 AM, Adam van den Hoven <
[EMAIL PROTECTED]> wrote:

This is a brilliant idea. I know because I thought of it first ;). In our
J2EE application we have a similar concept where any page can have an
arbitrary collection of named attributes and we have code that can work with that code. We have a Tag Library that will write out a value of a named
attribute, assume the value of the attribute is the path to a JSP and
include it, and others that let us do conditional logic (if attribute "Foo" has a value of "bar" do this else do that). All of this, I expect, will make
its way into radiant, if it hasn't already.


I agree that the single-dimensional data idea is a great one. Not only is it fantastically scalable, it's also a step toward a fully normalized DB schema
(I'm not a fan of tacking on columns willy-nilly, leaving most of them
NULL). It also makes migrations easier in both directions (up and down).


There is one piece of behaviour that I suspect you haven't implemented, but which turns out to be VERY useful. Right now, page parts are inheritable if the usage of the part says so, which is to say that the Radius tag has an attribute called inherit. In our application, we did it the other way. When I author a page, I get to say whether or not a attribute is inherited or not (and it defaults to inherited). This allows us to set values for a whole section easily (sparse population of data). It works out the same as it currently does with the parts in radiant with one exception. If I set a "masthead_image" attribute on page /products/widgets to "widgets.gif" then every page in /products/widgets gets that value, this is the same. However, I want the "masthead_image" attribute for /products/widgets/legal to have a
value of "pirate.gif" but it only applies to that one page and
/products/widgets/legal/privacy should have a value of "widgets.gif". In our system, we simply flag the attribute on /products/widgets/legal as being "local" and it only applies to that one page, its descendants get their value from its parent. With the current logic, I would have to go in and set the attribute on each child page and if this is something I need for my visual design, a content author is not likely to know to set the attribute unless I tell them but on any sufficiently complex project that will be
difficult to maintain.


Six one way, half a dozen the other. I think that Radiant's current behavior
is the more widely expected default behavior. It's easy enough to set
inherit="true" when needed, and I don't think there's much benefit to
switching it around.

The benefit is being able to sparsely populate data. Where the content author is the person doing the technical admin, its not an issue. but if you have many non-technical authors (a good reason for using a CMS) then sparsely (only where you want things to change) is very beneficial.


--
Tim
_______________________________________________
Radiant mailing list
Post:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

_______________________________________________
Radiant mailing list
Post:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

Reply via email to