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 <ra...@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, <j...@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, <j...@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) baal...@yahoo.com >>> Skype: ayendesigns >>> >>> Ayen Designs is a tradename of the computer services division of >>> >> >> >> >> -- >> Randy Fay >> Drupal Module and Site Development >> ra...@randyfay.com >> +1 970.462.7450 >> >> > > > -- > Randy Fay > Drupal Module and Site Development > ra...@randyfay.com > +1 970.462.7450 > >
<<acmelogo>>
<<ayenlogo>>
