On 28-Oct-08, at 12:06 PM, Tim Gossett wrote:
Advertising
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
