The Future of Fields, Drupalcon Boston 2008

This wiki page is for the development of the Drupalcon session we'll be presenting in Boston. We have 90 minutes on Tuesday morning; see our session page.

Please edit this page only if you attended the Design Sprint and will be participating in the session. Otherwise, please give us your feedback via comments. Thanks!

Session outline

Each section to be a presentation with a pause for questions before moving on to next section. The early sessions should be pretty quick because most of it is review of concepts already long-discussed within the community.

Presenters are bjaspan, crell, karenS, nedjo. I (bjaspan) have assigned specific presenters to each section; each presenter will create the slides for their own sections. If anyone objects to my suggestions or does not have time to create the slides this week, just speak up. Please create plain, unstyled slides. I'll merge them all together for simplicity during the session (we don't want to have to switch computers, etc., mid-session).

Overview (bjaspan; 3 minutes)

• Idea for and participants in design sprint
• Goals and outline of session
  • Goal: to present results of design sprint and get community feedback and collaboration

Need (bjaspan; 5 minutes: 3 minutes presentation, 2 minutes questions)

• Our vision of Drupal's future
  • Web application development platform; CMS is just one in-the-box app
  • API driven, not form-driven
  • Able to consume and provide web services
  • Able to seamlessly leverage the power of contrib for local and web service data
• Problems and challenges at present
  • Multiplicity of uneven APIs for object handling (user vs. node, etc.)
  • Binding to user input (form) model
  • Single assumed data store (local SQL DB)

Analysis (nedjo; 5 minutes: 3 minutes presentation, 2 minutes questions)

• Some steps to achieve the vision
  • Data API: Consistent methods for using local and remote data
  • Data rendering: Ability to output in many formats, not just HTML
• CCK fields as model
  • Already exemplifies much of what we are aiming for
  • Consistent method for attaching data to nodes
  • Escape the current garbage heap of $node
  • Represents a shift from objects or entities (nodes, users) to their fields as the core focus

Initial goal: minimal CCK-based fields in core (karenS; 15 minutes: 10 minutes presentation, 5 minutes questions)

• First step: Fields in core
  • Preliminary work in D6
  • Separate directories
  • Split out API from UI
  • API in new Fields module, developed in contrib with aim of core
  • UI remains in contrib
  • Code-level methods for what is now UI-based
  • Still limited to nodes
  • A small number of sample fields converted
• Next steps
  • Further implementations (convert more core fields)

Further steps: entity models (bjaspan and crell; 15 minutes: 10 minutes presentation, 5 minutes questions)

• Entity model, providing unified operations for all first-level objects (users, nodes, etc.). Two ideas of how this would work. Begin with what the two have in common, then review each for differences.
  • model 1
  • model 2

Further steps: external data store support (nedjo; 5 minutes: 3 minutes presentation, 2 minutes questions)

• Existing Services module. Adapt for core?
• Introduce a parallel Clients implementation?

Concrete tasks and how to help (karenS; 5 minutes)

• Contributing to CCK adaptation
• Work on Services and Clients

Discussion (panel; 30 minutes)