On May 3, 2006, at 10:30 PM, Allen Gilliland wrote:
Dave: 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.
Since our "anchors" are unique across an entire weblog, there's no
need for date info the permalink URL. It doesn't add any
functionality. It just makes the URLs longer. And, as you mentioned,
it could result in permalinks that change when the date changes.
if we do that then i suggest we do ...
/<weblog>/entries/date/<YYYYMMDD>/
/<weblog>/entries/category/<category>/
So, to enable filtering by date and category, these would also be valid?
/<weblog>/entries/date/<YYYYMMDD>/category/<category>
/<weblog>/entries/category/<category>/date/<YYYYMMDD>
We really don't want to lose ability to filter by both date and cat,
but this is starting to look messy.
however, now that i look at it, why not just drop the "entries"
part and consider that implied? that keeps the urls even shorter.
The shorter the better.
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.
Ah... OK. Now I see where you're going. That "offer path based urls
for entry collections that only specify a single criteria, like date,
category, etc." restriction is a good thing.
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.
That works for me. I think the calendar tag models, which are both
category and date aware, can be easily rewritten to support this
scheme and in weblog and custom pages -- just as they do now.
- Dave
