Custom way to select nodes to attach?

If I understand you correctly ... your node lists are too big to work effectively as selection lists ... tricky, I have a couple of ideas (nothing more). If you could provide a link to your test site it would be much easier to see the situation you want to deal with.

1. First you might try reconsidering your node hierarchy structure: add a middle generation to subdivide children / use more parents with fewer children each / use more nodetypes with tighter parenting rules ... ?
2. To customise the function of 'Attach existing' links you are going to have to change relativity module code. The format of the attach link is pretty easy to replicate : $base_url/relativity/addparent/$c_nid/parent/$p_nid (where $c_nid is the NID of the selected child node and $p_nid is the NID of the relevant parent node)
3. Using Views as node selection lists : I was reading about a module called viewselection, though I have not tried it, it did sound interesting ... http://drupal.org/node/103171. In a similar vein there's the editview module http://drupal.org/project/editview ... again, untested, but on my list of curios. May be worth a look.

My problem is not that I have many children or parents; my problem is that when the user clicks for instance "attach existing Page", there are so many pages that it (i) takes long to load and (ii) is cumbersome for the user to find the wanted page. (That's why I intend to use a "node browser".) — Or have I misunderstood you here?

If the 'attach existing ...' lists are too long and cumbersome (= what I meant by too many children) I don't understand how placing the same list in another window or whatever is going to make it any more navigable and usable? The 'Attach existing ...' list gets a full page already ... If the lists are too long for users to scope you need to shorten them. You may A) break them up into sublists and/or B) filter out irrelevant or redundant items from that list. I really can't see any other options. So the remaining question is how to go about sorting and sifting - there are a number of tricks, but it all depends on which node relationship modules you're using and the content you are dealing with.

Views module is all about lists of nodes and contains (almost ;) every widget you want for sorting and sifting these lists. If you're not already familiar with it, I would start there. However - whilst Omar's patch_4 does very good job of integrating views for child-nodes, AFAIK no-one has tried to tackle connecting views to the 'Attach existing ...' list. It would require some mods to Relativity module, but hopefully on the back of Omar's work it might not be too difficult. Such a patch might require some views modules features which are not (yet?) included in the official release (the viewsselection & editview 'patches') ... therefore this method is not currently available.

In the short term, a couple of things you might consider / try:

1. Tighter Taxonomy: If your vocabs don't enforce single hierarchy, you might have a lot of nodes repeating in different list groups. Can you apply AJAX collapsibility to the term fieldsets?
2. Tighter Relativity: Are all the children the same node type? If not, could you restrict any of these types to (parent ord) one parent node? - that will filter them off the 'attach lists'.
3. More Parents: Another way to create 'subcategories' would be create another content type (eg nanny) and insert it into the relativity hierarchy between you current parents and children. So instead of 1 parent -> 100 children you have 1 parent -> 5 nannies -> 20 children (per nanny) and no direct relationship between child and parent. Another analogy would be Book->Chapter->Page->Footnote, where each is a distinct content type, and each Chapter may only belong to one Book, each Page may only belong to one Chapter, but Footnotes may belong to any page ...

You see what I mean? - several ways to look at structuring your data to make it more navigable ... of course there are many possibilities, which is why I asked for a look at your testsite so I could make more specifc suggestions (if appropriate).

You're welcome - Good luck

I'm interested in this functionality as well. I want a node parent to be able to attach one or more children at once, and a browser at the top of the attachs page to simplify the search to the user. my solution woul be to have a personalized attachs page, i believe using views mostly. Have you advanced in this matter johnG? it would save me a lot of time...

I'm putting a bounty on this (well the ajax selection part) here : http://drupal.org/node/206236
If you've got a few $'s to spare and want this functionality chime in on the thread and pledge some cash :)

Wouldn't a popup with a search box (the site search would be a good idea, as it filters content by language which the current system doesn't) be a good idea; or even better a popup which could take a view and present the results from the view (a kind of hook).

Anyway, it should be some kind of ajax solution, the current way of changing the page means extra reloading of the node everytime you add a child. Can take a while under some conditions.

Anyway, to whoever might program this: let the selection be language aware. I often find myself wondering if a name of a place in my nodelist is the English, Norwegian or some other version. There are no hints in the links generated.

That's also why I can relate to the original issue, remember that each of the translations have exactly the same taxonomy terms assigned. So taxonomy refinement doesn't work, nor do refinement by node type.

A view would at least let me create a view for each language (though views should have arguments for language...sigh only filters today).