Jim,

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 this extension
http://github.com/saturnflyer/radiant-seo_help-extension/tree/master
which provides an "inherit" attribute on r:meta and adds r:if_meta and r:unless_meta

-Jim

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 comprehension.

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).

-Chris

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 bloat.

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 more thinking.

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? ;-)

-Jim

On May 19, 2008, at 3:34 PM, Sean Cribbs wrote:

Jamey,

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.

Sean

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 part in
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]> wrote:

I'm curious about why r:meta was implemented. Couldn't you get the same result by using page parts and dropping them in the appropriate place in
your layout?
I haven't used r:meta yet, so perhaps I'm unaware of some particular benefit

-Jim

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
the default.

Sean

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
extension.

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 extension.

I the 'tag' attribute (mine was 'as_tag'), I had allowed true | false | unless_blank for the reverse case that Jamey is mentioning. I have sites where I *don't* want keywords to inherit. They need to be explicitly defined or else the page gets none. So, by using the 'unless_blank' option, 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 this would
be helpful.

-Chris

Jamey Cribbs wrote:

First of all, thanks very much to the dev team for all of the latest
release activity.  It is greatly appreciated!

I do have a question about the new metatags fields for keywords and description. These work great, but I noticed that there is no way to set them to inherit (unless I am missing something). It does not look like you can set these fields on a parent page and have the children inherit them. I thought that this would be the desired behavior, but
maybe I am missing something.

Thanks.

Jamey Cribbs
_______________________________________________
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