Access to the object reference for the nodeto
| Project: | CiviNode And Civinode CCK |
| Version: | 5.x-1.x-dev |
| Component: | CCK Integration |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Torenware |
| Status: | needs review |
Jump to:
Add in a way to get the node object references when the node is loaded. This will allow us to load the node but divert theming so that we could do the theming ourselves rather than use the function theme_crm_profile_group(). It's likely that one contact will be presented in different ways dependant on the context. All being well, that will allow us to address these two issues by giving us the capacity to theme the data pulled from the civinode output.
a) I'd like to see the information displayed inline rather than with the title above, the information and a blank line before the next field title. In addition, can we choose to display some of the info without titles and perhaps on the same line as other info, or the default will always be new field on new line? In any case, here's how the contact info *could* ideally be displayed - or a variation thereof:
=====================
Summary Contact Information
Name: Dax Xavier Testing
Skype/VOIP: xxx@comminit.com
Web Site Address: http://www.comminit.com
Home Phone: 250-555-0494
Address: PO Box 74057, 13a25 West Saanich Road
City: Victoria
Zip/Postal Code: V0S 7Z0
State/Province: BC
Country: Canada
=====================
b) The profile title appears to be defaulting to id #1 (i.e. "Constituent Information" has ID 1 in the civicrm_uf_group table) as opposed to picking-up the appropriate profile title (i.e. should be "Summary Contact Information" as selected in the CiviNode default profile to display this particular format of information). If we had access to the object fields (Home Phone, Address, City, etc.) we could build the whole of the output as the choose and leave out what we want.
#1
I'm thinking that you don't actually want the node reference here; you want a reference to the contact data, yes?
Where do you want this? If the problem is one of theming, here's my proposed way of solving this:
How does that work for you?
It may also be true that you need multiple theming options. Then the right thing to do is to create the appropriate CCK formatters. It probably still makes sense to back these with php templates, the better to make improving the module's theming.
#2
Mostly yes. When you access a CCK node and try to theme it, you can mine a large array of key=>value pairs and some objects (e.g. a print_r of the $node: http://dev2.comminit.com/drupalfive/?q=en/node/52812 (best viewed via the source)). What would be great: to get this same detail of information available from what gets stored in CiviCRM when the CiviCRM comes via CiviNode. When we reference a node that is a CiviNode, we would take that node id# and use it to do a node load on it and then selectively, we could theme output from some of the data.
In the above example of an exposed node, we would do code like this:
<?php
$this_node = node_load(52812);
print "Title:".$this_node->title."<br/>";
print "Fiddle free for : ".round(($this_node->changed-$this_node->created) / 86400)." days<br/>";
?>
based on what is inside of the results of the node_load function. Maybe this would best be done by adding a civinode_load() function (similar to node_load) that extends the object with the contents of the CiviCRM `civicrm_contact` table and the other associated tables that would go into a CiviCRM contact. This could be done by passing out the output from db_fetch_object as the output of a civinode_load() function. Just a thought.
All the best,
Mike
#3
I have a couple concerns about this. The main one is that loading the contact data at hook_field / load time (which is when you'd have to do it) can be pretty expensive if done unconditionally. This is especially true if CCK is invoked by the Views module, where the code may want to look at many nodes at the same time. It's certainly *possible* to do it then, but it would lead to situations where you'd use so much memory that you'd slow your server to a crawl. I prefer to "lazy load" the data instead, just before it's needed.
The other approach would be to mirror some of the key contact data in Drupal. You really don't want to go there: the code to do this gets very complex very fast.
So it makes more sense to fetch data at theming time instead.
If you are looking at a node in code, it's always possible to get at the contact data, and I have APIs that do this if you need access to them. I either use civinode_util_load_cdata($contact_id), or I load the data directly with one of the civicrm calls (which take a little more doing).
I'd recommend using a theme-engine based approach, since it's the most "Drupalish" solution, and the easiest to modify. We can certainly create more options for a contact formatting theme for more flexibility, and it's always possible to override any theme function, either in a module or in your custom theme. These are standard ways of working in Drupal, which is what you want to do whenever possible.
#4
Two thoughts:
1) We only need the object when node_load() is invoked. We could pass arguments through the $param array to node_load() that would be ignored when the node_load assesses it, but could be a flag when passed to civinode_load() ? Also, the atomized data should be available; when the object is loaded, so this would be adding to the size of what comes back. If we can get a $contact_id reference to the CiviCRM data then we can pull from that civinode_util_load_cdata($contact_id), and that would work.
2) I agree that this could be expensive, but the object won't change frequently, so it could be cached and then loaded from the cache if its available.
So, we need to be able to use civinode to hook a CIviCRM reference to a node. Then, use the $contact_id to get a result from civinode_util_load_cdata($contact_id). In Civinode where is the contact_id stored?
#5
I'll start on this issue either today or tomorrow.
What I'll likely do is use the approach from John and Matt's book, and expose a PHPTemplate file for folks like Nedjo to modify to their heart's content.
#6
I've just checked in a new test verson of civinode and civinode cck into HEAD on Drupal CVS.
The theme directory contains a simple stub for doing PHPTemplate theming. It's ugly, but it's functional. I'm hoping one of you better themers will change the code to something that is actually pretty, and submit a patch.
See the theme/README.txt file for more info.