Where I work, I designed our system such that we have an in-memory
representation of all the nodes in our site which was (somewhat)
independent of the index.jsp that defines the node. We hang a lot of
metadata off these nodes, a lot of which is inferred. This lets us do
things like have a multilingual site (simply create index.jsp and
index_fr.jsp or index_xu.jsp) and so on. One of the most useful idea
we included (at least in so far as this thread is concerned) is the
idea of node parameters. These parameters are name/value pairs
associated with a node and can be used for absolutely anything you
want (the list of parameter names is arbitrary). The useful bit is
that when you define the parameter, you can say if its inherited no
not. This is sort of the opposite of how this sort of thing is done in
radiant where its the usage of something (a page part or a meta) that
specifies if its inherited, I specify that at definition.
This has a big advantage: sparse population. This lets me set a
default on some node (say the root) and have it inherited. I can then
change it for some descendant (so far no difference). However, if I
want that change to ONLY affect that one page and not its parents,
setting the value to being "local" (not inherited) means that the
original value will be used for the children of the page that
overrides the value. Since we use these value for more than merely
creating HTML Meta tags, this becomes very useful.
i would suggest that in addition to tests to see if meta is set (or
not) that you include tests for the value. This will allow for some
very interesting behaviour.
On 22-Aug-08, at 9:56 AM, Jim Gay wrote:
I'm resurrecting this thread so that I can express my personal
hatred of the meta tags.
I propose that they be removed, or handled in a different way (and
yes I volunteer myself to write the code for it).
I'll be doing some thinking about <meta> and how to better handle
the many options for HTML, but if anyone is interested, I created
which provides an "inherit" attribute on r:meta and adds r:if_meta
On May 19, 2008, at 4:13 PM, Chris Parrish wrote:
I can't speak for the core team but I wrote my own extension to do
the same thing for clarity and simplicity in the UI. Page parts
are for the page content (body) and the the other fields are for
meta-data (kind of like HTML's <head> vs. <body>). It could be done
without (for Radiant or HTML) but is nice for organization and
But you are right -- it's all just data. In fact, Radiant could
move the slug, breadcrumb -- any field really -- into a page part
and it would still be workable.
my $.02 (though probably overpriced).
On May 19, 2008, at 4:02 PM, Jim Gay wrote:
Given the debate about how to implement an "inherit" functionality
for something that already exists with r:content, I'd say this is
I think there is a benefit in the user interface though, to have a
text field rather than a text area to manage a small amount of
content so I could be persuaded to leave it in for that reason. But
I think that another option there might be to simply create a new
way to add page parts in text fields near the title area (I don't
recall what shards calls it). Add a part as a big text area in the
tabs or add it as a text field. They could be functionally the
same, but depending on the scenario they encourage (or discourage)
a user in entering a certain amount of text.
I use page parts on the home page, for example, to allow users to
alter things like the footer text on their site. Adding "Copyright
2008 Super Happy Funtime Inc." in a big text area isn't ideal
(because of the size of the text vs the size of the area given) but
it does the job. And it easily is inherited on every page.
I recall seeing the request for r:meta on Trac a long time ago and
just figured it wouldn't be added.
I think, however, that something like a "truncate" attribute makes
sense even for both cases... You can have users fill out a
description part, or just use the first 50 characters (for example)
of the body and use that in your meta tags. This would of course
cause problems with HTML being entered so that would take a little
Having said all of that, I don't think its a major detriment that
it exists, but I don't think it is necessary and probably shouldn't
exist in the future.
Should I feel out of place in this conversation since my last name
isn't Cribbs? ;-)
On May 19, 2008, at 3:34 PM, Sean Cribbs wrote:
That's great. In response to Jim, it was a common enough use case
for people who do SEO for their sites and such a low overhead to
implement, it seemed like a reasonable thing to add. I'd
appreciate debates on this matter, however, as I'm open to culling
superfluous code from the core.
Jamey Cribbs wrote:
I just implemented what Jim suggested in my project and it works
great. I created a meta_keywords and a meta_description page
the pages that I want the tags. The nice thing is that you can use
the inherit="true" parameter.
On Mon, May 19, 2008 at 11:52 AM, Jim Gay <[EMAIL PROTECTED]>
I'm curious about why r:meta was implemented. Couldn't you get
result by using page parts and dropping them in the appropriate
I haven't used r:meta yet, so perhaps I'm unaware of some
On May 19, 2008, at 11:47 AM, Sean Cribbs wrote:
Personally, I'd like to see inheritance of meta info be
optional and not
Chris Parrish wrote:
I just wanted to mention that I just noticed this change and
am glad to
see it implemented in core as well. It eliminates the need
for my page_meta
I too, like the inheritance idea (an optional attribute of the
tag) but I
would also like to see a feature I had implemented in my
I the 'tag' attribute (mine was 'as_tag'), I had allowed true
| false |
unless_blank for the reverse case that Jamey is mentioning. I
where I *don't* want keywords to inherit. They need to be
defined or else the page gets none. So, by using the
I was able to prevent the page from kicking out an empty set
of <meta> tags.
I'd be happy to write up a patch for this if others think that
Jamey Cribbs wrote:
First of all, thanks very much to the dev team for all of the
release activity. It is greatly appreciated!
I do have a question about the new metatags fields for
description. These work great, but I noticed that there is
no way to
set them to inherit (unless I am missing something). It does
like you can set these fields on a parent page and have the
inherit them. I thought that this would be the desired
maybe I am missing something.
Radiant mailing list
Radiant mailing list