Project:View reference
Version:7.x-3.x-dev
Component:Miscellaneous
Category:task
Priority:normal
Assigned:Unassigned
Status:closed (fixed)

Issue Summary

http://drupal.org/project/viewfield perhaps joining forces makes sense.

Comments

#1

See #1299222: Similar module for the corresponding Viewfield issue.

#2

#3

The plan is to see how the more generic 'references' or 'relation' modules pan out, and try to migrate users to a solution based on that. I am looking to deprecate my '*reference' modules, and I am keenly watching the progress in those newer modules.

#4

Alright well, I've looked into it more thoroughly recently, and it seems that unless Views are exposed as an entity there isn't really going to be a shortcut out of this. We are probably going to be maintaining these modules well into Drupal 8.

So I think one thing we could do now is see what features differ in these two modules and come up with a plan?

#5

Status:active» fixed

OK I need to address this issue as it's been here for 18 weeks and it bothers me. NancyDru deserves an answer, though perhaps not the one she wanted, but it's hard to tell, given the twitter-style messages it might just have been a half-cocked idea spawning from the prevalent duplicate module witch hunting that goes on in these parts.

I've spent some time looking into Viewfield on three separate occasions since my last post. I don't really know how to say it but I'm not too impressed with it.

A little history; back in Drupal 6 when I was working at a Drupal shop, I needed a way to insert a View into a node, similar to a node reference. I looked up "view reference" and found nothing, and so I made this module and in July 2008 I released it in this project.

About a year later I found out about Viewfield. Had a quick look, it couldn't handle the use-cases I'd been employing View reference for - particularly in the way multiple value fields and arguments worked, and you used this thing called 'tokens' to dynamically configure arguments which I found restrictive (though I've come to appreciate the pros and cons between PHP code and tokens since then, particularly after a few run-ins with the Drupal security team). I believe there also wasn't support for Autocomplete functionality that allowed dragging and dropping the order of the Views. You have one select list, and one box for arguments.

The other problem for me was that in 2009 Viewfield was still in development by a team of maintainers, and it did less than this module that I knocked up in a few hours by myself.

In August 2010, over 2 years after I released View reference, a release was made for Viewfield. And apart from the token integration, it had no features over View reference, and lacked several functionalities that View reference did have. They weren't amazing functionalities, just the sorts of typical things in other CCK modules, and yes of course I modelled it on Node reference's functionalities as I was confident most people would be familiar with that approach to making references. So I also had a leg-up from the excellent work of those that came before.

I actually used to have a little list of modules on the View reference project page that compared different modules that could relate nodes and Views. The feedback I got from this is "why would I use your module when the Viewfield module you linked is older and has more users?". Well that was a real kick in the balls after all my efforts to provide features and address issues that had nothing to do with my own usage of the module, so I have now removed that list. However, while that list was there I periodically reviewed similar modules so the list could be kept up to date. I noticed that as users made feature requests and contributed patches to Viewfield they were, perhaps out of necessity, making it approach the design of View reference more and more.

Exactly a year ago to the day I released a Drupal 7 version of View reference. There is still no release of Viewfield for Drupal 7. The current code doesn't appear to contain an Autocomplete option. I noticed someone pointed out it also has a 'force default' feature or something like that, which as I understand it has no place in a specific field module as there are several solutions available to achieve equivalent functionality with any field module.

The Drupal 5/6 status is also concerning. Updates have been made to the Drupal 5 version, but no releases have been forthcoming in four years, and despite d.o recommending removing D5 releases from supported releases, no actions have been taken in this regard in Viewfield. Similarly work has been put into two separate Drupal 6 branches since the last release and there are no releases there either.

There is very little support in the Viewfield issue queue, and I feel somewhat sorry for users of the module. Just having a look through the issue queue a lot of the issues could simply be addressed with the advice to use View Reference instead. Those poor bastards. I haven't even been able to engage in discussions regarding this current issue we're dealing with right now with Viewfield maintainers. This post may never even be read. Viewfield seems like a neglected module. I know it's hard when you've got a lot going on, I know all too well what it's like to be spread too thin. I'm not blaming anyone for anything, but I'm just looking at the unavoidable reality of the situation.

So here's how I see it: View reference migrating users to Viewfield is out of the question - the limited functionality of the module, the governance/maintenance of the module's issue queue, and the release cycle are unacceptable. View reference + tokens could handle everything Viewfield does, minus a feature that can be solved another way. But View reference is hardly a vision for the future either, and I don't think it is worth the effort to migrate users over to here either.

The future is generalising the handling of references, and a couple projects have already demonstrated their strengths in this regard. The unfortunate part of it is that these projects are based around Entities, and Views are not Entities.

I think Views (or ctools exportables in general) need to be exposed as Entities and then modules like "Relation" and "Entity reference" will take over. I've heard Earl Miles mention it before in the ctools issue queue, but I don't think there is any sort of plan in place. I just don't think this whole Entity thing is really going to pan out until Drupal 8, maybe not even then, I really don't know whether core maintainers consider it important to get Drupal working in a consistent way that can be understood by other modules without having to replicate code for every sort of object that exists within the system. I constantly run into such issues because of my modules "Finder" and "Node export" which attempt to understand Drupal objects and their relationships. You could make a contrib module for this purpose, but I've already experienced frustration trying to pursue contrib modules that turn Blocks into Entities in order to move on from my module "Block reference" - perhaps if that works out my confidence to get this done sooner will return. Plus there's the views contextual filter argument handling thing which, if views were entities, would be a feature unique to Views and special handling would always need to be added for that.

For now though, I don't see a clear plan to go ahead with something like that. I feel like I've been pushing for it in various issue queues, trying to raise awareness about this issue, trying to get ideas brewing, putting the feelers out for a sense of the future, but I've been met with stubbornness, a lack of creative thinking, an inability for programmers to apply logic and design outside of the coding environment, and worst of all - silence. I can't sort this out all by myself.

So at this stage joining forces doesn't make sense to me. What/who exactly would I be joining forces with? Come back to me in Drupal 8. Come back to me with a real solution.

#6

Nice, rational position! Won me over to view reference :)

#7

Status:fixed» closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.