I've been thinking about some modules recently and about how to get the data they need. Looking at a general trend of "monolithic module" -> "individual CCK fields + helper modules + glue code" I'm curious how those "helper modules" can get the metadata they need to know how to interact with the CCK fields.
More specifically, we have the image module and then lots of helper modules image publisher which know how to interact the the image module because it's node type and data structures are set in stone.
In the CCK world, lets assume we are using the image field so how do we get the image publisher to get data into the image module?
I can see a "node_get_types" and then foreach over that and "do something" but I'm not sure what that something is...
Is there a helper function that can tell me which field types are installed on a node?
I remember hearing something about this at Drupalcon...but not exactly what that something was...
Comments
cck field info ok, but gallery is messy
the first place to look is to see how this page is generated since it has field => node mappings: admin/content/types/fields. if you spelunk that, you will find content_fields() and its helper function _content_type_info() which does laods of good stuff (and more).
but even then we aren't able to match what image_pub does becuase it knows exactly how gaalleries are built (i.e. taxonomy based). in the cck world, thats not always true. one could use node references to albums, for example. perhaps whats needed is another module which is "cck image gallery". that one ships with a node type called album and imagefield nodes can node ref into that. this gallery module would be presumably also ship with some default views ... or just keep doing taxo based galleries since thats more static.
any parent will tell you that glue can be messy.
Indeed, $fields =
Indeed,
$fields = content_fields(NULL, $content_type);is the answer.content_fields
Interestingly enough, if you leave out the first argument then you might as well leave out the second argument as well
That was unexpected behavior...
--
Knaddisons Denver Life | mmm Chipotle Log | The Big Spanish Tour
knaddison blog | Morris Animal Foundation
Huh? If the first is NULL,
Huh? If the first is NULL, you simply get all fields for the specified content type. I use this very line of code in the Hierarchical Select module, so I'm sure that it works.
all fields for all content types
Look at the comment and the code - you get all fields for all content types.
Greg
--
Knaddisons Denver Life | mmm Chipotle Log | The Big Spanish Tour
knaddison blog | Morris Animal Foundation
great - thanks
These are perfect, I'm digging into them and they provide just what I need.
My plan right now (and gallery was just a proxy for the top secret module I'm building) is to provide an admin interface that provides options:
So the glue module that I provide will force some decisions on the user (like you must use vocab to define galleries). Of course, it could be extended to include the concept of galleries as node refs.
Thanks again.
--
Knaddisons Denver Life | mmm Chipotle Log | The Big Spanish Tour
knaddison blog | Morris Animal Foundation
Working with CCK and non-CCK
Two questions--
Is it strictly the CCK way to save fields in CCK tables? Would it be right out for your cck_latlon module to store latitude and longitude in its own table, that could be shared by, say, user_latlon or taxonomy_latlon? Am I being very silly?
In general, how do you think your cck_latlon should play with the (appropriately sprawling) location landscape?
My questions aren't academic; for the World Social Forum 2008 call to action I'm throwing together a location solution that will use taxonomy under the hood.
~ ben melançon
member, Agaric Design Collective
http://AgaricDesign.com - "Open Source Web Development"
benjamin, agaric
somewhat ot - my thoughts
In short, yes, cck fields can store data wherever they want. If you look at example cck field module you can see in hook_field an explanation of where/how to store data.
Really, I think that the geo module is the rightful home of these kinds of things, but it isn't 100% ready for prime time. I already had built the cck_latlon solution before I really know what geo could do.
As I said in the commit of the cck_latlon module, the eventual direction of it may be towards merging with the geo module. But right now I need it on its own.
--
Knaddisons Denver Life | mmm Chipotle Log | The Big Spanish Tour
knaddison blog | Morris Animal Foundation
Also API
Actually, I think the future direction will be:
1) A variety of APIs (think image API, date API, voting API, actions API, form API).
2) One or more fields that use one or more APIs to create fields, widgets, and formatters. Some could be combo fields that combine simple fields into more complex ones. Combo fields take lots of custom code now, but should become easier in 6.x.
3) Default views to display the fields in various ways.
4) Some glue for whatever is leftover. If the API is good enough, maybe won't take a lot of glue...