I'm developing functionality similiar to the one found in noderelationships (search_and_reference) for D6.

I've forked the nodeconnect project into a sandbox module and all the development will happen there. At least until the code is mature enough to produce a proper patch.

I will go the same way as noderelationships: allow a user to cusomize a view which is then presented as a table to select content from. I hope to be able to cover single and multivalued fields.

Any suggestions are welcome.

Comments

e2thex’s picture

e2thex commented

@paranojik

I think that functionality would be awesome functionality and i would love talking about getting that in to nodeconnect.

I would make two suggestion (base on using it in d6)
1. settings: see if you can get the settings to be saved as part of the field, and have the configure of those settings be part of the field configuration. if it is not possible to store the values as part of the field, store them as nicely named variables. In the d6 version (noderelationships) we had a heck of a time getting the settings exported to code via features, and also it seems nature for this to be part of the widget configuration

2. Maybe on the view side add a handler (like the current page or block one) that handles the select and such, that way someone can use any view that uses that display handler. (in d6 you had to clone the one that was provided)

Thanks for working on that I think it will be a very need addition

paranojik’s picture

paranojik commented

Thanks man!
Settings are already saved per-field instance and features correctly exports the data.

On the views side things may need more work. I actually only consume the "default" display of the selected view. I do not render a specific display but output the results with all selected fields in a tableselect form. Maybe I should have implemented this part as a custom views style (like the one views_bulk_operations used) as you suggest.

Later on I discovered that if I wanted to use a different type of view (specifically a fuzzysearch_index view) a views style is not sufficent because of the way different views query plugins map views results to entity-ids (a standard node view result contains a nid field, whereas a fuzzysearch_index view results has a enitity field). So I ended up implementing a pluggable mechanism which could theoretically allow using any kind of search/query for providing the results. I implemented two "DataProvider" classes for the two beforementioned situations.

funkytraffic’s picture

funkytraffic commented

I am really waiting to see this happen so I can migrate to Drupal7 with my site.

I would like to create a feature request for both modules: Node Connect and Node Relationships.

There is a early development version I found of a module called Field taxonomy. Though this module might probably never even see an alpha version, it illustrates a nice approach: Assign a taxonmy term to a node reference (in this case to any field). This would turn a reference into a 'real' relationship.

This would mean: Node type 'person' has a node reference to 'organsiation' with the taxonomy term 'customer' or 'employee' or 'manager' assigned to it. I know that entity Relation is going in that direction to, but I am not sure if it fullfills my needs. Or 'person' has a reference to 'person' with the term 'friends' or 'eternal enemy' ;-) .

Having Search & Ref Views support and taxonomy attributes added to Node Connect would make this tool extremly powerfull.

Do you like that approach? Shall I open a new thread for this? If yes where?

funkytraffic’s picture

funkytraffic commented

Another aspect is: In D6 there is besides Node Relationships: NR Explorer, Popups Add and Reference, Modal NR, Embedded Edit, Nodeselect, Node Widget...

They all have a similar approch, which is absurd.

I would be nice to see all this modules continued within Node Connect, since it gets rid of a lot of javascripting terror and would put coding energy into one project.