By drupalnesia on
I have created a node reference called as "Product ID" using CCK. What do I need is the "Product ID" reference not only shows the "Product ID" but also "Product ID, Product Name, Product Group" (but saving only the Product ID value on the table).
If we can do this then users no need to recheck what is the product name of certain "product id" and vice versa. So, is it possible doing such thing with CCK?
Comments
Yes, but you have to get them
I use contemplates, and I put something like this into the top of the template:
Then you can print the details you want:
A real life example:
This get the name of the hosting company, and the other information I want displayed on an individual hosting program. This is for a web host guide I am making.
See it here: http://host.shabamdevelopment.com/ (mostly done, but still under construction. That piece is done.)
I mean on Edit Form
Sorry if my question not clear. What do I mean is in Edit Form.
Example: while users create an order than users can see the Product ID and Product name in the select list. This is not difficult in simple HTML because "select list" support title and value, but I don't know which part of CCK code/field/table should I alter.
Also, I found that node reference in CCK always refer to the "title field".
Any ideas?
The reference always points
The reference always points to the node-id, but the title is shown in the select list.
Try to make a list-view, and select additional fields you'd like to see in the labels in the select list.
This approach doesn't work.
This approach doesn't work. Because all of the list-view will be saved to the field. What we would like to save only the primary/foreign key. Think abou the master-detail.
Could CCK noderef include node body?
I wanted to use CCK noderefs to include the whole of another node, and produced a contemplate hack which operates along roughly the same lines (I think - I'm a Drupal development newbie).
It works ok-ish, but I really want to operate on the Form API tree of content and not on HTML because I want to do some restructuring before display. I want to build a node content tree that includes child node content trees.
CCK's nodereference field looks like a good candidate for being extended in some way. I'm tempted to patch nodereference.module's function nodereference_field_formatter to add a new field format that displays the entire referenced node instead of a link to it. The problem with that is that (I think) I'm still dealing with HTML.
Does this approach make any sense? Is there some other approach I should be looking at?
Am I asking in the right place?!
I have the same question
I'm looking to add child nodes under a parent node. I see a little "+" in my head.
I want to have recipes and then want to just click a + and be able to add ingredients and amount (in Ounces or cups) right while editing the recipe. But I want the ingredients to be referenced from another set of node types. (I have ingredients and recipes)
I want to be able to also click on an ingredient and be able to see what recipes it is used in, and be able to click on any of the recipes to open it.
I am totally stumped, and can't seem to find any tutorial on how to do this without getting in to the thick of the code and the API. Is there an easy way to do this? The closest thing I've figured out is to have a fieldgroup and then a fieldgroup table, but that solution just seems messy.
Thanks!
Mac
Field content is just an HTML string
I've learned a little more about this, and it seems part of my question was based on a misconception about what "Input filters/formats" actually produce. I was thinking they produced a big structured Forms API array that gets rendered to HTML at quite a late stage. Hence you could manipulate the output as fine-grained structured forms data.
Now I think they go straight from the input format to a single large HTML fragment, represented as a single string - pretty much as they used to in Drupal 4.7. The only real structure you have is the different fields of a node (e.g. title, body + metadata such as author). So fine-grained restructuring of the content of referenced nodes is not going to be easy unless I'm willing to parse their HTML.
I hope this helps others treading this path.
Duncan