On 29-Oct-08, at 7:21 AM, Josh French wrote:
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).
Andrew and I have been discussing this, and he raises a good point:
"if we make the data accessible to tags (other than conditionals),
these metadata do start acting more as parts/content." Over the
weekend, the sprinters had a long debate regarding the use of these
page attributes and how they differ from page content, and I think
the resolution was that attributes should be used as filters, or to
trigger behavior on individual pages, but stop short of being
treated as content. To that end, I am envisioning a set of tags that
acts on attribute _types_ rather than attribute content, e.g. a
conditional tag for booleans; if_before/if_after for datetimes; and
so on.
There are some things you can do to prevent this from being abused
(clearly its only an issue with strings), namely normalize the
strings. Not fool proof but doable.
We use it largely for conditionals as well.
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.
My inclination is to follow Radiant convention, unless someone can
convince me otherwise. (I'm a pushover, so have at it.)
In some ways its a matter of style. In our world (which is a rather
complex business environment) its a HUGE time/cost/complexity saver so
I figured I'd share the idea.
If I set a
"masthead_image" attribute on page /products/widgets to "widgets.gif"
then every page in /products/widgets gets that value
To me, this suggests the possibility of (ab)using attributes as
foreign keys (e.g. to an asset stored in another table) as opposed
to literals. We wrote an extension for a client that attempts to
automagically draw some associations based on introspecting a schema
similar to what we're using here, and I still have nightmares about
dark things shuffling forth from join tables. So it's not something
I was planning on attacking on this first pass, but I definitely see
a strong use case for it and if anyone has a strong pattern for
accomplishing this, I'd love to hear about it.
Again, this may be a difference between Radiant and my world. We don't
use a database for anything so there is no foreign key to abuse.
Everything is encoded in plain old JSPs and everything we refer to
like this is a JSP or a bare resource (like a gif).
Adam
j
_______________________________________________
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
