Node Gallery views depends on default content types and fields. When you create new relationship, all views become broken, because they use handlers that refer wrong tables/columns.
If you go further and delete default content types, you get lots of "broken/missing handler" errors.

Comments

crea’s picture

Title: Node Gallery heavily depends on hardcoded content types & fields » Node Gallery views heavily depend on hardcoded content types & fields
crea’s picture

I got broken:
cover images
images

It seems to be using hardcoded fields provided by the CCK. I think we need special handlers that are smart enough to link proper table & column judging by Node Gallery relationship

crea’s picture

This could be a feature request, depending on if you want the module be usable out of the box for multiple relationships...modifying every view display for every relationship is lots of work and really requires deep knowledge of Views.
This is real bug, not a feature request, because while one could clone & customise views for each relationship, there are also global views that are broken together with multiple relationships. For example, "covers grid" types of views are broken, because they contain hardcoded field (a cover), that works with default setup only.

crea’s picture

Quick thoughts on fixing this:

  • Need a smart relationship which links proper gallery type to the node table. It could also add node type condition in the WHERE clause to improve node table index usage
  • I think CCK already handles dynamic table changing (because field can be stored in per-field or per-type table). What is not handled is dynamic field. For the Node Gallery field handler to work independendly from the fields, it should use aliased field. Node Gallery could add the aliased field to every imagefield in the hook_views_data_alter(). Alias would mean same field & same view could be used with any imagefield.
crea’s picture

There's also a problem with multiple relationships, that we can't provide working solution for multiple relationships out of the box, because we can't assume certain usecases for them. For example, we don't know if user wants to have global gallery list, with all gallery types showing together, or per-relationship gallery lists.
I think all this relationship stuff wasn't thought out well.

scroogie’s picture

Priority: Major » Normal

In my opinion it's okay that the *default* Views require the *default* content types. They belong together. If you create custom types and relationships, you need to provide custom Views as well. That is the reason why the Views are selectable in the relationship settings! It's easy to duplicate the Views and to modify them accordingly.

I'm not convinced that providing some magic field handlers or changing Views queries is in any way better, but I'm open for discussion! Perhaps you can indeed come up with a way that is more usable than the status quo.

justintime’s picture

Category: bug » feature

Agreed. The idea wasn't to give a "one view fits all", as writing the handlers would have likely proven fairly difficult. It's save to say < 5% of NG users use anything more than the default relationship, and that work wouldn't have benefited many users.

Instead, we strive to give real-world working examples of how to do things with the default relationships, and use the issue queue/docs on how to push the module beyond that.

crea’s picture

If it was commercial product, I would fix this, to provide excellent UX. In the case of GPL software, too much work needs to be done, and we are not getting paid for this.
I agree that leaving things as is would be enough, if it was documented. It was surprise for me that Node Gallery can't handle deletion of it's own stuff.

zengenuity’s picture

Status: Active » Closed (won't fix)

At this point, I won't be adding new features to the D6 version. If features are wanted for D7, please post a new issue.