<?xml version="1.0"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Page comments</title>
		<link>http://www.ssbits.com/home/</link>
		<atom:link href="http://www.ssbits.com/home/" rel="self" type="application/rss+xml" />
		<description></description>

		
		<item>
			<title></title>
			<link>http://www.ssbits.com/snippets/2009/create-a-field-in-page-but-not-it-s-decendents/#PageComment_544</link>
			<description>While this is an effective method of achieving what you suggest, it worries me.

First, you are only really hiding it from the admin pages.  The field is still going to be available on each of the derived classes.  This seems a bit wasteful.

Second, it is a bit of hidden magic, which increases complexity and makes it harder to maintain the software.  Normally one expects fields to be inherited from the parent classes.  This is one of the main reasons to inherit.

Assuming we do actually have control over the Page class, I would feel more happy if one were to move common fields that should be inherited into an abstract parent class, e.g. PageBase, and then have Page derive from this and implement these special one-off fields.  Page types that should not inherit these special fields should then derive directly from PageBase.  In this way the inheritance model is not subverted and the classes are more self documenting without having to trawl through what is going on in getCMSFIelds.

Your inheritance hierarchy would then look a bit like this:

SiteTree
 - PageBase
   - Page
     - NormalPage
   - SpecialPage</description>
			<pubDate></pubDate>
			<dc:creator>RSSName</dc:creator>
			<guid>http://www.ssbits.com/snippets/2009/create-a-field-in-page-but-not-it-s-decendents/#PageComment_544</guid>
		</item>
		

	</channel>
</rss>