I don't really know what the "politics" of module and feature development is or how things are co-ordinated, but I discovered today that the "Context" referred to by the ChaosTools/Panels world is not the Context module. Maybe this is just a timing issue, but I really think it's important this be given some thought, quick, before too much confusion abounds.

I have no allegiance or reason for favoring either, and as a total outsider, here are some observations (and I may be wrong, but here goes)...

  • The notion of context is a powerful site design tool. So powerful, that I can easily imaging many, many modules exploiting this to coordinate content display.
  • It appears that the "context" supported by Chaos Tools does not provide a management UI for contexts which is independent of panels and the rest of Chaos Tools.
  • If Chaos Tools context is extensible by other modules (which I assume it is), then there don't seem to be many modules using it, whereas the Context module is accumulating a small but loyal following of other modules supporting it.

This put us into quite a quandary. We'd LOVE to use the new Panels 3.0. However, the context support in Chaos Tools isn't nearly so comprehensive as that provided by the Context module, which we are already using (with amazing success). Instead, it appears to only provide limited context support within the "Panels world". If there is a UI that allows us to define and manage contexts for our entire site, please let me know, as we couldn't find it.

Moreover, it appears that Chaos Tools and the Context module are both duplicating a pretty essential site concept, in different ways, with little or no apparent communication. And, when searching the web people are using the word context to refer sometimes to one module, sometimes to the other. While everybody seems to embrace the concept it appears that a good implementation is going to be hampered by the "multiple chefs" phenomenon instead of agreeing on a separate, well-debugged API that everybody can use.

At this point the Context module appears to have a more pervasive feature set. But, it has problems that need addressing, particularly in the UI and terminology. But, I can say personally that is has solved myriads of problems in our complex site design and is reasonably solid technically. Maybe we could have solved all those problems if we had adopted Panels/Ctools months ago, but I don't think CTools context has the feature set or same architectural vision that Context does.

So now, all we can do is *sigh* and wonder if we just have wasted three months of development on adopting pervasive support for the Context module in our code. Which will win? Which will lose? Will they be compatible? Will there be two different ways of doing things tied to families of compatible and incompatible cousin-modules?

Please tell me that I am totally wrong and there is some brilliant scheme for adopting a site-wide Context API that empowers all modules and that this is just a temporary situation. I really don't want to have to discard the entire CTools/Panels3 world of modules just because it doesn't work with our existing commitment to the Context module implementation. I also don't want to throw out our existing context implementation too casually (months of work in some of our site-specific modules that use the Context API), if CTools/Panels3 rewrites aren't going to be the dominant way of doing things.

Comments

merlinofchaos’s picture

merlinofchaos commented

I haven't had the time to go look into context.module.

All I can say is that Panels was using a system named context back in 2006 and I am not likely to change. I don't entirely know what its featureset is. I do have a long term architectural vision, and that vision includes making the 'block' interface something you will never want to see again. From what I understand, context.module basically tries to make the block interface more usable. I've heard mixed reports as to its success.

The context developers have made no effort to contact me or do anything, and since context.module is johnny-come-lately to me, there really isn't a lot I can do. I don't really have the free time, between Views, Panels, a job and family, to go and actually do more. And I'm very sad that they chose to discard my work without having ever looked at it. But I have no control over that.

I would like a site-wide context API. I fear that the fact that I want to do things completely differently from Drupal core, and the addition of context.module means that we're just going to end up with a fairly large split in how things are done until one or the other truly wins is just how it's going to be.

I'm not sure what a site-wide management of contexts UI would look like. My vision of contexts is very much focused on a per-page setup, but it's entirely possible that sdboyer's idea of blueprints will be another gamechanger. If he ever gets the time to write it.

merlinofchaos’s picture

merlinofchaos commented

Another thing I don't know is whether or not there is some room for context.module and CTools idea of context to work together. Maybe there is, maybe there isn't. The two currently operate on a different scale.

garywiz’s picture

garywiz commented

It's not really a matter of what came first, I'm just noticing a problem that I think is a real one, and I doubt that anybody specifically tried to ignore anything or duplicate efforts, but it's happening anyway. Ironically, it's made a bit worse by the fact that the Context module is actually quite good! (Needs help, but very good.) If one implementation were bad, it would be easier. :-)

I also understand the home/family/kids thing and there is only so much that can be done.

We are actively working and coding with the Context module API now and it is having tremendous site benefits, so maybe we can work more actively to see whether there is some integration method or other way to assist. I'll post issues if it becomes relevant to progress, and thanks for the observations.

merlinofchaos’s picture

merlinofchaos commented

Someone on IRC mentioned that they do use Panels/CTools and context.module together on a site. Though obviously context in one doesn't translate to context in the other.

garywiz’s picture

garywiz commented

Yes, they appear work side by side without conflict.

I installed the new CTools/Panels 3.0 combo and they worked fine (very fine, indeed). The only problem is that we now have a pretty sophisticated site-plan which involves contexts as a driving force between how we will design and manage our new sites. Our developers know the word "context" as meaning something quite specific, and go right to the context module's settings page to manage various criteria which will cause blocks and pages to respond the way they want.

I suspect we're using contexts more than most. We have three separate context "namespaces" that we invented based upon our site plans:

* Focus (either community, promotional, or general)
* Page type (episode, community, show, forum, feature)
* Site (entertainment site, business site, insiders site) - we use domain tools to manage this across sites

So, our site design team laid out the sites so that the focus, page type, and site dictate what modules, "QuickTabs" blocks, page extras and menus should appear. It has been extremely good for creating a great information architecture template, and the whole "context" methodology has saved countless hours in trying to identify how certain page characteristics should be distributed, since context makes those characteristics quite literal.

In fairness, I have not used Panels since Panels 1.0, so I can't really contrast how we would have approached the site design. I suspect if timing were different we would have tried it both ways, but we are too far along now. I just point out the above as food for thought in considering how contexts were used by us, and I suspect by some others.

sdboyer’s picture

sdboyer commented

First, let me just clear up the technical point definitively - these two implementations of 'context' have nothing to do with each other, are architected towards different problems and operate within different paradigms, and the circumstances under which they collide are more coincidental than systemic. Now, the less pleasant bits.

Let me preface my comments by noting that the question over the context namespace is more of a sore point for me than it is for Earl. Let me also note that does not put me in a very receptive mood when you start out by describing yourself as "a total outsider" with "no allegiance or reason for favoring either," then proceed to lay out considerable experience with Context, but later reveal that you haven't really used Panels since 1.0. I have tried to make a point of seriously listening to folks when they want to talk to me about their experiences with context.module. But misrepresenting the the weight of your experience encourages me to perceive your case as disingenuous, not balanced.

There is a fundamental conceptual difference between the two approaches, one that I often describe as the difference between a "pull" (ctools/panels) and "push" (context) approach. The "push" approach is well characterized by one of your sentences:

...go right to the context module's settings page to manage various criteria which will cause blocks and pages to respond the way they want.

Context.module is essentially extending the concept of block visibility rules - when a block visibility rule is met, the block is shown, or 'pushed' out onto the page. Similarly, when the criteria for a context is met, changes to the output are 'pushed' out onto the page.

Panels has another layer - the panels display. It is due to these panels displays that Panels follows a 'pull' paradigm, whether or not there's any context involved - they're nothing more than an organized set of rules for pulling together, laying out, and styling content on a given page from a whole bunch of different sources. When a context is passed to the display, it's the panels display's rules that determine what additional content might be shown or hidden (pull), rather than the context itself deciding (push).

Note that pull vs. push are loose concepts and that the lines get murky under intense scrutiny. But the basic point is useful - the current primary implementation of ctools' contexts (Panels) is to hand data objects over and let the display handler figure it out; the underlying idea is about giving more data to the logic that's ultimately responsible for content rendering for that logic to do with as it pleases. The current primary implementation of Context, afaik, is about directly adding content to output via regions & the theme layer, the overall goal being the establishment of a sectioned experience. Again, these are the PRIMARY implementations, not an exhaustive account of what is possible with each system. But, as Earl and I have both said, the bottom line is that the current primary implementations operate in a different scope and with a different focus. I prefer a pull-based system, which makes it a no-brainer for me.

Having been through this discussion a few times, there are two potentially useful points I've come up with. First, YES, integration is possible. I'm not sufficiently up on context.module to be able to suggest ctools->context integration, but for context->ctools, I could see either of the following:

  • Context injecting itself as ctools-style context objects into (at least) Panels operations via the various provided alter hooks, then letting Panels do its pull-based thing from there.
  • Context injecting new content pieces directly into Panels display objects at runtime using the various provided alter hooks. This would be complex and difficult to implement, but could actually be _really_ cool if done well. Kinda best of both worlds, although it could also get nightmarish quickly.

Second, I think there are several discussions at very different conceptual levels going on in this thread, and that it's important we name it. ctools context is an API-level tool, which makes it (almost by definition) not "featureful" in the way that context.module is. The question - and it's an important one - of a global drupal context API/system/whatever is only marginally relevant to the term confusion at the UI level you've described. Either one of these systems could operate using the same underlying global contextualizing system, and coming up with one wouldn't resolve the ambiguity; one moves data objects around, the other pushes content. And I don't know how to say it without sounding snarky, but I think it's worse to leave it just implied, so Jeff, Young, Alex, et. all, please forgive me: in a situation where the same word is being used to describe two definably different concepts/processes, it does matter which came first. So garywiz, I think it's great (_seriously_) that context.module worked so well for your project, but the fact is, namespace is the only thing your approach really shares with the approach embodied in ctools' context.

garywiz’s picture

garywiz commented

Thanks for your well thought-out reply and I apologize if this issue has been rehashed many times.

I think both context implementations are far closer in vision than you think:

  • Both are API-level tools. Neither is "featureful" unless it is used for something. For Context, this is the "Context UI" which implements the block "pushing" you describe. For CTools, this seems to be used primarily right now for the Panels implementation. I don't believe either API is biased strongly toward how it is used.
  • Both have a plug-in architecture which allows context definitions to be defined and presented by other modules.
  • Both define a method to wrap context definitions using methods so they can be tested as single aggregate entities.

One strength of the Drupal community has been to identify strong base technologies (such as Views, CCK, etc.) and gradually migrate them to be more and more central. Of course, this saves code, saves time, and consolidates thinking around reusable APIs.

The notion of context is reaching a critical mass where lots of code and lots of time could be saved if it were consolidated into a good API, otherwise module after module will implement "contextual knowledge" in its own way.

While there are clearly different implementations, consider that code which builds a Drupal page may need to know:

  • If it is the front page or not (front-page context, built into core)
  • If it is associated with a particular user or not (user context, in core)
  • If it is associated with a particular organic group or not (og context, managed by og, but also now grafted onto ctools context, thus managed in two different ways)
  • If it is associated with a particular domain (domain module and its many offspring)
  • If it is in a privileged context (roles and permissions and many satellite modules implement this now)
  • If it is presenting a particular node or node type (CTools/Context both allow this plus much more).
  • If it is an admin page (many modules actually say arg(0)=='admin' as a way to determine this context).
  • If it is assigned to a particular taxonomy vocabulary or term.

I believe the list could be expanded to three times that size, or more. Worse, when deciding what should or should not appear on a page, the UI contains many redundant ways to do so, and developers must know a dozen different APIs and ways of detecting "context". The amount of code in Drupal across all modules to determine page context in ad-hoc ways is growing fast, and the amount one needs to know to build a complex page is growing along with it.

So, regardless of when they were both "born", both the Context module and the CTools context API provide a consolidated way to (a) aggregate context definitions into a single, extensible model and to (b) have a single way to test them. The point of my issue was not to say that one is better or one is worse, but to understand why multiple APIs are being developed to do, at some level (the name space level) the same thing, and whether one was going to be more widely adopted or not.

I appreciate your well considered reply and did not mean to appear "disingenuous". Maybe you misread my meaning when I said I was "an outsider" and had no allegiance to either module. Being an outsider to the community doesn't mean I lack experience. Just because I have worked with the Context module on our site doesn't mean I favor it or believe it is better. It has problems. I'd like to try an alternative, and have looked pretty extensively at the CTools context mechanism to determine how I could use it instead. And yes, I haven't worked with Panels actively since 1.0. I don't count "casual use" as experience. I have installed Panels 2 and 3 and used them quite extensively, just not in a production environment on a major site.

It sounds like the conclusion at this point is that there are many different ways of doing this, that the word "context" is used in different ways by different projects at different times, and there is no agreed-upon effort to create or use a single API.

Everybody has limited time and can't solve the worlds API problems. I do have some time to spend on this however, and the main purpose of my issue was to clarify where things are so that, if I do try to contribute patches or solutions, I do so in a way that's productive.

sdboyer’s picture

sdboyer commented
Status: Active » Closed (works as designed)

It's starting to really seem to me like you're not listening, and when folks stop listening, I tend to stop having conversations. But I'll allow for the possibility that we're just talking from really different perspectives about this and try again.

I think both context implementations are far closer in vision than you think:

* Both are API-level tools. Neither is "featureful" unless it is used for something. For Context, this is the "Context UI" which implements the block "pushing" you describe. For CTools, this seems to be used primarily right now for the Panels implementation. I don't believe either API is biased strongly toward how it is used.

I shouldn't have said anything about API-level vs. non-API level; it's subjective enough that it just muddies the lines further, and I don't want to go there. Other than that, you're really just rehashing parts of the points I made about why they're different. And I'm sorry, but your belief about the 'bias' of each code base is...well, a belief. It's not evidence in support of your position that the implementations are closer than I think.

* Both have a plug-in architecture which allows context definitions to be defined and presented by other modules.

This isn't a substantive similarity, it's just a good design practice. It's like saying "these modules are similar because they invoke their own hooks."

* Both define a method to wrap context definitions using methods so they can be tested as single aggregate entities.

Again, not a substantive similarity with respect to this discussion; it's mostly just good design practice. It makes the _vision_ no more similar than two segments of code utilizing a Visitor pattern.

One strength of the Drupal community has been to identify strong base technologies (such as Views, CCK, etc.) and gradually migrate them to be more and more central. Of course, this saves code, saves time, and consolidates thinking around reusable APIs.

The notion of context is reaching a critical mass where lots of code and lots of time could be saved if it were consolidated into a good API, otherwise module after module will implement "contextual knowledge" in its own way.

Time saved? Maybe, even probably - at least, after a huge investment of time up front. But code saved? These are generalizations, not arguments; you need to point to the duplicated code that could be unified, not just abstractly claim it's there. Again, just because they're both called 'context' doesn't mean they have so much overlap that we're both going to automatically experience a gain by unifying code.

While there are clearly different implementations, consider that code which builds a Drupal page may need to know:
* If it is the front page or not (front-page context, built into core)
* If it is associated with a particular user or not (user context, in core)
* If it is associated with a particular organic group or not (og context, managed by og, but also now grafted onto ctools context, thus managed in two different ways)
* If it is associated with a particular domain (domain module and its many offspring)
* If it is in a privileged context (roles and permissions and many satellite modules implement this now)
* If it is presenting a particular node or node type (CTools/Context both allow this plus much more).
* If it is an admin page (many modules actually say arg(0)=='admin' as a way to determine this context).
* If it is assigned to a particular taxonomy vocabulary or term.

First, let me just note - I wrote the context integration for og with ctools (though I wrote it eighteen months ago back when context still lived in Panels), and it is hardly "managed" in two different ways. It's same thin ctools context wrapper around the _exact_ same approach og itself uses to defining context - thereby enabling communication between og and panels/ctools. Which is what ANY attempt at a Grand Unified Context API will ultimately do - take contextual information and hide it behind a unified, accessible interface.

With that out of the way - I have a mixed reaction to this list. On the one hand, you have indeed illustrated the diversity of information that drupal needs to be cognizant of on every page request. And you're right that it is taxing on developers to need to be aware of all of the different means of doing it. But just because we can rope it conceptually into something that one can make a cogent argument counts as 'context' doesn't mean it should all be unified. Here's a counter-list:

  • The database connection information
  • Whether or not javascript is enabled in the user's browser
  • The server's php version
  • The requesting user's session id
  • The form id of a form that's being displayed
  • Whether or not modules X, Y, and Z are enabled
  • The state of any L10n
  • The currently active theme
  • If the requesting user is running Windows, Mac, or something else

The point is, almost ANYTHING can be considered context. Can you draw a clear line? I can't. Whether or not stuff gets called contextual has more to do with whether or not its relevant to what you're trying to do right now than any objective characteristic of the stuff itself. Sooner or later (and in my experience, it's sooner), wrapping stuff up to make it looks the same just ends up bloating everything and simplifying nothing. And, take the third item in that list - the user's session id. We do provide some methods for accessing that that protect the session information - those methods simplify working with sessions, which is part of why we do them, but we also do it to ensure stability and consistency in places where foregoing it could be, in this example, security risks. Not just 'cuz they fit Merriam Webster's definition of 'context.'

So, regardless of when they were both "born", both the Context module and the CTools context API provide a consolidated way to (a) aggregate context definitions into a single, extensible model and to (b) have a single way to test them.

Once again: we use ctools context to manage an enormous range of logic and data-moving problems in a systematic way within ctools, Panels, and other modules - and these points you're focused on are 85-90% irrelevant to that logic. I'm not remotely opposed to a Grand Unified Context API. I'd love it. I'm just trying to communicate to you that these two modules do really different things, and even if you don't believe it, coming up with such a grand unified API would not solve that problem. And also, maybe, highlight why pushing for changes to the 'context' idea that don't account for a large portion of what we use it for makes me more than a little uncomfortable.

The point of my issue was not to say that one is better or one is worse, but to understand why multiple APIs are being developed to do, at some level (the name space level) the same thing,

As I've said, namespace collisions and general similarities do not very similar, or even reconcilable, modules make - but your entire post here is premised on the idea that they ARE very similar, and reconcilable at a far deeper level than they are. In other words, your initial assumptions weren't correct. And I've already explained why these very basic differences makes the namespace collision even more of a sore point.

and whether one was going to be more widely adopted or not.

http://drupal.org/project/usage/ctools
http://drupal.org/project/usage/panels
http://drupal.org/project/usage/context

I also grepped over contrib to see what sort of dependencies I could find (note that this comparison does disproportionately favor ctools/panels, at least because there's a LOT in ctools besides context) Here's what has dependencies on context:

./context/Attic/context_prefix.info,v:50:dependencies = context
./context/context_contrib/Attic/context_contrib.info,v:54:dependencies[] = context
./context/context_prefix/context_prefix.info,v:60:dependencies[] = context
./context/context_prefix/context_prefix.info,v:86:dependencies = context
./context/context_prefix/context_prefix.info,v:108:dependencies = context
./context/context_ui/context_ui_contrib.info,v:66:dependencies[] = context
./context/context_ui/context_ui_contrib.info,v:67:dependencies[] = context_ui
./context/context_ui/context_ui_contrib.info,v:126:dependencies = context context_ui
./context/context_ui/context_ui.info,v:69:dependencies[] = context
./context/context_ui/context_ui.info,v:84:dependencies = context
./context/context_ui/context_ui.info,v:117:dependencies = context
./spaces/spaces.info,v:87:dependencies[] = context
./spaces/spaces.info,v:88:dependencies[] = context_ui
./spaces/spaces.info,v:89:dependencies[] = context_ui_contrib
./spaces/spaces.info,v:90:dependencies[] = context_prefix
./spaces/spaces.info,v:124:dependencies = og views context context_ui context_prefix@
./spaces/spaces.info,v:140:dependencies[] = context
./spaces/spaces.info,v:141:dependencies[] = context_ui
./spaces/spaces.info,v:142:dependencies[] = context_ui_contrib
./spaces/spaces.info,v:143:dependencies[] = context_prefix
./spaces/spaces.info,v:159:dependencies[] = context_contrib
./spaces/spaces.info,v:185:dependencies = views context context_ui context_ui_contrib context_prefix@
./ngpcampaign/ngpcampaign_events.info,v:41:dependencies[] = context
./ngpcampaign/ngpcampaign_media.info,v:74:dependencies[] = context
./ngpcampaign/ngpcampaign_issues.info,v:35:dependencies[] = context
./context_theme/context_theme.info,v:27:dependencies[] = context
./xslt_book/xslt_book.info,v:47:dependencies = context@
./xslt_book/xslt_book.info,v:57:dependencies[] = context
./features/features.info,v:45:dependencies[] = context

And on panels/ctools:

./dashboard/dashboard.info,v:60:dependencies[] = ctools
./panels_collapse/panels_collapse.info,v:30:dependencies = panels
./panels_accordion/panels_accordion.info,v:39:dependencies = panels
./panels_flexigrid/Attic/panels_flexigrid.info,v:34:dependencies = panels
./advanced_forum/advanced_forum.info,v:213:dependencies[] = ctools
./ecommerce/ec_checkout/ec_checkout.info,v:163:dependencies[] = ctools
./ecommerce/ec_customer/ec_customer.info,v:175:dependencies[] = ctools
./ecommerce/ec_receipt/ec_receipt.info,v:200:dependencies[] = ctools
./panels_plugin_example/panels_plugin_example.info,v:28:dependencies[] = panels
./panel_style/panel_style.info,v:44:dependencies[] = panels
./panel_style/panel_style.info,v:45:dependencies[] = panels_mini
./panel_style/panel_style.info,v:68:dependencies = views panels panels_mini
./panels_sections/panels_sections.info,v:30:dependencies[] = panels
./panels_sections/panels_sections.info,v:31:dependencies[] = panels_page
./nodereference_views_select/nodereference_views_select.info,v:72:dependencies[] = ctools
./custom_breadcrumbs/custom_breadcrumbs_panels/Attic/custom_breadcrumbs_panels.info,v:49:dependencies[] = panels
./custom_breadcrumbs/custom_breadcrumbs_panels/Attic/custom_breadcrumbs_panels.info,v:50:dependencies[] = ctools
./views_bonus/Attic/views_bonus_panels_threecol_term.info,v:65:dependencies = views panels
./views_bonus/Attic/views_bonus_panels_threecol_term.info,v:105:dependencies = views panels
./views_bonus/Attic/views_bonus_panels_threecol_stk.info,v:65:dependencies = views panels
./views_bonus/Attic/views_bonus_panels_threecol_stk.info,v:105:dependencies = views panels
./views_bonus/Attic/views_bonus_grid.info,v:103:dependencies = views panels
./views_bonus/Attic/views_bonus_grid.info,v:125:dependencies = views panels
./views_bonus/Attic/views_bonus_panels.info,v:48:dependencies = views panels
./views_bonus/Attic/views_bonus_panels.info,v:78:dependencies = views panels
./views_bonus/Attic/views_bonus_panels_twocol.info,v:65:dependencies = views panels
./views_bonus/Attic/views_bonus_panels_twocol.info,v:105:dependencies = views panels
./views_bonus/Attic/views_bonus_panels_twocol_stk.info,v:65:dependencies = views panels
./views_bonus/Attic/views_bonus_panels_twocol_stk.info,v:105:dependencies = views panels
./views_bonus/Attic/views_bonus_panels_threecol.info,v:65:dependencies = views panels
./views_bonus/Attic/views_bonus_panels_threecol.info,v:105:dependencies = views panels
./views_bonus/panels/views_bonus_panels.info,v:30:dependencies[] = panels
./resizable_body/resizable_body_panels/Attic/resizable_body_panels.info,v:52:dependencies[] = panels
./siteminder/siteminder.info,v:31:dependencies[] = ctools
./advanced_profile/advanced_profile.info,v:279:dependencies = panels views
./advanced_profile/advanced_profile.info,v:294:dependencies = panels
./advanced_profile/advanced_profile.info,v:336:dependencies = panels content
./openlayers/openlayers.info,v:132:dependencies[] = ctools@
./analytics/analytics.info,v:36:dependencies[] = ctools
./amazon_store/amazon_store.info,v:55:dependencies[] = panels
./panels_scheduler/panels_scheduler.info,v:43:dependencies[] = panels_node
./panels_fe/Attic/panels_fe.info,v:44:dependencies = panels
./ngpcampaign/ngpcampaign_events.info,v:44:dependencies[] = panels
./ngpcampaign/ngpcampaign_media.info,v:44:dependencies[] = panels
./ngpcampaign/ngpcampaign_issues.info,v:38:dependencies[] = panels
./fieldtool/fieldtool.info,v:59:dependencies[] = ctools
./topichubs/topichubs_panels/topichubs_panels.info,v:41:dependencies[] = panels_node
./topichubs/topichubs_panels/topichubs_panels.info,v:58:dependencies[] = panels_node
./datasync/datasync.info,v:74:dependencies[] = ctools
./datasync/datasync_scheduler/Attic/datasync_scheduler.info,v:69:dependencies[] = ctools
./panels_tabs/panels_tabs.info,v:62:dependencies = panels tabs
./panels_tabs/panels_tabs.info,v:122:dependencies[] = panels
./linodef/modules/linodef_buttonsapi/Attic/linodef_buttonsapi.info,v:108:dependencies[] = ctools
./asset/contrib/asset_panels/asset_panels.info,v:31:dependencies = asset panels
./asset/Attic/asset_panels.info,v:60:dependencies = asset panels
./asset/Attic/asset_panels.info,v:106:dependencies = asset panels
./asset/asset_panels/Attic/asset_panels.info,v:69:dependencies = asset panels
./asset/asset_panels/Attic/asset_panels.info,v:98:dependencies[] = panels
./ctools/bulk_export/bulk_export.info,v:38:dependencies[] = ctools
./ctools/delegator/Attic/delegator.info,v:46:dependencies[] = ctools
./ctools/page_manager/page_manager.info,v:38:dependencies[] = ctools
./ctools/ctools_plugin_example/ctools_plugin_example.info,v:29:dependencies[] = ctools
./ctools/ctools_plugin_example/ctools_plugin_example.info,v:30:dependencies[] = panels
./ctools/views_content/views_content.info,v:41:dependencies[] = ctools
./data/data.info,v:63:dependencies[] = ctools
./og_collections/og_collections.info,v:33:dependencies = og panels panels_views og_panels@
./feedapi_mapper/feedapi_mapper.info,v:117:dependencies[] = ctools
./panels_carousel/panels_carousel.info,v:86:dependencies = panels jcarousel
./transformations/ui/transformations_ui.info,v:47:dependencies[] = ctools
./transformations/ui/transformations_ui.info,v:89:dependencies[] = ctools
./transformations/transformations.info,v:104:dependencies[] = ctools
./panels/panels_node_content/panels_node_content.info,v:44:dependencies[] = panels
./panels/panels_views_legacy/Attic/panels_views_legacy.info,v:60:dependencies = panels views
./panels/Attic/panels_page.info,v:73:dependencies = panels
./panels/Attic/panels_mini.info,v:59:dependencies = panels@
./panels/Attic/panels_node.info,v:55:dependencies = panels
./panels/panels_node_legacy/Attic/panels_node_legacy.info,v:75:dependencies = panels
./panels/panels_node_legacy/Attic/panels_node_legacy.info,v:110:dependencies = panels
./panels/panels_node/panels_node.info,v:76:dependencies[] = panels
./panels/panels_node/panels_node.info,v:92:dependencies = panels
./panels/panels_node/panels_node.info,v:115:dependencies = panels
./panels/panels_export/panels_export.info,v:82:dependencies[] = panels
./panels/panels_export/panels_export.info,v:107:dependencies = panels
./panels/panels_export/panels_export.info,v:129:dependencies = panels
./panels/panels.info,v:160:dependencies[] = views ctools
./panels/panels.info,v:175:dependencies[] = ctools
./panels/panels_simple_cache/panels_simple_cache.info,v:73:dependencies[] = panels
./panels/panels_simple_cache/panels_simple_cache.info,v:107:dependencies = panels
./panels/panels_views/panels_views.info,v:67:dependencies[] = panels
./panels/panels_views/panels_views.info,v:103:dependencies = panels views
./panels/panels_views/Attic/panels_views.info,v:54:dependencies = panels views
./panels/panels_mini/panels_mini.info,v:83:dependencies[] = panels
./panels/panels_mini/panels_mini.info,v:111:dependencies = panels@
./panels/panels_mini/panels_mini.info,v:133:dependencies = panels@
./panels/panels_page/panels_page.info,v:98:dependencies[] = panels
./panels/panels_page/panels_page.info,v:142:dependencies = panels
./panels/panels_page/panels_page.info,v:179:dependencies = panels
./total_control/total_control.info,v:74:dependencies[] = panels
./taxomenu/taxomenu.info,v:43:dependencies = panels_page taxonomy
./taxomenu/taxomenu.info,v:57:dependencies = panels_page,taxonomy
./og_blueprints/og_blueprints.info,v:43:dependencies = og panels panels_views og_panels@
./i18n/contrib/Attic/i18npanels.info,v:51:dependencies = i18n panels
./domain_ctools/domain_ctools.info,v:31:dependencies[] = ctools
./panels_titles/panels_titles.info,v:29:dependencies = panels
./panels_taxonomy/panels_taxonomy.info,v:38:dependencies = taxonomy panels
./og_panels/og_panels.info,v:30:dependencies[] = panels
./og/modules/og_panels/Attic/og_panels.info,v:249:dependencies[] = panels
./og/modules/og_panels/Attic/og_panels.info,v:250:dependencies[] = panels_views
./og/modules/og_panels/Attic/og_panels.info,v:277:dependencies[] = ctools
./og/modules/og_panels/Attic/og_panels.info,v:293:dependencies[] = panels_views
./og/modules/og_panels/Attic/og_panels.info,v:308:dependencies[] = ctools
./og/modules/og_panels/Attic/og_panels.info,v:410:dependencies = og panels panels_views@
./og/modules/og_panels/Attic/og_panels.info,v:432:dependencies = og panels panels_views@
./og/Attic/og_panels.info,v:88:dependencies[] = panels
./og/Attic/og_panels.info,v:89:dependencies[] = panels_views
./og/Attic/og_panels.info,v:127:dependencies = og panels panels_views@
./og/Attic/og_panels.info,v:149:dependencies = og panels panels_views@
./panelsblock/panelsblock.info,v:41:dependencies = tabs panels
./feeds/feeds.info,v:34:dependencies[] = ctools
./pressflow_preempt_panels/pressflow_preempt_panels.info,v:44:dependencies = pressflow_preempt panels
./wysiwyg/wysiwyg.info,v:121:dependencies[] = ctools
./wysiwyg/wysiwyg.info,v:198:dependencies = libraries ctools jquery_update jquery_ui debug
./wysiwyg/wysiwyg.info,v:212:dependencies = libraries ctools jquery_update jquery_ui popups debug
./feedapi_eparser/feedapi_eparser.info,v:45:dependencies[] = ctools
I appreciate your well considered reply and did not mean to appear "disingenuous". Maybe you misread my meaning when I said I was "an outsider" and had no allegiance to either module. Being an outsider to the community doesn't mean I lack experience. Just because I have worked with the Context module on our site doesn't mean I favor it or believe it is better. It has problems. I'd like to try an alternative, and have looked pretty extensively at the CTools context mechanism to determine how I could use it instead. And yes, I haven't worked with Panels actively since 1.0. I don't count "casual use" as experience. I have installed Panels 2 and 3 and used them quite extensively, just not in a production environment on a major site.

OK, thanks for clarifying.

It sounds like the conclusion at this point is that there are many different ways of doing this, that the word "context" is used in different ways by different projects at different times, and there is no agreed-upon effort to create or use a single API.

Everybody has limited time and can't solve the worlds API problems. I do have some time to spend on this however, and the main purpose of my issue was to clarify where things are so that, if I do try to contribute patches or solutions, I do so in a way that's productive.

There's no agreed-upon effort because, at minimum, no one has made a convincing case that the marginal benefits outweigh costs. And I'd welcome patches - it would give us something concrete to talk about. But I'll also put out the caveat that I think you need to be a lot more precise about what problem you're trying to solve before you start rolling patches - I'll definitely be a lot more receptive.

garywiz’s picture

garywiz commented

Well, I think you've been pretty receptive so far, so thanks.

I don't think the benefits are marginal at this point, mainly because I see code being written to solve the problem of visibility contexts in a generic way, and people gradually adopting it. Such efforts appear to reflect a growing need. Yes, I think it's early to claim that a sweeping context management framework is a high priority. It's a low priority in the grand scheme of Drupal's framework. But, noticing it early and discussing it can't be a bad thing.

The point is, almost ANYTHING can be considered context. Can you draw a clear line? I can't. Whether or not stuff gets called contextual has more to do with whether or not its relevant to what you're trying to do right now than any objective characteristic of the stuff itself.

Here is a rough start at pinning this down: "Any time a visibility condition is exposed to the user by more than one independent module, it is a candidate for integration into a context framework."

This cuts to the core of why a context framework is useful and helps tell the difference between the "server's php version" and the "path template for the current page". The latter is consistently exposed in the UI for making decisions about content visibility, the former is not. The only real reason for considering something context is because it is being shown to users as part of their page-building toolkit.

I'm not sure whether code is saved and that is a tough argument to make soundly at this point, I agree. But, complexity for the user is reduced and a methodology is created that saves time for the user and designer as a site becomes more and more complex.

Ignoring the painful process of choosing which modules to use, the current methodology for creating a site is:

  1. Build a site map or site plan.
  2. Map that plan into pages consisting mostly of different types of nodes, views, and panels.
  3. Determine on a case-by-case basis how various display modules can adorn those pages with related information or utility functions.

Of course, the site map or site plan usually needs to be constrained, or at least have consideration for what is possible. This used to be simple. Most people building Drupal sites were technical. At first it was easy to build a site plan because "nodes" were the lingua franca of site design in Drupal. Even when the CCK came along, it was still a matter of segregating the site into nodes of different types. Blocks and menus were adornment and utilities, but still manageable in the mind of the site designer. Non-technical site designers could even grok this world of "components".

Then came views. Panels. Advanced theming with extensive control of page templates. Add module after module which attempts to add richness and flexibility to the way each page can be designed. The non-technical site designer now is completely at a loss to determine "what can Drupal do?" And this is not good, as larger site design teams contain specialists in design, IA, user experience, content, and software. Bridging the gap between technical internals and site design terminology is why so many CMS systems resort to "fixed models" using literally created sitemaps like Silverstripe or the notion of channels like Vignette. While these are limiting in some ways, they establish a technical framework that is conceptual so that design concepts can be directly translated into configuration clicks.

So, an alternative methodology might be:

  1. Build a site map or site plan.
  2. Map that plan into pages. Assign various sections of the one or more contexts, at first informally. For each context, determine how pages may be themed differently and what optional content is present in various contexts.
  3. Create a specific set of contexts based upon the site plan.
  4. Build the page using nodes, views, panels, blocks and other elements using context to control conditional content.

I know this might seem inprecise rather than pinning down specific technical requirements. But, I have some pretty concrete empirical evidence that the concept of context is something that both non-technical and technical people can embrace and use to define the concrete elements of a site. It's a lot better than talking to site designers about nodes, views, blocks, panels, nodequeues, and pathauto and the combinatorial algorithm for what might or might not appear on their pages. For us, the end result has been that our site is easier for the non-technical content managers (we have 3 of them) to understand and change without as much technical assistance and most importantly, the concepts used in the admin UI reflect the concepts that were present in the site plan.

I apologize for taking up as much of your time as I have, and I hope that the thread of discussion at least benefits somebody at some point. I also realize that turning these theories into code is the best way to test them, so will be trying some context alternatives using ctools just to see what happens.

garywiz’s picture

garywiz commented

I just keep coming across examples of people trying to implement generic solutions, usually related to blocks of course:

  • Visibility API - API for controlling visibility of arbitrary elements.
  • OG Block Visibility - Displays blocks conditionally based upon group context.
  • Domain Blocks - Similar to the above, except that it adds domain context criteria to blocks configuration.
  • Block Node Visibility - Extends the block interface to include node types as an additional context besides the normal path templates.
  • Region Manager - Allows selection of blocks which will appear on a page based upon page context (uses a novel method to determine context).
  • Region Visibility - Allows entire regions to be hidden or shown based upon role or page context.
  • Sections - Allows you to identify site sections and control visibility based upon role, page context (regex paths), or "custom php visibility snippits".
  • Block Page Visibility - Creates a way to consolidate block visibility decisions into a single php function.

There are many others that incorporate nodetype and path-based context as part of their functioning, but the above appear to offer context recognition as their primary benefit. Obviously, blocks are the biggest focus since the relationship between blocks and other page content is a major information design issue.

sdboyer’s picture

sdboyer commented

@garywiz - sorry, I've been NUTS the past week and a half. I'll respond more soon.

EvanDonovan’s picture

EvanDonovan commented

Subscribing. This is an interesting discussion.

frankcarey’s picture

frankcarey commented

yes, interesting. I've written (and just upgraded to panels 3) a location_context plugin for panels that that allows for location module location contexts (just country for now) in panels. I also just started a context_rules module to allow you to set context module contexts based on rule conditions, so I'm familiar with both APIs. I'm seeing definite room for cross pollination here. For instance:

1) Ctools could expose it's contexts to the context module, so that the context_ui module could control blocks and regions using ctools logic

2) Context module could provide "ctools context" hooks so that you could set page variants based on context module contexts.

Thoughts?

frankcarey’s picture

frankcarey commented

Also I think it's interesting to note the context module's description in the modules page. "Provide modules with a cache that lasts for a single page request." Kind of an odd description, but it gets to the heart of what's happening in the context module. At it's core, you basically are setting and getting triplets in memory, where the triplets are namespace, attribute, and value. If panels were to integrate, it could simply set something like this when viewing a user override page for the admin user:

Namespace: ctools_user

Attribute: uid

Value: 1

It could even set multiple context triplets as needed...

Namespace: ctools_user

Attribute: is_self

Value: FALSE

merlinofchaos’s picture

merlinofchaos commented

Frank: I would consider patches that are low impact.

colorado’s picture

colorado commented

This was a really interesting and helpful discussion. Thank you to the participants.

NKaush’s picture

NKaush commented

garywiz, I cant help but appreciate your point. Being a non-technical newbie myself, I just seem to be going in circles around panels, blocks, themes, node heirarchy, node relativity, node reference etc for the past two weeks in trying to get output on a "page". I havent even looked at books, menus, ogs etc yet as I'm already overwhelmed at this point.

davidburns’s picture

davidburns
he/him
Primary language English
Location Philadelphia
commented

subscribe

lpalgarvio’s picture

lpalgarvio commented

subscribing as well

see butler project:

Working in-progress code for the "Butler" context system for Drupal 7 (contrib) and Drupal 8 (core). It's not fully functional yet and nothing is guaranteed stable in the API, but you can certainly give it a whirl and try to get involved. :-)

http://drupal.org/project/butler

and context/butler group:

The Web Services and Context Core Initiative (WSCCI) aims to transform Drupal from a first-class CMS to a first-class REST server with a first-class CMS on top of it. To do that, we must give Drupal a unified, powerful context system that will support smarter, context- sensitive, easily cacheable block-centric layouts and non-page responses using a robust unified plugin mechanism.

http://groups.drupal.org/wscci

context and butler:

Phase 1: Context

Drupal derives a lot of information out of the HTTP request. There is a lot of information there, too, and from that information we extract all sorts of information: What node is currently being viewed, what page callback to use, who the current user is, what the language of the site should be, and dozens of other important facts. However, there is no consistent way to do so. Every system and every module must invent their own way of doing so, usually with some global function or global variable. In order to build a more robust REST server within Drupal, we need to unify that contextual information in to a coherent and integrated system.

The solution here is to wrap the HTTP request into a single, extensible context object. That context object will act as a central gateway to information coming from the client (who may not be a user at all) as well as information we derive from it, such as the current node, current user, and so on.

By providing an integrated, extensible system for contextual information, we can build a more coherent, robust, flexible response system on top of it.

layout and butler:

Phase 4: Layouts

That doesn't mean that our HTML page generating system can't improve. In fact, those same underlying tools should make it possible to build a new, plugin-based, context-aware page rendering system as simply one response controller among many. We already have a solid conceptual model to follow here: Drupal's own Panels module, which has shown itself to be a very robust and effective way to build much more complex pages than Drupal natively supports. With a more context aware front-end system, we can also more easily tie into other important technologies such as ESI, or even implement them ourselves within Drupal.

http://www.garfieldtech.com/blog/web-services-initiative

lpalgarvio’s picture

lpalgarvio commented

Context OR Butler module integration:
http://drupal.org/node/1211388

Rules module integration:
http://drupal.org/node/1211368