[development] node types should not be changeable, operations
drumm at delocalizedham.com
Wed Aug 23 17:18:56 UTC 2006
Jeremy Epstein wrote:
>> 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.
> -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:
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:
- PHP code
- 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
A bit about the situation now. Here is the help text for the machine
# 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.
More information about the development