CCK

CCK is becoming quite useful and living up to its promise. The node and user reference fields are not terribly useful yet, though. The Add and Reference and Form Restore modules by Artem Timofeev are great additions to the interface aspect.

By far, however, the largest issue that limits the real use of the node and user reference fields is their lack of ordinality. It is impossible to say that the relation is 1:1, 1:n or n:m (if we were really daring we'd implement an inheritence reference as well). For example, I'd like to use CCK to have a database of composers and the pieces they've written. Assuming I could work out all the interface and workflow issues that make it rather clunky to catalog the complete works of Mozart and Telemann using these tools, the real knockout criterium that prevents this from working is that there is no way to say that a piece can only be referenced by one composer (1:n). What good would the database be if it were possible to say that both Beethoven and Stravinski wrote the moonlight sonata?

Attendees:

• trevor tunnacliffe - devlin ebusiness architects
• robert parizek - redoing vanillabeansolutions.com in drupal
• christian nally - instillananarchy.com
• colin chudyk - 3ring.com
• richard eriksson - justagwailo.com
• scott hadfield - converting www.cs.sfu.ca
• james clendenan - queens engineering society engsoc.queensu.ca, nice
  use of LDAP for single signon which was timely given the Identity Open Space Vancouver that took place all day yesterday and all day today
• dale mcgladdery - www.group42.ca

Colin presented on the category module. I showed off support.activestate.com in Jeff G of ActiveState's absence (he was sick) and we talked alot about CCK and Views (I showed how we used it on Cosmic Cubes.com and Colin showed his postal code matcher).

Howdy,

looks like one of the most wanted features of Conent Construction Kit (CCK) are teasers (short presentation text of nodes with eventually a picture, showing on the front page).

Urging this feature as many others for couple of my websites, I digged Drupal.org a bit looking for a solution. Unfortunately, teaser functionality seems still on it's first steps and many different approaches can be found (i write below the interesting Drupal.org nodes i found).

QUESTION: i would be interested in hiring / co-sponsoring a programmer to develop teaser functionality for CCK. Can any expert Drupal coder give a hint on what approach is more reliable/correct/better, so to take the right path and spend well any effort?

Before reading this post, check out my thoughts on how to implement a new taxonomy system using CCK. It figures into my idea here as well:

http://groups.drupal.org/node/246#comment-1625

Proposal: A theme/module that manages each *.tpl.php file for the site admin by storing the layout in the database. For each handled hook (aka hook.tpl.php), the system would create a CCK type. The type would contain a Title and a text field. The textfield would be the place where the admin could enter the theme code. Each *.tpl.php would just be a shell to pull in this data from the currently selected node.

Firstly, hi all in this group...

A little background from me - I've been programming websites for a few years and recently had a chance to meet Rob Douglass through my work. My eyes have been fully opened to Drupal and its potential! Before drupal I coded sites by hand as I always believed CMS's to be restrictive and blubbery. Although drupal isn't particularly lightweight, its certainly not restrictive. My first (personal) project was to create a challenge database for a forum I regularly attend... This produced DBP-Site. I learned a lot from this such as a code highlighting module which, at some point, I'm going to progress and submit to the module base here (it should work as a more generic highlighter too).

You can look at the basic work I did yesterday on making a date field widget in my sandbox. There is also an issue in the CCK issue queue to address the code.

Someone please take over. At least parts of my approach are quite good and can be used in a final solution. Other bits are clearly a fudge because a final solution is going to be a lot of work.

Known issues:

• Day seems to be offset by -1 after going through format_date
• Time zone support is nonexistant

One of the things I came away with from the Vancouver DrupalCon, is that we already have our relationship API, in the form of CCK and what I want to do with forms 2.0.

Firstly, in forms 2.0, there will be 2 discrete steps.

Step 1: Defining Fields for form. (or node type, or whatever)
Step 2: Placing these fields within their final form structure (add tables, fieldsets etc).

Now I am basing this functionality off of the cck field definitions, so that all the validations and field type
code will be built using cck, and one of these field types is 'nodereference'

CCK already handles all the 'has, can have and single / multiple' bits of the relationship api, and with