David M Johnson wrote:
On May 3, 2006, at 4:17 PM, Allen Gilliland wrote:
The above is what is currently proposed on the wiki and is a viable
option, but after a discussion with some of the guys from Technorati
and poking around a bit on the web I think there are some good
alternatives to consider.
/<weblog>/entry/<YYYYMMDD>/<anchor>
/<weblog>/entry/<YYYYMMDD>/?category=<cat>&page=1
/<weblog>/entry/<YYYYMM>/?category=<cat>&page=1
/<weblog>/entry/<YYYY>/?category=<cat>&page=1
The structure shown above seems to be used on a number of sites and
has some noticeable advantages and disadvantages. MT (typepad,
livejournal) and blogger use this except they omit the day from the
url and only support YYYY/MM.
pros:
- date becomes part of the standard link, which makes it easy for
users to hack at the url and know what to expect.
- we can actually calculate next/prev year, month, and day from the url.
cons:
- if someone modifies the pubtime of an entry then the permalink
changes :(
- we have to additionally validate that the url date matches the
entry date for permalinks.
I'm don't like using the word "entry" in the URL to a page that will
include a page-able collection of entries. I guess we could use the
word "archive" or "blog" instead, since it does not imply singularity
or plurality. Maybe "entry" and "entries" is the ticket; that's what I
used in the Atom protocol URLs.
I agree, using "entry" in the link if it were to include the date as
well doesn't make a whole lot of sense. However, if we do go this route
I think we should use a word that indicates something relevant to the
content contained within.
Also, I don't understand why we need a date in the entry permalink.
We don't *need* it, but if it helps make the urls more functional then
it is worth considering. If you look at other blog sites like typepad,
livejournal, and blogger, they all do it that way. That doesn't mean it
is right of course, but it's worth thinking about.
So, why not do something like this:
/<weblog>/entry/<anchor>
/<weblog>/entries/<YYYYMMDD>/?category=<cat>&page=1
/<weblog>/entries/<YYYYMM>/?category=<cat>&page=1
/<weblog>/entries/<YYYY>/?category=<cat>&page=1
if we do that then i suggest we do ...
/<weblog>/entries/date/<YYYYMMDD>/
/<weblog>/entries/category/<category>/
and technically we can add on to that, like ...
/<weblog>/entries/tag/<tag>
however, now that i look at it, why not just drop the "entries" part and
consider that implied? that keeps the urls even shorter.
i have wavered back and forth about wether or not to allow these path
based versions of the entry collection views and i think by biggest hang
up is on the issue of url redundancy. what we could do is offer path
based urls for entry collections that only specify a single criteria,
like date, category, etc. then we could continue to allow the weblog
homepage to support an arbitrary number of url query params to allow for
views that refine by multiple criteria. i.e.
/<weblog>?date=<YYYYMMDD>&cat=<category>&tags=<tags>&page=3
but the software would promote these urls ...
/<weblog>/date/<YYYYMMDD>
/<weblog>/category/<category>
/<weblog>/tag/<tag>
none of those urls would allow for restriction by an additional criteria.
Then use a similar structure for "custom" pages, since they also need
date, category, etc.
/<weblog>/page/<page-link>?category=<cat>&page=1
/<weblog>/page/<YYYYMMDD>/<page-link>?category=<cat>&page=1
/<weblog>/page/<YYYYMM>/<page-link>?category=<cat>&page=1
/<weblog>/page/<YYYY>/<page-link>?category=<cat>&page=1
I think for the user defined pages that we should stick purely with
query params mainly because we have no reason to suspect that user
defined pages are mostly concerned with those criteria. I think we will
want to allow the user defined pages to have access to any query params
they want to use.
-- Allen
- Dave
