Panels 2.0 design

After giving this a great deal of thought, I have worked up a preliminary
design for Panels 2.0. My primary design goal with this is flexibility,
so that panels can be used in a variety of situations. The example
situations I have come up with are the following:

o Panel as a page (this is what we currently have)
o Panel as a node -- some have mentioned missing this feature from the
  dashboard days.
o Panel as a framework for a node
o Panel as a framework for a page
o Panel as a framework for an organic group
o Panel as a framework for a user / user's 'homepage'.
o Panel as a framework for a user's blog

The first step in doing this is to break the existing panels module into
two parts. The first part is the core panels.module, which will exist only
as an API. The second part is the panels-page, which will probably be in the
same module as it should not be a very large amount of code and is probably
always useful.

The core panels API

o Provide a 'panel' object which consists essentially of just the basic
  layout plus the content that's in it.
o Load a panel object using a panel ID. Optionally named panels like Views
  but I haven't convinced myself this is necessary or a good idea.
o Provide UI to edit a loaded panel object
o Save a panel object
o Provide methods to load content into the editor.
o Provide methods to display the panel.

The panels-page module:

o Provide URL, menu items and access control to pages
o Link these pages to a panel
o Load all available content into the panel editor
o Display the linked panel within the page.

To accomplish this, page specific fields such as URL will be removed from the
panels table and moved into a panels_page (or along that lines) table. Also,
the block content type needs to be improved to support all existing block 
controls such as access control and url based filtering, plus supporting the
block configuration mechanism (even if that configuration is global and not
on a per panel basis unfortunately).

Once this is accomplished, we can start to fill out the above list.

The panels-node module:

o Provide a node type and/or CCK field that is a panel
o Load all available content into the panel editor and edit the panel during
  node edit.
o Display the linked panel within node view.

To go on with the rest of these, however, we need to do a little more to the
basic panel system. It needs a new content type, a type that is Panels aware.

The panel_content type:

o Is aware of panels and can take advantage of data that it may be preloaded
  with, such as URL arguments (can enhance panels-page), or some other data
  such as the current node or current user/node author.
o Can be provided globally or only used locally (i.e, provided to the editor
  only by modules that are aware of its existence).
o Panels itself would include, at the very least, the 'main content' content
  block which represents the primary content that is passed into the panel.
  This could be a node or a user profile, or even an entire page.

For example, the panels_og module could:

o Provide a bunch of panels_content types that are specific to groups, such
  as a series of views that follow a certain naming convention, plus other
  non-view content such as a list of group members, a group control block,
o Provides a method for the administrator of a group to attach a panel to
  the group and edit it.
o Displays that panel for the group node; uses that (or maybe a different)
  panel as the framework for nodes that are in the group. Using a choice
  of panels here would be wise; perhaps forum posts use a slightly different
  framework than event nodes.
o Sets the group or node being viewed as the 'main content' and requires
  the main content panel_content to be placed within the panel object once
  and only once.

For example, the panels_node_framework module could:

o Provide panel_content that is specific to a node. Examples might be 
  the prototypical profile block, related nodes, views that use 'nid'
  as the only required argument. Allows for other modules to specify
  that their panel content is suitable for the node framework (this would
  work really well for voting widgets and ecommerce widgets).
o Hook into the node view system to encapsulate the node as the main_content
  portion of the panel and display the panel.
o Allow the panel to be used to be selected by some combination of node type
  and/or taxonomy term.

For example, the panels_page_framework module could:

o Provide all block and panel content to the panel editor
o Provide a method to choose a panel based upon URL and/or some other
  criteria I haven't thought about.
o Hook into the page view to encapsulate a page as the main_content of
  the panel.

For example, the panels_my_blog module could:

o Provide content specific to users; allow other modules to specify their
  panel content as suitable for this module. Great examples are the profile
  block, recent comments on my posts view, etc.
o Allow users to create panels that be attached to their blog/home page
  and used as an overlay on their blog nodes.

In terms of implementation details, the panel_content is probably the
hardest part to design right. The content needs to be flexible; it
needs to be able to specify where it can be used, which means we need
to identify as many obvious uses as possible and hope that we cover
enough bases that similar uses can simply choose one of the options.
I'm thinking a hook to discover content types that returns an id and
enough information; and another hook that takes that id, the panel
info and can then provide the content. I don't want to have to cache this
data like we do in Views; I think this is feasible since we really only
need the whole list of content during the edit phase. The id should be
enough for the content render function to figure out what it needs to
do.

At this point, I ask for commentary!