version: 6.x (that version is not selectable)

I am trying to clean up the context_ui module, remove all module_exists calls, and move the functionality to submodules. I think this way the code is more flexible, new external module features can be added faster and easier. Unnecessary functionality can be disabled.

This is the the initial patch, menu and block functionality is not removed from context_ui.
Added a new submodule, for integration with the "sections" module.

I can't create a patch for new directories, so the new submodule files are in the tar.gz file..

CommentFileSizeAuthor
#1 context_modules_286336_2.patch13.28 KBpasqualle
#1 context.tar_.gz.txt3.76 KBpasqualle
context.tar_.gz.txt2.67 KBpasqualle
context_modules.patch9.59 KBpasqualle

Comments

pasqualle’s picture

pasqualle
Location 🇭🇺 Budapest
commented
StatusFileSize
new context.tar_.gz.txt3.76 KB
new context_modules_286336_2.patch13.28 KB

menu functionality removed from context_ui
added new submodule for integration with css_injector

yhahn’s picture

yhahn commented
Assigned: Unassigned » yhahn

Thanks for the patch -- I share your concerns about bloating context_ui with optional functionality and unnecessary module_exists calls.

The plan is to get to a stable 1.0 release and then push to get small patches into each of the integrating modules (Views/Panels/Nodequeue/Outline/etc.) since the integration is generally a very small and unobtrusive amount of code.

I will look first at breaking integration against non-core modules (I think support for core modules can stay in context_ui for now) into includes until a release. Once that happens, it would be great to look again at pushing these changes upstream rather than fragmenting the functionality of context_ui into sub-modules.

Would you be interested in submitting patches against sections and css_injector for integration with context_ui?

pasqualle’s picture

pasqualle
Location 🇭🇺 Budapest
commented

reading your last sentence again, I am not sure you asked this
#288564: context: css_injector, sections

but I think if I submit patch against css_injector, then the half of code in css_injector module will be unnecessary, and also there is a missing hook and a setting to fully integrate with context_ui.

missing hook: response to context..
missing setting: where to display, setter or getter..

pasqualle’s picture

pasqualle
Location 🇭🇺 Budapest
commented

I would suggest to move all external module code out from context_ui, into submodule. Only core-required modules should remain in context_ui. Solve the issues "inhouse" and when it works perfectly, then ask other modules to take the integration code. We could test, add as many external modules as we can..

Issues for better integration:
The integration should work without the context_ui module being enabled.
More options for item selection. checkboxes will not be enough.
Better user interface. If we integrate more than 20 modules, the page will be too long..
Hook for context response.

yhahn’s picture

yhahn commented

Thanks Pasqualle -- I think this is a good path to take. I have begun work on these issues. I've committed the changes to the DRUPAL-5 and HEAD branches, see http://drupal.org/cvs?commit=131333

  • Added "multiple" boolean to items defined in hook_context_items(). If true, options get rendered as checkboxes. If false, options are rendered as radios. Let me know what other item selection needs you see coming up -- I think for now this should suffice.
  • "Hook for context response": I've added another key, "type" in hook_context_items() that should be set to either "setter" or "getter". This controls where the options appear on the form. There's more to do here -- see below.

Next steps:

  • I will split the contrib module integration out into a context_ui_contrib module or so. Once this is done, I can integrate your sections + css injector patches into it.
  • "The integration should work without the context_ui module being enabled." -- I'm not sure I understand this? Could you please clarify what you mean?
  • "Hook for context response": I'm still thinking about the best way to do this, but I agree that this will be needed as currently the only real response actions (menu and block) are both hard-coded in to respond to context. I'll look at your implementation of sections/css injector for some ideas on how to abstract this better.

Thanks for your patience -- hopefully I'll have this cleaned up soon so that I can commit your patches.

pasqualle’s picture

pasqualle
Location 🇭🇺 Budapest
commented

The commit seems nice, it is a good step forward..

item selection: I think context_ui will need textfield filters in the future, something like views 2 has. But it is not necessary for now. I would like to see some kind of plugin system, where these selectors (filters) can be defined..

context_ui need to be enabled: I mean when you disable the views_ui module, your views still work, but if you disable the context_ui module, your context settings does not work any more, because the functionality is inside the context_ui. This should be redesigned..

Thanks for your work, I think this could be a very useful module for Drupal.

yhahn’s picture

yhahn commented

Ah, now I understand what you mean.

The issue here is historical -- the core context module actually provides a much simpler set of tools that can be put to various interesting uses (e.g. context_ui, context_prefix) and we've wanted to keep that module as the core set/get API functions.

Context_ui came about as a way to expose to everyday users what we were actually doing on a lot of projects in code (we would implement "sections" using context set/get, block visibility, theme rules, etc. directly in the code using hook_nodeapi, hook_form_alter, etc., etc.).

For now, I think it should be fine to leave this module's UI and core functionality unified. We've got plenty of other stuff to work on until this really becomes an issue ; )

yhahn’s picture

yhahn commented
Status: Needs review » Fixed

http://drupal.org/cvs?commit=131366

Contrib module functionality has been split out into a single context_ui_contrib.module as discussed. Eventually, it would be best if this type of integration moved upstream.

Closing this issue.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.