By vivekkhurana on
Hi!
I have to write a drupal module which adds a field to selected content type form. The module will have one and only one autocomplete field.
My query is, can I base this on CCK ? What are the advantages of basing a module on CCK vs writing hooks from scratch and creating database tables. CCK provides all this plus integration with views. But might have to compromise with db tuning etc.
So what I am trying to understand here is that given a module is going to has only one field, under what conditions it will be worth basing a module on CCK ?
regards
Vivek
Comments
CCK is used to create content
CCK is used to create content types. Other modules extend content types and/or work with them. As examples, the taxonomy module allows you to categorize content and the views module can display content in a variety of ways. There are many more modules that work with content types. Modules that collect and store data that is not content type based loose out on a lot of this possible functionality but not necessarily all. Your module could for example provide it's own views integration to work with views.
You don't really say what the purpose of your module is, so the question is, can it benefit from working with content types.
Purpose of the module
The module I have to create mimics the functionality of tags. The difference is, instead of using taxonomy, I have to use content to tag content. We have custom content type for department and now the requirement is, that a user should be able to tag content with departments. One option would be to create a taxonomy term, whenever a department is created or second option is to allow user to select content via an autocomplete box. I am taking the second approach, allowing user to select content for tagging.
So, my module has to show only one field, which is an autocomplete text box for selecting department(s) and expose one view handler to list all the content tags available for a given node.
Automatically adding a
Automatically adding a department taxonomy term is a useful idea, and would not need much custom code. You'd get a per-department list of tagged content with no extra work. But you may find you need to do some work if you don't want all Drupal's standard taxonomy features to apply to this vocabulary (RSS feeds, search, etc).
Or use a CCK nodereference field, loading the autocomplete values from a specified View of the departments content type. No custom code required. If you need to tag an item with multiple departments using autocomplete, you'd need to make that field a multiple-value field. If you need a view of content per department (like a taxonomy listing), you'd need to create a View with an appropriate reference to handle that.
Personally, I prefer the second approach if full-blown taxonomy features are undesirable.
Sorry I may have
Sorry I may have misunderstood. The advantage of using CCK is that it will be far less work that custom code, has been tested extensively for security and performance, avoids reinventing the wheel, and allows you to add other CCK-based features with minimal work.
The disadvantage of CCK is
The disadvantage of CCK is that it requires a number of extra modules (increasing the RAM usage on every page load), it's not particularly portable between sites, and it's often very awkward to customize.
Weigh the options and see what is best for you.
Contact me to contract me for D7 -> D10/11 migrations.
I think the question of how
I think the question of how easy it is to customize a content type is very dependent on the problem.
Note if departments are a
Note if departments are a unique content you can easily use a node reference field (ie no need for a custom module).
Also, for people following along, if you want to make a taxonomy term based on a node title there is the Node Auto Term [NAT] module.
Need multiple references
My problem is, in some cases a node can be tagged with multiple departments. For instance a notice that is important for more than one department. Node reference allows you to reference one node at a time and the UI for referencing multiple nodes is cumbersome. The requirement is to have a UI similar to active_tags.
I would then consider create
I would then consider create a widget for node references that works like active tags (Yes you can create new widgets for existing field types).