[development] D6 Programmatic creation of a custom content type with fields

Randy Fay randy at randyfay.com
Mon Jan 17 13:37:17 UTC 2011


IMO, wherever possible, it's best to let CCK manage additional data on a
node. And if a custom data type is to be presented, wherever possible, use
features to manage it.

-Randy

On Mon, Jan 17, 2011 at 2:30 PM, <jeff at ayendesigns.com> wrote:

>  Ah, makes sense. Ok, so that leaves me with one higher-level question. Is
> there a question I should be asking myself to decide whether to have cck
> manage the content type, its field and the processing of both or to do it
> separately, other than which is easier?
>
>
> On 01/17/2011 04:36 AM, Randy Fay wrote:
>
> The D6 node_example in Examples is the non-CCK technique, and it adds
> *data* but not fields, to a node. Presentation and data management are done
> in custom code.
>
> If you just need something that CCK can do, use features and CCK (which is
> essentially the easier way to do #1).
>
> Both ways work, but if you *can* do it with CCK + features I would think
> that would be the best technique.
>
> -Randy
>
> On Mon, Jan 17, 2011 at 4:49 AM, <jeff at ayendesigns.com> wrote:
>
>>  I find what seems to be two different approaches for creating fields for
>> a custom content type via a module. One is from drewish, where the field is
>> first added via cck manually, then dumped with var_export(content_fields())
>> and then added to the content type in the install via
>> content_field_instance_create(). The other is in rfay's Example module,
>> where Randy creates a table for the module in the install and inserts fields
>> into it that are what cck would insert.
>>
>> I'm wondering if the latter removes the need for me to do all the node
>> processing from my module. Also, my content type has one field (other than
>> title and body) which is an image filefield with unlimited instances, and
>> I'm thinking that that same method would have the field being handled by
>> filefield and that the method in Example would require that I manage the
>> _fid, _list and _data db content, etc., so if there's a reason why this
>> would be a better way to do it, or why the first method wouldn't be, I'm
>> missing it.
>>
>> Jeff
>> --
>>
>> Ayen Designs
>> 388 Bullsboro Drive #105 · Newnan, Georgia 30263
>>  404-271-9734
>> Web:ayendesigns.com
>> Blog: theAccidentalCoder.com <http://theaccidentalcoder.com>
>> Drupal: j. ayen green <http://drupal.org/user/367108>
>> IRQ: j_ayen_green
>> IM (Yahoo) baalwww    (MSN) baalwww at yahoo.com
>> Skype: ayendesigns
>>
>> Ayen Designs is a tradename of the computer services division of
>>
>
>
>
> --
> Randy Fay
> Drupal Module and Site Development
> randy at randyfay.com
> +1  970.462.7450
>
>


-- 
Randy Fay
Drupal Module and Site Development
randy at randyfay.com
+1  970.462.7450
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20110117/8b7a428e/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1462 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20110117/8b7a428e/attachment-0002.jpe 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 8316 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20110117/8b7a428e/attachment-0003.jpe 


More information about the development mailing list