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:

• Panel as a page (this is what we currently have)
• Panel as a node -- some have mentioned missing this feature from the dashboard days.
• Panel as a framework for a node
• Panel as a framework for a page
• Panel as a framework for an organic group
• Panel as a framework for a user / user's 'homepage'.
• 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

• Provide a 'panel' object which consists essentially of just the basic layout plus the content that's in it.
• 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.
• Provide UI to edit a loaded panel object
• Save a panel object
• Provide methods to load content into the editor.
• Provide methods to display the panel.

The panels-page module:

• Provide URL, menu items and access control to pages
• Link these pages to a panel
• Load all available content into the panel editor
• 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:

• Provide a node type and/or CCK field that is a panel
• Load all available content into the panel editor and edit the panel during node edit.
• 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:

• 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.
• Can be provided globally or only used locally (i.e, provided to the editor only by modules that are aware of its existence).
• 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:

• 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,
• Provides a method for the administrator of a group to attach a panel to the group and edit it.
• 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.
• 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:

• 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).
• Hook into the node view system to encapsulate the node as the main_content portion of the panel and display the panel.
• 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:

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

For example, the panels_my_blog module could:

• 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.
• 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!