<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>
<blockquote type="cite">
<pre wrap="">I'd prefer to see customizable 'machine readable node types' go the way
of the dodo.</pre>
</blockquote>
I agree. The only minor masking that isn't completely evident is in the
URL, for example node/add/machine-content-type. If we are simulating
the machine name change, we'll need to get into aliasing that. Most
everywhere else, we should be able to present the user with a human
readable content type.</tt><br>
<pre class="moz-signature" cols="72">Rob Roy Barreca
Founder and COO
Electronic Insight Corporation
<a class="moz-txt-link-freetext" href="http://www.electronicinsight.com">http://www.electronicinsight.com</a>
<a class="moz-txt-link-abbreviated" href="mailto:rob@electronicinsight.com">rob@electronicinsight.com</a></pre>
<br>
<br>
Darrel O'Pry wrote:
<blockquote cite="mid1156356528.5254.60.camel@localhost.localdomain"
type="cite">
<pre wrap="">On Wed, 2006-08-23 at 10:18 -0700, Neil Drumm wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Jeremy Epstein wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">So, I propose that this be removed and alslo that a hook be created to
allow modules to act when a node type is deleted.
</pre>
</blockquote>
<pre wrap="">-1 to this feature being removed, but +1 to creating a hook to allow
modules to respond to changes to a node type. I have created an issue
for this task:
</pre>
</blockquote>
<pre wrap="">This is a battle I didn't want to fight while getting configurable
content types in core, but it needs to be fought now.
Lets look at places where the machine readable node type is used:
- Database
- PHP code
- URLs
- HTML (id and class attributes)
Here is what I think should happen in each case
Database: databases like numeric keys. I think it would be good to
replace the machine-readable type there with numbers.
PHP code: since there is no exposed UI here (always use the [human
readable] type name), I think the same numbers might work. This is a bit
harder with hard-coded node types, since they have a hard-coded name
that is used. Perhaps the hard-coded name can be recalled and used for
hook invocation where applicable.
URLs: Currently, we have numeric ids scattered in many URLs across
Drupal. I'd like to see this change in the future, but we don't have a
good example of a design pattern that works and we don't have a system
for setting up redirects for changed URLs. I'd like to see a machine
readable name work.
HTML: There were numerous complaints about flexinode using numeric ids,
they are clearly unacceptable here since themeing should not require
knowledge of how the database is set up. They should be machine readable.
Two more questions- should machine readable names be changed and should
they be configurable by users?
Machine readable names should definitely be changed. That does affect
URLs and CSS depending upon HTML. In an ideal world, HTTP redirects
would be set up for changed URLs, but as mentioned earlier, that doesn't
exist at the moment. For CSS, a warning or message should inform users
of what changes are needed.
I've summarized how to make code and the database not care about machine
readable names changing and how to gracefully handle them changing in
URLs and HTML. I think it is safe to assume that people want the machine
readable name to directly correspond to the [human readable] content
type name.
A bit about the situation now. Here is the help text for the machine
readable name:
# The machine-readable name of this content type. This text will be used
# for constructing the URL of the create content page for this content
# type. It is recommended that this name consists only of lowercase
# letters, numbers, and underscores. Dashes are not allowed. Underscores
# will be converted into dashes when constructing the URL of the create
# content page. The name must be unique to this content type.
That is a lot to think about, especially when there is a second name
that is human readable and directly corresponds to this name. We could
auto-generate this name based on the current [human readable] name and
simply remove the whole field. If we sum the combined time of people may
spend wasting time trying to figure this out and compare that to the
remaining developer gain, I think the users should win.
I think this is enough to show that machine readable names used in URLs
and HTML should be auto-generated based on the content type name.
</pre>
</blockquote>
<pre wrap=""><!---->
Why not use a sanitized human readable name in places like css and html
output? What we're really talking about is user morphable database
keys, which in my opinion is out right wrong. We don't give end users
access to change nids? or any other ids do we?
1) When you start considering cck/field.module whatever it will be, uses
node->type extensively as a database key. I'm sure there is quite a bit
of other code that would really like to have that string set in stone.
Modules that generate content types being one of them.
2) When you change that 'machine readable type' aka database key, in a
transactionless database you're asking for lots of trouble!
We need a reliable name to use in code and in the database. You can hide
it from site users with a properly sanitized 'Human Readable' type.
I'd prefer to see customizable 'machine readable node types' go the way
of the dodo.
</pre>
</blockquote>
</body>
</html>