David M Johnson wrote:
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.
Right. I wasn't saying that we need that stuff in the permalinks for
any reason. I am merely asking the question, "other big blog sites do
it, so is there a reason we should too?"
*snip*
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.
Right. So the idea is that most of the time users aren't going to need
to view entries constrained by multiple criteria, so we can provide some
nice, short, simple, path based, and easily indexable urls for these
views. Then for the more rare cases where someone does want to view
based on numerous criteria then they just have to use the query
parameter version.
As far as I can see the only possible downside is that we can end up
with 2 urls to the same page ...
/<weblog>?cat=<category>
/<weblog>/category/<category>
None of the software will promote the query param version, but
technically it will be there and work. That's probably not that big of
a deal though.
-- Allen
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
