[development] node types should not be changeable, operations need hooks

[Rob Barreca]

>
> I'd prefer to see customizable 'machine readable node types' go the way
> of the dodo.
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.

Rob Roy Barreca
Founder and COO
Electronic Insight Corporation
http://www.electronicinsight.com
rob at electronicinsight.com



Darrel O'Pry wrote:
> On Wed, 2006-08-23 at 10:18 -0700, Neil Drumm wrote:
>   
>> 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:
>> - 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.
>>     
>
>
> 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.
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20060824/22fb7efa/attachment.htm