At least in part, the aims of this group seem to be concerned with gathering new ideas for Views from the stumbling of others. So I hope is that this is of interest (it is to me).
I'm new to Views. Very new. I spent 2 hrs with it yesterday evening. I didn't make much progress. Here's what I would like to do,
-
Construct a view of child terms, from a term.
(note, term data in the results, not node data) -
Make a generalized path. Along the lines of /child-terms/% (% being a term).
(I know this kind of functionality is one of the stars of Views, but I like little steps) -
Save that View as a default View.
-
Load the default View automatically from our module, so the View path will always be available for the module , and users directly, to exploit.
And here are some of the places I'm stumbling,
-
Views doesn't (seem) to offer many options that deal with a taxonomy directly. So I have to construct my own query building code. Couldn't find any examples, bar in the Views source itself. Hacking Views source I couldn't get even a dummy argument or filter to appear.
-
Most of the documentation assumes that a module is declaring its own tables (hook_views_data()). Probably the most called for need, but in this case we are retrieving data from existing tables. Can I extend, or further declare, through hook_views_data()?
-
The SQL is trivial - {term_hierarchy} for all tids with the chosen parent. But I didn't come across much about how this translates into Views [join]/left_field API, bar this link.
-
So where does the code go? Especially when we integrate with the module. I made up a MODULENAME.views.inc just to start off in a tidy manner, but now find that is rather a critical name. Used for hook_views_data()...
-
hook_views_handlers just returns me "// example code here" so I don't know where that is supposed to go. Same for hook_views_query_alter(). hook_views_api(), No documentation? A hint here I suppose...
-
We'd like Views integration to be optional. If Views exists (installed/enabled), we use it, if not, other provision. Maybe hook_views_api() can handle that, but are there any side effect risks? What if a user decides to install/uninstall Views after our module
Linked to this group, this node contains some useful snippets, but not really enough to feel like I have any big questions answered. I feel a long way away from hook_views_default_views() - which is probably my target.
Sure I can trawl through source for examples, use trial and error for code placement, see if I can find some Views extended or compliant modules and trawl their code. I'm sure we'll get there, but if anyone could give me some pointers, I'd appreciate it. I'm not asking for anyone to write code for me.
Rob
Comments
Most of the documentation
To extend existing data, use hook_views_data_alter().
Maybe looking at this patch will help, which adds more info to Views about term parents: http://drupal.org/node/408180
By looking at the existing *.views.inc files in Views itself, you can quickly see that hook_views_data, hook_views_data_alter, hook_views_handlers and hook_views_plugins can all go in *.views.inc.
In general almost any Views hook except for hook_views_api() can go in your modulename.views.inc file.
Your 'here' link is so close. One of your questions is answered directly here: http://views-help.doc.logrus.com/help/views/api and another is answered indirectly here: http://views-help.doc.logrus.com/help/views/api-handlers (That one doesn't actually say to put your hook_views_handlers.inc in your modulename.views.inc file, but it does say to look in the *.views.inc files in Views for examples).
The only risks are that the view paths you might come to expect may not actually lead anywhere, so you have to be careful about referencing them. And if you do make another provision then yes, you'll need to keep an eye out for Views becoming active and your default views suddenly doing stuff. Now, Views will automatically take over paths, so that may not really matter too much. But at a certain point, making Views optional can be a lot of work, and if there's any module that's ubiquitous throughout Drupal, it's Views.
support
Wonderful support mate. Sadly, I never expect much from a forum. Too often public forums have no respect for the learning process, and even dev forums suffer from self-centredness. But that's just the nudge I think we'll need.
Power to yer elbow,
Rob
To be fair, there's a lot of
To be fair, there's a lot of things that contribute to that impression. A lack of time and a lack of resources are way up there. But also, bad questions.
Honestly, you made it easier for me to answer your questions by providing some very specific questions that didn't require pages and pages plus a lot of research to answer. Your questions got to the point and focused on precisely where you were confused. It's amazing how much more likely I am to give some support when it takes me only a few minutes to write up the answers and I don't have to reread the post half a dozen times to understand what the question even is!
So thank you for providing me with good questions that I was able to more or less answer!
Oh another item I meant to
Oh another item I meant to have in my list: Posts getting lost in the sea of information. That's always a big one.
Any chance of sharing some
Any chance of sharing some of your code? I'm especially interested in:
I'm sure it would help a lot of people if they can see more options for terms.
Practicaliites (groan)
Sorry, missed these comments. Given the trouble I'm having making a child relationship, Flying Drupalist, I may not be the geezer for the job!
Seriously, we need to see that Views is following core in regarding Taxonomy as an internal/admin affair. I expected to have to build my own API extensions even before I had loaded Views for the first time. I'm pleased the facilities are there, within the API.
Upshot:
Context and engagement; personally speaking, I'll glaze my eyes over sussing it out if someone will take time to explain, and show me what it's for. Example: I'm over here due to some well-articulated and enthusiastic posts!
help needed to add dummy tables to hook_views_data
Hi,
I'm upgrading a drupal 5 site to drupal 6.
There is a dummy table in hook_views_tables.
<?phpfunction mymodule_views_tables() {
$tables = array(
// this is a placeholder...not really a table at all
'mymodule_dummy_table' => array(
'fields' => array(
'mymodule_myfield' => array(
'name' => t('My module: myfield'),
'notafield' => true, // this is a virtual field
'handler' => 'mymodule_field_myfield',
),
),
),
);
return $tables;
}
?>
And mymodule_field_myfield function is:
<?php
function mymodule_field_myfield($fieldinfo = null, $fielddata = null, $value = null, $data = null) {
if ($data->nid) {
return theme('view', 'test_view1', null, null, 'embed', array($data->nid));
}
}
?>
And below is drupal 6 coding:
<?php
function mymodule_views_data() {
// this is a placeholder...not really a table at all
$data['mymodule_dummy']['table']['group'] = t('My module');
$data['mymodule_dummy']['mymodule_myfield'] = array(
'title' => t('My module: myfield'),
'field' => array(
'handler' => 'mymodules_field_myfield',
'click sortable' => false,
),
);
}
function mymodule_views_handlers() {
array(
'handlers' => array(
'mymodules_field_myfield' => array(
'parent' => ????, // what goes here??
),
),
);
}
?>
I've created a mymodule_field_myfield.inc file as per instructions in advanced help.But i dont know what coding to go in this file.
Problem is that i don't know what to do next? Also how to return the view via handler function as it is done in drupal 5 by theme_view function. Can anyone please shed some light on it or point me in the right direction.
Many thanks in advance.
The parent is almost
The parent is almost certainly views_view_field
You'll need to create a class that inherits from views_view_field that implements the render() function. You need to do something special if the table that your field is hanging off doesn't actually exist. In order to do that, see views_handler_field_custom() -- it overrides the query() method to do nothing.
Thank you very much..
Hello merlin,
Thank you very much for you valuable advice..
I'm glad and feel honored to find out that the developer of one of drupal's most powerful modules has himself replied to my post.
Views is just an amazing and wonderful module. Many thanks for such a powerful module.