RFC on GitHub Issue #322 (copied)
Sam Whited
(https://github.com/radiant/radiant/issues/322), and attached a patch
containing both fixes (https://gist.github.com/1935006). Any comments,
suggestions, etc. would be appreciated.
---- BEGIN ISSUE ----
Radiant defines two Radius tags for rendering dates, `<r:date />` for
outputting generic dates using Ruby's `strftime` and `<r:rfc1123 />`
which always outputs RFC-1123 formatted dates.
r:date has two attributes, `format`, and `for`. The for attribute
allows the user to select between the current datetime, the datetime
when the page was published, or the datetime when the page was last
updated.
r:rfc1123 however, has no such functionality. Which means if the user
wants to get the current datetime in RFC-1123 format, they must use
the r:date tag, and write a format string for RFC-1123.
The functionality of these two tags feels either incomplete, or redundant.
I see two possible fixes for this.
1. Allow the r:date tag to accept the string "rfc1123" for the format
attribute, and eventually deprecate the r:rfc1123 tag.
2. Add a `for` attribute to the r:rfc1123 tag that behaves like the
one in r:date.
The problem with the first solution, is that it (sortof) breaks the
point of the format string (or at least makes the code a little less
elegant). While I can't imagine this really being a problem, it just
feels a wrong.
The second solution still requires multiple tags, however, it makes
the r:rfc1123 tag much more useful (especially for RSS feeds with
often contain `<lastBuildDate />` and `<pubDate />` tags).
Implementing both solutions (I feel) is just redundant, however, for
the purposes of illustration, I threw together a quick patch that does
both: [https://gist.github.com/1935006](https://gist.github.com/1935006)
Do people think one or the other solution would be better, or am I
creating a problem where one doesn't exist?
I didn't make this issue a pull request, because I definitely think
only one of these changes needs to be implemented. I'll actually stick
(part of) the patch in my repo and merge it if there's a general
consensus that one or the other should be implemented.
---- END ISSUE ----
--
Sam Whited
pub 2048R/0DBB515F
SamWhited.com
s...@samwhited.com
404.492.6008
Georgia Tech Research Institute
Cyber Technology and Information Security Laboratory
Secure Information Systems Division
sam.w...@gtri.gatech.edu
Georgia Institute of Technology
Physics Undergraduate
swh...@gatech.edu
Jim Gay
I keep coming back to the idea that the locale file is sufficient here.
If we update the standard radiant locale file, we could add a entry
for dates rfc1123
While that would hide details and potentially make things more
difficult to find (because you'd need to know more about what formats
you could use) I think that points to 2 other problems.
1) Building feeds should be easier. I'd like to see a feed builder
extension/feature that allows you to select a type (atom, rss, etc)
and select some pages and it generates the radius for you.
2) Getting information about tags should be easier. We should have an
interface that allows you to discover more about what options are
possible with tags. The translations for tags are just big strings.
It would be better to have a string for a description, but provide
details about what options are available for the attributes and their
arguments.
--
Write intention revealing code #=> http://www.clean-ruby.com
Jim Gay
Saturn Flyer LLC
571-403-0338
Sam Whited
>
> I keep coming back to the idea that the locale file is sufficient here.
> If we update the standard radiant locale file, we could add a entry
> for dates rfc1123
>
The more I look at it, the more I think you may be right. Giving the
format attribute of the date tag two different meanings (format
string, or keyword) is generally confusing, and probably isn't the
best way to solve the problem. At the same time, doing it all in a
config file is confusing and makes it difficult to swap back and forth
between two different time formats.
> While that would hide details and potentially make things more
> difficult to find (because you'd need to know more about what formats
> you could use) I think that points to 2 other problems.
> 1) Building feeds should be easier. I'd like to see a feed builder
> extension/feature that allows you to select a type (atom, rss, etc)
> and select some pages and it generates the radius for you.
Tomorrow I'm planning on having a little hack day with a friend to
throw together a few extensions that a client of ours needs; one of
those is a sort of blogging extension (that would separate out blog
posts or news articles into a separate tab in the admin interface).
Maybe if we find the time we'll try to make it a bit more general, and
support feeds (or put them in a separate extension).
> 2) Getting information about tags should be easier. We should have an
> interface that allows you to discover more about what options are
> possible with tags. The translations for tags are just big strings.
> It would be better to have a string for a description, but provide
> details about what options are available for the attributes and their
> arguments.
That sounds like a great idea, though I'm not sure what the best way
to implement it would be. Definitely something to think about.
Best,
Sam