On Wed, Sep 23, 2009 at 2:09 PM, John W. Long <m...@johnwlong.com> wrote: > On Sep 23, 2009, at 1:08 PM, Jim Gay wrote: >> >> That may be the case, but the name of the tag has caused confusion in >> my experience. My typical users (myself included) consider content to >> be text. . . . I'm arguing that the default behavior for if_content >> be more reflective of it's name (checking for content) > > You've definitely given me pause to think here Jim. Your argument about the > name of the tag does carry weight. And I could almost go either way.
Go my way :-) > Here > are my thoughts: > > 1. Preserving the current behavior serves existing users because we don't > introduce a backwards incompatible change. Granted we could write migrations > that would add the appropriate attribute to all if_content tags, but is that > really what people will prefer? Very good point. However, I see this as a bit of a correction, much like the original purpose of this thread: correcting if_url to actually mean the URL. That's a breaking change, but it makes sense. In the case of if_url and if_path, they both serve different purposes and it is (or will be) very clear from the name of the tag what they do. Correcting if_content by adding if_blank could actually add to the confusion (or create it where there isn't any) and it is not apparently clear what those tags do and how they are different. >> 2. if_blank allows for the same behavior, and is almost as intuitive It's intuitive by itself, I agree, but not in the context of having another tag named if_content. And by adding more tags, we're adding more to learn and understand _immediately_. Opinionated default behavior for a tag allows you to get going quickly without the need to learn many tags for different options. Users are likely to get familiar with at tag if it's default purpose is simple and clear and as they become more comfortable, they are likely to pickup on the options available. <r:if_content part="sidebar"> is very simple to understand. After you learn that, you might say, "oh, wow! i can use inherit='true' to check a parent page? cool!" So the path to learning complex things is simpler. >> 3. I would like encourage the use of if_content because it doesn't encourage > people to add a bunch of blank objects to the system I'm not sure I understand what you mean by that last comment. I think it's acceptable, although less desirable, to maintain the current behavior and have only one tag for this purpose. The practice of using a page part called "no-map" is a hack. It gets the job done, but page parts should be used for content, not for page attributes. I've never used this for a client, instead I check the URL in my site maps because having a part called "no-map" requires explanation about what it is, and why when you add content, nothing happens to the page. Even explaining the use of "no-map" to a client/user would make me feel like there should be a more intuitive way to do it, but that I was lazy and just put the burden of understanding on the user. That's why I think that developers who use "no-map" page parts and the like should receive the burden of adding an attribute to their sitemap snippet (which is a trivial task) which would tell the snippet to not check the text of the "no-map" part and instead just check it's existence. At the first big Radiant sprint weekend we discussed the addition of page attributes for doing something like this. A use case for having if_content check for the presence of text would be something like a "Related Links" side bar on a website (with free-form content, not using the related_links extension). Currently, I can create the related links area in the layout which displays some header like <h2>Related Links</h2> inside an <r:if_content> block. If a user has no related links, she can't just leave it blank so that she knows where to put them later. I must train her to delete and recreate the page part. While that is seemingly not that difficult to do, it adds to the complexity of understanding how to manage your content. And by content I mean (and my clients understand that to mean) text. So from their perspective: "Why can't I just delete the links?" There's no good answer to that currently and although this could be solved in an extension (as others have pointed out) this is unintuitive and forces site developers and maintainers to require external resources for something that, by its name, ought to check for actual content. -- Jim Gay http://www.saturnflyer.com _______________________________________________ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
