A very good way is that followed by the views_gallery module in its install script, where it creates the gallery and image content types, including imagefield, etc. See http://drupal.org/project/views_gallery <http://drupal.org/project/views_gallery>I feel I have improved upon that in my (work in progress) Project Flow & Tracker installation profile, where I use a function from the installation profile API to create a content type and its fields from a file (holding what is exported via content copy). You can download that here (branch 6.x-1.0-alpha1): https://github.com/victorkane/ProjectFlowAndTracker/tree/6.x-1.0-alpha1 Victor Kane http://awebfactory.com.ar http://projectflowandtracker.com On Mon, Jan 17, 2011 at 10:37 AM, Randy Fay <randy@randyfay.com> wrote:
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@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@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@yahoo.com Skype: ayendesigns
Ayen Designs is a tradename of the computer services division of
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
