Attendence: Jonathan Chaffer, Dan Bravender, John Hwang
Location: Structure Interactive
Date: 2006/04/17
Time: 7:00pm - 9:30pm
We gathered at Four Friends around 6:45pm and waited until 7:00pm. We then moved to Structure Interactive in the McKay Tower and immediately began discussing about CCK. The following are notes about CCK and high priority items for GRupal that JonBob pointed out.
To Do
High Priority (For 4.7 Release)
- Collect Use Cases
- Validators (52051)
- Date Module (50062)
- Module defined fields - "Duck Typing" - Event module needs to define required date field, e.g. start date/end date.
- Teaser support - (Adrian) (51091)
Medium Priority (Future)
- Node_reference - currently allows you to limit by content type... but instead of that, it should allow - the user to select a view to take the selection (57902)
- Decorators - something like this is necessary...?? To be core
worthy(goes hand in hand with theme), we need to remove all HTML into the theme functions (theme_) (56298) (55338) - Import/Export Content Types - From one site to another (58153)
- Migration path from old content types (blog, page, image, flexinode...etc) to CCK
Notes
Date Module
-use built-in drupal's date function. needs to handle timezones
-Fancy Date widgets would be nice but we need something that just works
-Make sure that any database function we use is compatible with other databases
-Perhaps we need to update Drupal core's date_format()
Diagrams
We tried to diagram CCK as it currently stands from the user's/UI perspective and from the developer/code perspective.
diagram placeholder
"Duck Typing"
Other modules need the ability to designate required fields. E.g. Event module will want to require and designate a "start date".
Side benefit: "Behaviors"/"Meta Data"/"Flags"/"Settings". "Duck Typing" is important because it give the content type additional "invisible" fields that are available, but not used during form input.
Validators
Currently the content module does most of the heavy lifting in validating the inserts/updates to the database. However, widgets developers can add additional checks to ensure that the content is validated depending on the content. It would be nice to allow the user to designate additional validations that are beyond simple regex.
-Provide the user to type regular expressions to validate the content
-Provide a way for users to select which validator to use
Decorators
This was a discussion/suggestion but nothing was decided!
The concept of a decorator is an similar to the widget but for output and not input. Widgets are used to generate the HTML form input. Decorators would be use to specify the HTML output of the field instance. While there would only be 1 widget, there maybe multiple decorators for a field instance. For example, when a user wants to creates an url field, we want to give the user the ability to create a field called "Date" but depending on the situation, the user may want to display different outputs for the date. So the user creates multiple decorators named "Short date", "Medium Date", "Long Date", "Calendar Date"...etc. In the View, the user would be presented with all the different decorators available for the field and depending on the View, the user can select which output to use.
We have reservations about this feature b/c it blurs the line between the theme and the "view", as in MVC view. Jon's argument was that we can currently achieve much of this in the theme and it's clear where to draw the line between the model and the presentation... :)
"Derived" Node Titles
Drupal's Node table uses a single text field to hold the title and requires that it not be null. However there maybe instances where the user might want to multiple text fields with additional text to populate the title field.
Use Case
I want to build a node type for contact management You typically have a first name and a last name. You probably want to have separate fields for first and last name b/c you want to be able to sort/search by first or last name. But if I want to use the contact's full name as title, we have a problem b/c the currently node table only allows one field as the node title. What if we want to use the concatenation of both field (ie. Full Name) as the node.title. Wouldn't it be wonderful if we could allow the user designate multiple fields to be used as the node title? Even better, if the user could input additional text to prepend, append or insert. e.g. (Mr. John Hwang, Hwang, John, John Hwang Jr., ...etc.)
Suggestions
The user is required to select which fields to use as the node title.
1. Use tags - Mr. %lastname, %firstname
2. Create a decorator to handle the node title creation
Next Meeting
We will be gathering at Four Friends until 7:05pm and then move to Structure Interactive to code.
Location: Four Friends --> Structure Interactive
Date: 2006/04/24
Time: 7:00pm