views integration

well, i'm not the right person probably, but i thought about getting nids/tids directly from the view instead of use taxonomy_term_count_nodes, then aggregate (maybe aggregate beforewards with http://drupal.org/project/views_groupby ?)
and get the tid and node count.

this is (almost) already possible creating a view with the module views_groupby
but adding the capabilities of vocabindex would be just fab.
just my 2c.

Well, you chose naturally :] but i guess i'm not the only one (http://drupal.org/node/339423)
that wish a feature like this be implemented in some taxonomy-menu module.

More generally I think that node counting in drupal it's a very important and requested feature
ie. http://drupal.org/project/term_node_count

Maybe the simplest solution would be something like this:

1. we have a view that overrides taxonomy/term/% (the vocabindex paths point there)

2. this view it's a sql query that returns nodes (nids), has fields, filters and an argument which is the term tid

3. we programatically call the view with a default argument = 'all' (get results for all the terms)

4. we have a full sql query from the view that selects all the nodes (nids) for all the term-menu-paths we need,
so we have all the node counts we need in just one query since we group by (term id).

5. cache the results (?)

The guess it's to use to use/get the filters used by the view (the WHERE statement substantially) to build a custom node_count routine.
(I don't know if it's possible to get the query generated from a view and alter it on the fly...)

thank you anyway for your time!

I am now thinking of letting users choose between Taxonomy or a Views as a data source for Indexes instead of just Taxonomy, as Vocabulary Index does now. This still needs A LOT of thought, though.

That's exactly the feature requested :]

Basically, you suggest using Views for getting node counts only? It would be faster to create a custom approach or to use Term Node Count directly.

Yes. If Term Node Count stores the node-count for each view then it would be faster indeed
(i don't know if it does, but if it does then all would be so much easier).

But i think that the custom approach would be difficult because the filters in the view come from various places
(ie. access control, filters, grouping...) this is why i suggest to directly use/query the view someway.

I think that the only differences when choosing a view instead of taxonomy as a datasource are:

1. some terms won't appear in the vocabindex because they're filtered out by the view
2. some nodes won't show as they're filtered out by the view (so the node count should take this into consideration)

Basically once we get the filtered sets of tids and nids, we should be done (this is what the views already does for us).

The paths could be custom and could be taken from a free textfield setting:
if the view url is my_categories/%tid_argument then the rendered output will take this into account when printing links
(this is the approach taken by taxonomy_menu module, but it suffers the node-count issue too).

Just some considerations.