I should have demo your module a bit more, didn't realize It was already returning the node information other than edit link (makes the module name make a lot more sense though XD). . Well, I was obsessed with the idea of this functionality being as a node reference widget anyway, so I tried my hand at it, resulting in a module with very similiar functionality but different approach (using similar popups reference patches though XP).

Want to try and merge them togeather? Though not sure how we'd do that (again, different approach, since it's a widget and not addon/alters). Your module name is muc
http://demo.intheclosets.com/node/22 Here's information about it, code, what patches, link to demo (use username test, pass watwatwat).

Comments

cyu’s picture

I will take a look, but my first impression is that it does sound like we are going down the same route and should probably merge efforts.

hefox’s picture

Kk,
And oops, above was suppose to be: Your module name is much better*. Got distracted and.. half sentence and half word for the loose.

cyu’s picture

Hmm...I went with alter instead of widget because I was initially piggybacking onto popups add and reference and then eventually was going to add per field config in the same way that it does. I will have to think about it a bit more, but I see merits to the widget approach as well. What are your thoughts on the pros and cons?

hefox’s picture

Widget/set of widgets feels right to me because it's a bit more than an add on to me; it changes the way nodes references are picked and acted on; though it does use auto complete atm (though it doesn't have to!). Oh, that's one advantage; one thing I'd like is that for disabling selection of preexisting nodes is for the autocomplete to be a hidden field instead of a autcomplete with display:none, which would likely be easier as a widget .

Also, saving and adding configuration options is simpler since it can use the CCK widget_info (though I forgot to add in the autcomplete references configuration, oops!; need to call the nodereference_widget_info, etc.).

Hm, I think my main thinking is that a widget is more likely to generally cleaner path than an add-on (though my module is bigger ATM XD) and provides more control. Cleaner as in less likely to the whims of other modules (I've had issues going back to fix code after upgrading modules since the base code changed a way it did things :(.).
Oh, also, I did it as an element; so like node reference it can potentially be re-used for other modules. For example, it'd be nice if node reference from url could use it as a alternate fallback method like it does for node reference autcomplete, selection, etc.

tldr; More control, possible "cleaner" way to do it; the alter method is lighter code and likely can expansion to other widgets easier.

Hm, one path I can see being done is a base functionality not specific to node reference that supplies the JavaScript, functions, etc. then with various widgets for different field types; actually I quite like that idea though haven't given that much thought on what functions/functionality would be needed. I'm leaning toward this as the best option, but more complex.

Ah typical drupal issue; so many ways to do things, so hard to decide which!

hefox’s picture

(Ah right, forgot to mention we have different focuses I think (or rather, just thought about that). My focus was more on the adding the node view in various ways; while yours was.. more focuses on the popup, add in node part. That comes out like how my widget doesn't require popups, but works more elegantly with it; ie the refresh link when popups aren;t used).

cyu’s picture

Also will be interesting to see what http://drupal.org/project/inline_noderef ends up looking like. I think they will be using #ahah instead of popups for doing on the fly node creation, but we all probably have fairly similar goals.