Hello. Please forgive my placement of this post. The options didn't yield a clear forum to post this to.

My question is about strategy in defining a certain content type: a product data sheet.

I am in the process of converting my company's existing website to Drupal. The site is www.spacequest.com We sell spacecraft components and have a "Product Data Sheet" for each component, which list the specs for each product. This data is provided in a tabular format and includes things like Input Power, Power Consumption, Operating Frequency, etc.

I would like to design a Product Data Sheet (PDS) content type that allows me to define these specifications in each PDS. I could, of course just put the data in the node body, but I don't like that much. I looked at Ubercart based on some example sites I had seen, but it does not appear to have the functionality I need to add the specs. I assume that people who have the nice sites I saw were done custom or the data was entered in the node.

The solution I have come to for the moment is to define CCK variables for each unique spec type and put them in CCK groups (we have general spec tables, radio spec tables, etc and sometimes they are separate). However, my feeling is that someone out there may have come up with something better. If you have, I'd love to hear your suggestions!

Thanks!

Comments

WorldFallz’s picture

You don't really explain why ubercart and cck aren't working for you but I suspect the result doesn't look the way you want it to.

I would definitely do this with cck and fields, then simply theme the node to appear however you want. If you created a content type called 'pds' you can then create a template file called 'node-pds.tpl.php' (you can simply copy the theme's node.tpl.php to start with) and rearrange the output any way you wish.

dcajacob’s picture

Actually, my issue doesn't relate to theming. I am aware that I can theme the node and its fields to look however I like.

The issue is the structure of my node type which I'll call a Product data Sheet: Essentially product data sheets had several tables of specifications. If the sheet refers to a GPS receiver, I might have a General Specs table wherein I specify the units power consumption, receive frequency and data interface protocol. I may have another table that covers its environmental specs, like min and max operating temperature, vibration tolerance, etc.

I'd like to define the specs as CCK fields in my node definition, but I don't see a beautiful way of doing it. It seems like I'd have to create a unique CCK field for each type of spec. I Know I can group them with CCK Groups, which helps. But it seems kludgey. I was wondering if someone with more experience had insight in how to implement something like this, where the data is more variable and less well-define dthan your average node type.

The reference to Ubercart is to point out that I evaluated it to see if it met my needs. I had seen a website that was putatively run using UberCart where the products hads LOTs of product specs. But my experience with UC seemed to indicate that those nice specs were likely just part of the node body and not really CCK magic.

Thanks!

WorldFallz’s picture

I know it doesnt seem like it, but this is really ultimately a theming issue. There's a couple of ways to approach the data collection:

  1. you could use one base node with nodereferences and/or viewfields to the individual specs which are contained in their own content type, then theme the output however you like-- perhaps with views and theming the different views.
  2. you could, as you mention, use cck fields and fieldgroups right in the one node, and again, theme the output however you like.
  3. you could store the data directly in non-drupal tables, and theme the output to retrieve and format the data however you like

See the pattern, lol? If it were me, I'd probably go with the first method.

And you're correct-- there isn't a 'simple' way to do this and get 'beautiful' output automatically-- whatever method you choose, this type of complex layout is going to require a significant theming effort to achieve something "beautiful" ;-)

dcajacob’s picture

Thanks,

This is helpful. Not to disregard the advice, but I do understand the importance of themes in all this. My initial question (if poorly worded) was really regarding the data or node architecture - how to tie all these specifications to a product node. And my use of 'beautiful' really refers to the data design, not the look and feel. I think a good, proper data design is a good start. I hate starting with something kludgey.

I had considered all the options you mention, except #1. I don't think any of them are beautiful, but I'll probably go with one for now and change things in the future if something better comes along.

Thanks for your help!

WorldFallz’s picture

you're welcome ;-)

And, based on your additional comments, I would definitely recommend option #1 -- though I would not call the data structure "beautiful", I would say it is "clean" and allows you the most flexibility for future changes/additions to functionality.

effulgentsia’s picture

You might want to check out Conditional Fields and/or Flexifield. With conditional fields, you can set up all the individual spec fields in your PDS content type, and then have "controlling" fields that show/hide groups of the individual spec fields. With flexifield, you can setup each group of specs as a content type, and then have your PDS content type use a flexifield whose "Allowed content types" setting includes all of the spec groups.

john.kenney’s picture

Hi:

I saw this thread which is similar to something I'd like to do. I wonder if you were able to make a go of it somehow?

I'm thinking maybe not cause I see you're still using PDF product pages, but maybe it's in the works.

I'm not doing products, but rather company reviews. The basic idea is relatively similar, though my page layout looks more complex than yours. Example page: http://www.aboutcallingcards.com/pingo-review

From reading this thread, it sounds like there is not a simple way to create something that looks like a 'normal' table where the field-labels and field-items are cells in a table vs.

's. From what I can gather from this thread and others, I would need to create a new .tpl.php template which identifies all the relevant fields, overrides the default layout, and stuffs the data into tables / cells - which is fine, except I don't really know how to do that.

I'd be grateful to hear of anything that might be of help.

Thank you!

john.kenney’s picture

I figured out how to do this.

Took quite a while, but now have the elements working. Haven't completed an actual page with it, but all the parts are working, so just a matter of polishing it.

Partly for my own benefit, here are the relevant pages to help create highly structured pages or data tables using CCK:

- http://drupal.org/node/198572 -- Theming the same CCK form in 3 different ways

- http://drupal.org/node/101092 -- Theme a CCK input form

- http://drupal.org/node/590740 -- How to create data sheet using CCK with tables and text areas

First two are more focused on creating CCK forms - and really, the direction shown are totally not relevant for the task at hand, but I include them because they are otherwise widely referenced and I suppose they were helpful way to start learning out CCK themeing. But alot of it is total misdirection for creating a customized HTML/CSS page for outputing data (as opposed to inputting it). For instance, all the stuff in these pages about putting things in template.php file is not necessary to do a CCK data table.

Instead, read the last one which is mine.

Short version of how to create a CCK data table is as follows:

0. Install CCK and contemplate modules; as necessary, install additional CCK modules for specialized fields like links, email, etc.

1. Create new content type and add CCK fields

2. Create new node-content_type.tpl.php template page

3. Add generic content and/or customized HTML (e.g., div's, tables, classes, etc.) to achieve desired layout with placeholders for where the CCK variables are meant to go

4. Use contemplate to identify exact variable names to use, including suffixes like [0] and ['value']. For whatever reason, most CCK variables end up with multiple forms, so you need to figure out which ones generate the exact output you want.

5. Insert CCK variables in appropriate spots in your .tpl.php file. Format each variable calls as follows: <?php print $field_variableName[0]['value']; ?> where you use the appropriate suffix shown in contemplate to obtain the precise output desired for each variable. Examples: <?php print $field_review_company_name[0]['value']; ?>, <?php print $field_company_url[0]['view']; ?>

6. Style using CSS, as needed