On 2/22/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
Dave wrote:
I would add that the only thing that kind of sucks about that is that
expecting most users to understand content types is a bit of a stretch
in my mind. So the benefit of the current solution where we just lookup
the content type based on the file extension used in the "link" value of
the template is that it keeps things simple for users.
Having to see a field marked "Content Type" with a value of "text/css"
on the template editing form for a css template may cause more problems
than it will solve. If people start to hack at it without knowing what
they are doing then they can break things.
That's true and so we'll have to be careful how we expose it in the
UI. For example we might want a combobox with options like:
Web page (text/html)
CSS file (text/css)
Custom...
Where custom leads to popup that allows a custom content-type. That
could even be hidden away in an advanced settings area similar to
those on the edit-entry page.
So we may want to ask how often we think people need to create custom
templates where they need to set a custom content type which can't be
accomplished by using a file extension?
Content-type is the standard and "right thing" to do here. You can't
rely of file extensions in general and I've got specific problems with
them. I'm creating pages that generate feeds so I need
application/xml+rss and application/xml+atom. And I need
application/json for JSON. My ISP controlled server is not setup to
map .atom, .rss or .json so file extensions are useless to me and I
think that's a pretty common situation for bloggers.
- Dave
