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 :-)
> 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
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
<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
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
Radiant mailing list