Hi group,
I'm new to this group and forum. This may been a well-worn out conversation, but after reading through everything I could find, I've managed to make myself more confused. Specifically on the topic of developing hybrid-cck/custom modules.
Our usecase is, we've built a number of custom modules, including all of the hook_* functions to manage our data on our own. Recently, I began to look at views as a way to significantly reduce the amount of work required to create pages, blocks, tables, rss feeds, etc.. from our data (all of which is required). After prototyping this with one type in one module, I was overwhelmed by the volume of places in my code I have to maintain for each field - must of which aren't that sophisticated: dates, node references, etc...
This led me to CCK. The idea of using CCK to develop our custom types and inherit the display, validation, CRUD, and views support is very appealing. We can't go pure CCK because we have quite a bit of custom logic to perform with the data created. Workflow, calculation, etc...
After researching for the better part of this week, I've discovered a lot of questions in the community about the wisdom of pursuing a hybrid approach like this. However, I don't know how current most of the discussion is. For example, the oft-cited concern about fields changing out from under a custom module appears to have been addressed in CCK 6.x-2.0 : From the release notes -
Usability Improvements
-- snip --
* Re-arrange non-CCK "fields" (title, body...) along with CCK fields on the Manage fields screen. Third-party modules can expose their own "fields" to gain d-n-d reordering for free.
-- snip --
API* A new API with Create/Read/Update/Delete (CRUD) functions has been added to make it easier to create and populate fields from custom modules and profiles.
* Module-defined fields can be 'locked' to prevent users from changing or deleting them and breaking functionality.
* The API for widget modules have been significantly reworked to allow field widgets to be reused outside of node forms.
It would appear to me, these features overcome a majority of the issues cited in hybrid development. BUT, I can't find any documentation how to achieve these results. I've read through content.module, and search all the forums I could find. How do we do it? Does it solve the problems many have raised about this approach?
Thanks!