Attached is a quick experimental module: Views Area.

It allows module developers to quickly add new 'area' elements to Views without having to ever again need to put PHP in Views output. It does so by registering hook_views_area_info() to create custom area handlers that are all controlled by this module.

Example:

/**
 * Implement hook_views_area_info().
 */
function views_area_views_area_info() {
  $areas = array(
    'test' => array(
      'title' => t('My test'), // Required
      'help' => t('Test an area callback'), // Required
      'form_callback' => 'views_area_form_test', // Optional <-- discarded by Views.
      'render_callback' => 'views_area_render_test', // Required <-- discarded by Views.
      // Optional <-- discarded by Views.
      'options' => array(
        'something' => array('default' => TRUE),
      ),
    ),
  );
  return $areas;
}

One problem, illustrated above. When this is run through hook_views_data(), some of the extra info I need is not saved by Views, which means some workaround code that I'd like to remove.

Essentially, I need to add elements to hook_views_data() and have them available inside $this->definition when acting on the view.

If that can be worked out, this might be core-module worthy.

Give it a try.

CommentFileSizeAuthor
#24 793814-ctools-area.patch6.23 KBagentrickard
#23 793814-ctools-area_1.patch697 bytesagentrickard
#17 793814-ctools-area.patch5.66 KBIsland Usurper
#15 793814-ctools-area.patch6.34 KBagentrickard
#14 Archive.zip2.77 KBagentrickard
#4 views_area.tgz1.7 KBagentrickard
views_area.tgz2.12 KBagentrickard

Comments

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

In case it's not clear, the use-case for this is creating dynamic HEADER or FOOTER elements in code, and having those appear as views handlers, not requiring the insertion of PHP (or the use of the PHP input filter).

merlinofchaos’s picture

merlinofchaos commented

THe reason it's not getting retained is that it's one level too high. You have 'area' => array('handler' => '...') -- you need to make sure everything you want retained in the definition is a sibling of the handler.

I'm still thinking about if this should go in Views or not. On one hand it's a nice little saver, but on the other, it's basically de-OOing something that's OO and I'm not sure that's really something I want to promote directly.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Well, don't think of it as de-OOing. Think of it as a huge timesaver and convenience tool. I'm not a huge fan of the magic naming / autoload features of views handlers....and writing one per custom header function seems like overkill.

Also, this layer of abstraction should make the CTools Content Types plugin for areas dead simple.

As to the definition, I see the issue. I need:

/**
 * Implementation of hook_views_data()
 */
function views_area_views_data() {
  $base = array(
    'area' => array(
      'handler' => 'views_area_handler_area',
    ),
  );
  foreach(views_area_info() as $name => $info) {
    $data['views']['views_area_'. $name] = $info;
    $data['views']['views_area_'. $name] += $base;
    $data['views']['views_area_'. $name]['area'] = $info;
  }
  return $data;
}

Or the rough equiv.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
StatusFileSize
new views_area.tgz1.7 KB

And....done.

Thanks for the assist. I am perfectly willing to release this stand-alone if it doesn't fit with the vision of Views core.

dawehner’s picture

dawehner
Primary language German
commented
Status: Needs review » Needs work

Sorry you are missing the area handler

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

@dereine

What? I don't follow.

dawehner’s picture

dawehner
Primary language German
commented
Status: Needs work » Needs review

Forget it.

bojanz’s picture

bojanz commented

This code helped me as an example for defining custom areas (I wasn't defining it as a field in hook_views_data()).

However, from my point of view, I'm not sure how useful this hook is...
I am defining my own field handlers, filters, argument handlers, so writing an area handler is consistent with that (I don't have a hook for those other use cases either)

dawehner’s picture

dawehner
Primary language German
commented

Additional you can have areas only related to certain base tables. You can definitive profit from being a data definition handler. For example using access callback and access arguments is also a good feature.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Yes, this doesn't need to go anywhere, it was just a valuable exercise. I might use it on projects where if have to do multiple areas.

It might be more useful as an abstraction module that allows Blocks to be used as areas.

dawehner’s picture

dawehner
Primary language German
commented 
It might be more useful as an abstraction module that allows Blocks to be used as areas.

I think we should write a plugin in views which allows to use any ctools content type here. This would allow a lot of stuff.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Yes. Would that go as a Ctools patch or a Views patch?

dawehner’s picture

dawehner
Primary language German
commented

I think this can go into views. There are already some integration of ctools related stuff in views.

Additional v3 will one day require ctools.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Needs review » Needs work
StatusFileSize
new Archive.zip2.77 KB

No proper patch, because I didn't make a CVS checkout of Views. But here's some code for testing.

TODO: Add this line to the bottom of includes/handlers.inc

function ctools_views_api() { return views_views_api(); }

Then the attached files will work. Put them in views/modules.

TODO:

- Form handling for Ctools settings.
- Access restrictions on display? On admin?
- Context handling.
- Keyword handling.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
StatusFileSize
new 793814-ctools-area.patch6.34 KB

Proper patch!

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Title: Allow modules to create new areas in code » Area handlers for CTools content types

Title change.

Island Usurper’s picture

Island Usurper commented
StatusFileSize
new 793814-ctools-area.patch5.66 KB

Updated patch to load the right file for ctools_content_render(). I also noticed that the static variable in ctools_content() caused the args not to matter at all, even when I hacked it to make the views args be inherited by an embedded view. Is statically caching the content really necessary, or does it even need to be loaded in option_definition() when the type and subtype are in the definition? I suppose I'm not too worried about the subject. *shrug*

esmerel’s picture

esmerel commented
Status: Needs work » Needs review
agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

I haven't done much on the patch recently. I moved most of my code into a separate module for easier testing. I can post that here if you like.

merlinofchaos’s picture

merlinofchaos commented
Category: feature » task
Priority: Normal » Critical
Status: Needs review » Needs work

Ok. Love this patch. Some problems.

1) The Label needs a dependency on the checkbox. It's meaningless if that box is checked. Also, the checkbox should be reversed. 2) None of the actual configuration for the content is in there. This isn't a problem on simple content, but try adding the custom content. Implementing this shouldn't be hard at all. option_definition() can create a conf value defaulting to array() and it should be possible for that to hold whatever we need in the array, and the ctools content config system should be able to do whatever is needed.
3) If you have configuration as per 2), 1) becomes invalid because there's already an override title setting in almost all content.
4) Maybe not a problem with this patch specifically but something that has to be addressed. The Most Common option is the global text area. We want to make sure that is very very easy to find. Which means we may want to have the add new handler default to the Global group rather than no group to make sure that's the first thing users see.

In addition:

4) There's currently no way to use this with content that wants context. Why does that matter? Almost everything I can think of I want to do takes an argument. You can use this, for example, to attach views in ways that the current attachment displays can't conceive of. Views with different base tables. Views with different arguments. You can use this to easily display information about a node or a taxonomy term argument. The problem is, that we have to translate views argument -> context and we have to have that context available.
5) Solving the above problem would also be insanely massively awesome for access plugins as well, because we could trivially use all CTools access plugins for Views. That opens up worlds of possibility, but that means argument to context conversion has to happen somewhere very early in the process.

Updating this to a critical task. While this is not going to be a release blocker in any way, I think this is a fantastic use of the new system and it solves a LOT of problems that we can't currently solve.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

@merlinofchaos

Continue as patch, or as separate module that gets folded into the Views or CTools release?

merlinofchaos’s picture

merlinofchaos commented

Definitely continue.

I actually spent awhile deciding if I was going to work on it myself right there, but decided my time was better spent continuing to reduce the needs review queue. Still a lot of stuff that needs my love in the queue.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
StatusFileSize
new 793814-ctools-area_1.patch697 bytes

Patch update against 6.x.dev. Working for simple cases.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
StatusFileSize
new 793814-ctools-area.patch6.23 KB

Properly formatted to create the new files via CVS diff.

mrharolda’s picture

mrharolda commented

Is this issue still active?

I've made a patch for Views 7.x-3.x-dev #1243948: "Global: block" area support to support adding blocks to views. I guess the ctools approach is better, but since this issue hasn't been updates in ages...

mustanggb’s picture

mustanggb commented
Issue summary: View changes
Status: Needs work » Closed (won't fix)