I added this functionality into the options module I created, but am thinking this is really a distinct issue. I see a need for flexible options to format the output sent to the node view for cck. The current basic modules just wrap the value in a div with no label, which obviously needs more work. I know we are relying on the views module for much of the formatting of the output, but after spending some time with it, I think it is not going to be a solution for deciding exactly what html is going to be put in the body of the cck node itself. There are basic questions like whether or not to display a label for the data, and whether to show it as a div or a dl.
I created a way that format options can be selected for each field when the field is created. They should include enough options so that output can be themed, css can be applied properly, etc. I cut this functionality out of the options module and put most of it into the content module (where it probably really belongs). This includes a way of setting the format options, and functions to handle the themeing of various alternatives. Then the individual field modules just need to return their values wrapped in the them functions and the output will be displayed as the admin intended.
I am attaching a patch for the content module that will make this all work. I have also created a patch for the text, number, and date modules that would allow them to use this functionality. That should be enough for others to decide if this is a good approach.
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | content.module_7.patch | 2.74 KB | karens |
| #11 | content.module_6.patch | 2.66 KB | karens |
| #3 | date.module.patch | 1.3 KB | karens |
| #2 | number.module.patch | 1.31 KB | karens |
| #1 | text.module.patch | 1.63 KB | karens |
Comments
Comment #1
karens commentedHere is the patch for the text field.
Comment #2
karens commentedHere is the patch for the number field.
Comment #3
karens commentedAnd here is the date field.
Comment #4
coupet commentedworks great! as mentioned, more options on how data is sent to node view.
Comment #5
markus_petrux commentedHaven't tested, but it looks great!
***monitoring :-)
Comment #6
karens commentedThis is going to need to be re-rolled for the latest cck version since there were lots of changes that will affect it. I will try to do something with it next week.
Comment #7
sami_k commented+1 though I have yet to see what it actually does, but if the description is accurate, it is only necessary that CCK have this patch.
Comment #8
markus_petrux commentedCould you please add OL/UL (wrapper) and LI (items) to the formating options?
Comment #9
David Lesieur commentedUnfortunately the patch does not apply anymore, but by reading the code I'd say +1! Great patch. I need it. :-)
Comment #10
markus_petrux commentedhmm... instead of all these options, what about preparing a normalized structure with all information about a node that is passed to a theme function?
CCK could provide a default implementation, but with such an approach it would be pretty easy to override. The limit is the imagination! :-)
Comment #11
karens commentedBuilding on markus's comment, I realized there is actually a very simple way to get decent looking, themeable output from the current implementation of cck, and it also adds in field labels and sorts the fields in the output based on the weight that was given to each field. The attached patch makes changes to content.module and will work even if you make no changes to the field modules.
The basic approach is this:
1) The current field modules format the view output and pass it to the $node_field array, and also return formatted output back as a return value. I am using the array and ignoring the formatted output.
2) Content.module takes a last pass at that $node_field array after the field is done with it. I added code in this patch to add the label and weight for each field to the array in addition to whatever else they did.
3) In content_view I invoke field_view for each field but ignore the output it is passing back and just build the output array.
4) Finally, I take the output array, sort it by the field weight and field label, then pass it to a theme. The current theme formats the output as a dl, but can, of course, be overridden.
If this approach looks good, we should go back to the individual field modules and remove the line where they pass formatted output back and just let just work on building the $node_field array.
Comment #12
markus_petrux commentedSweet!
Would you mind passing more information to theme_content_view(), so if one needs to override, it might be necessary to know something about the $node or the context itself. Maybe passing the same paramaters that content_view() got, adding the generated array $out at the end?
You might want to initialize $out on top of content_view().
Comment #13
karens commentedGood points. I also changed the name of the array to $view which seems more intuitive. This goes back to my thought earlier about passing a $view array around and then processing it at the end in the same way we now pass a $form array around and process it at the end.
Anyway, is this what you were thinking of? Any other ways to improve it?
I also added the node_teaser() function which will take the full page output and shorten it, but if we want to be able to identify specific fields that should display in the teaser that will require other changes.
Comment #14
markus_petrux commentedYeah, theme_content_view() is looking good t me.
About the teaser... hmm... not sure what's best to do here. content_view() gets a parameter that tells if it is about a teaser or not. In node.module::node_view() only $node->body or $node-teaser is generated. Also, node_view invokes nodeapi(view) and hook_link(node)...
Maybe if CCK fields had an attribute to say if it needs to be rendered in teaser (or only in body)?
Comment #15
karens commentedI think has been made irrelevant by latest cck themeing additions.
Comment #16
(not verified) commented