There are a few things where I would love some work to be focused on Views. There are people who have interest in various places that I think may make some things obvious choices for some people.

1) I want the theming wizard to have bells and whistles. I want a user to go click click click and have exactly the right code to do anything he wants with a view. The biggest hurdles to themeing views is identifying function names and identified field info. The list view does a good job with the field info, but it doesn't go far enough, as it doesn't tell you how to theme a handler. For yes, the handlers can be themed. And it also needs something that can do tables. And do lists in different ways. THey don't have to be ul lists. They could be just some divs. who cares.

• Standard set of hooks to allow modules to express relationships and query them
• Requirements (based on discussions at OSCMS Vancouver 2006):
  • Pluggable frontends (ways of entering and viewing relationships). Experience has shown that there are many different ways relationships can be created and presented to users. See the 'Relationship UI' child page for a simple frontend.
  • Pluggable backends (ways of storing/retrieving or deriving relationship data). Experience has shown that some modules will need direct control of the relationship storage space. See the 'Network Relationships', 'Hierachical Relationships' and 'CiviCRM Relationships' child pages for example backends.
  • Extensible
  • Works with both 1-1 and 1-many relationships
  • Object neutral - can relate nodes, users, comments, relationships, URIs
  • Can retrieve direct relationships (e.g. friend - L1) as well as as indirect relationships (e.g. friend-of-a-friend - L2, friend-of-a-friend-of-a-friend - L3 etc)
  • Can retrieve relationships taking into account direction (e.g. only parents or only children) or ignoring direction (e.g. relatives)

  Additional requirements for discussion:

  • Each relationship type can be a node - easily extensible with metadata explaining what this relationship 'means'. Additionally - or alternatively - we could allow a simple keyword to define the relationship type.
  • Split off the API from the 'standard' backends and frontend to make it easier to maintain and add to core.
  • Direct (L1) relationships could be cached with the node - we could even 'grow' the node relationship cache for higher level relationships as they are requested, possibly with certain limits.
  • Relationships can be directional or non-directional - we could track this with the relationship type (i.e. if the relationship type has an 'inverse' then it is directional).
• Potential use cases for relationships in Drupal
• Node authorship (multiple authors!)
• Taxonomy (which is relating to a point in a taxonomy tree, which can also be created using relationships)
• Media or other attachments to a node
• Web Links (relating to an external URI) - these could optionally be picked up from the node body and/or tracked using weblinks.module
• Event and volunteer signups
• Comment threading
• Metadata in general
• Tracking users buddies
• Tracking user content likes/dislikes
• Adding AI-like capabilities 'If you liked this, you'll love...'
• Lastly, but certainly not least - the semantic web (RDF, FOAF...) revolution!
• Potential DEP Dependencies:
  • Users, comments, taxonomy terms and attachments become nodes. Without this DEP the RAPI would be significantly more complex, because of the need for either a table mapping 'object-ids' to node, comment and user ids, or tracking the tables in question directly with each relationship

This is simple query to the group. I am going to go check out the forums as well.

I am not a ninja themer. But I am not a newbie either. I've done about 4 themes for drupal now. All have been variations of existing themes.

My questions have to do wth table-based vs liquid lay-outs.

1/ What do people recommend as a framework for building liquid lay-outs? I have tried doing up my own version of the ALA holy grail thingme, and I have tried modifying the civicspace theme, and in neither case have I enjoyed the process. Are there her techniques that don't require such wholesale manipulation of the browser-space?

If you're interested in a San Diego BarCamp, please indicate so here:

http://barcamp.org/BarCampSanDiego