The Future of Fields or, How Snow and Flu in Chicago Clarified What Drupal is Good For

Data Architecture Design Sprint I will embed our group photo on the porch in the snow here (I don’t have the memory card handy at the moment).

Goals of the DADS (or so we thought)‏ Re-design Drupal's core data architecture –Data API –Object modeling –Fields in core –Many related ideas Propose a design at Drupalcon –Voilà!

Our Grand Conclusions

Drupal’s raison d'être Drupal’s architecture allows contributed modules to easily add value to content.

The Future Web services –Consuming –Providing –Enhancing A monolithic web site is like an off-network computer –i.e. It’s useless.

The Path Forward Apply Drupal’s value-add contrib modules to web services Consume –Treat local and remote data as equals –Allow contrib’s value to apply to either Provide –A topic for another day

Data API needs Consistent set of methods for all entity types (user, node, etc.)‏ Defined set of fields with known structure and predictable representation

CCK Fields as model Already exemplifies much of what we are aiming for –schema aware –predictable representation—in db, in object Strong demand for fields in core—should be not an add-on option but a new model and step forward Ironically, admins have a richer set of tools than developers do

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

Fields in core: Minimal Code-level methods for what is now UI- based UI remains in contrib Still limited to nodes A small number of sample fields converted

Fields on Remote Data Drupal is a client of a remote service Remote service exposes entities and their fields Example implementation for D5/D6:generic module set plus supporter service

Clients module set

Specific client per external service

Field configuration

How You Can Help