Transition from Context to Panels? [#809864]

Both Context and Panels are powerful systems for placing context-aware content on a page.

I think Panels might be a better choice for COD for a few reasons (keeping in mind that Panels has an idea of Context that's not context.module ;) ):

- Panels provides configurable page layouts based on context.
This seems useful for changing the layout for time-dependent pages like a session page based on whether it's in the past or future, since users have different motivations in those times. Before the session, folks might want to know who is presenting, where and when the presentation is taking place. Afterward, they are likely more interested in session notes, slides and video.

- Panels is a tool that's intended for non-developers, as well as developers.
Part of my intention for COD is to make it possibly for non-developers to run a sophisticated event site. Panels makes more control available for non-developers than Context.module, which is largely a developer tool. Context requires templating to change a page layout
Clearly though, both are sophisticated tools and require the operator to learn some amount of new concepts and jargon.

One question that comes to my mind about a Panels implementation is

- Can we run a Features comparrision against a changed panel to see what's been reconfigured from what COD provided out of the box? This seems valuable for an installation profile.

Comments

Comment #1

populist commented 31 May 2010 at 07:01

In general, I think that Panels is a great tool for building "Drupal Products" and could do a lot to benefit COD specifically. We built the Drupalcon SF site using Panels and it allows for a site customization to happen quickly which is necessary in an event/conference environment. A few points worth mentioning:

1.) There is a lot of work going into making Panels have an In Place Editor (http://drupal.org/node/785576) for the front end of the system. This will allow a user to hit "customize" and be able to add/edit/move/delete the elements of their site.

2.) The ability to create custom Panel Panes has a lot of potential for a product because you can easily create an inventory of elements that a user might want to drop on a site (most recent sessions, most recent users, etc) and allow all sorts of customization beyond that. It also is pretty easy to add new custom Panel Panes which can be dropped in wherever.

3.) There is solid feature support for Panel Pages (through Ctools exportables) and all of the related elements (Layouts, Panes, Tasks, etc) exist cleanly in custom module code.

4.) Layouts can be changed easily to meet different use cases without having to write a lot of theme code.

Comment #2

brentratliff commented 17 August 2010 at 01:13

We used Panels and Context together to create some of the Drupalcamp Atlanta pages including variants for session nodes, sponsors, and user profiles. Context set the active primary menu links and sidebar items on all pages while Panels controlled everything in the content area with a one column panel for the variants we set. It would be very easy for a non-technical content editor to drop blocks, nodes, etc generated from the 'features' into the content panels. We currently are not using Panels 3.7 with the inplace editor because it breaks Skinr, which we are also using with our Fusion subtheme. Once we test the available patch for the Skinr fix, we will upgrade Panels. From a development standpoint, it was easier for me to set the sidebar items that made sense along with the active primary menu to divide the site into logical sections. I went with Context for the sidebar and menu reactions and disabled the Context U/I for the content editors. They still have edit ability for the content region itself in Panels. I guess it comes down to how much control you want someone to have since both Panels and Context play nice with Features. If I were creating a distribution that needed a more flexible use case, using Panels to control the entire page may be the way to go. I'm happy to export the Panels and Contexts we used into a feature.