Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Just another small one here. Does two things:
1) Autocomplete suggestions weren't being run through theme_autocomplete_node_finder_suggestion().
2) Add $delta to theme_autocomplete_node_finder_suggestion() so that you can theme suggestions differently for different blocks.
While not really related I have a couple questions if you have a second :)
A) I'm interesting in adding 'type' to the node query made as I think it's very useful to have as part of a $match quite often, and really comes without any additional performance hit. What do you think?
B) Really the next thing I was going to look at here after that is the possibility of opening up autocomplete_node_finder_get_result() so that the queries could come from 1) another module or 2) a View. I think that would add a lot of flexibility. :) But I'm thinking this may be a bit pre-mature if you are re-factoring much of this module.
So..... do you have some plans in mind for the new version already? If so, I imagine it's best to wait and see what that's going to be like before looking at B) above.
Thanks!
| Comment | File | Size | Author |
|---|---|---|---|
| autocomplete_node_finder_theme.patch | 1.76 KB | Moonshine |
Comments
Comment #1
danielb commentedI'll patch that in tonight.
Yes I've already thought of those other suggestions. And the problem with adding these features is the ..._get_result() function that generates the SQL is becoming too large to manage. I would like to make some sort of query building function that lets other modules hook in and change the query - and it would be a lot cleaner to read and maintain.
My plan is to seperate out all the different ideas this module uses into separate modules that can each concentrate on doing what they need to do, here is my outline: http://drupal.org/node/340415
Comment #2
danielb commentedAlso I know that views is supposed to be a query builder, but I can't seem to find any information about actually using it as a query builder.... Are there any instructions where I can feed it fields, tables, wheres, joins, etc... and it gives me the sql string?
Comment #3
Moonshine commentedYeah.. after going through some of the sql code here, I'd agree it's not really going to be worth letting things inject changes into that flow directly. But really that's were I love the idea of just letting the user choose a View for the query as an option.
Then they would just make a node View (using Views itself), which they can select for the block to use. Then your module just calls the Views query with the search arguments. Really that's exactly what CCK's Nodereference field does via 4-5 functions
If you look at :
nodereference_autocomplete()
_nodereference_potential_references()
nodereference_get_view()
in...
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/cck/modules...
that should give you a feeling for how it's done.
Really it could work very well as people would be able to choose the fields they want returned with the $match's and the ordering they want in Views also.
Something to think about..
Comment #4
danielb commentedYeah I'm fairly familiar with node reference, that is probably the first place I'd look for clues on doing this.
I'm really keen to get my new framework for this project committed soon, and then I'll probably look into this. It's part of my roadmap for Finder - so this problem will get addressed there.
Still I will apply patches to the current model of this project if given.