Provide default project browsing views that don't depend on project_release

Tagging for #439958: Document issues left before 6.x official release

sub

I will be working on this over the next few days.

The specific view that has project_release dependencies is project_overview and project_overview2. I am concerned that conditionally providing those dependencies in the project views will cause problems. What do you think about overriding the project_overview[2] view with the project_release dependencies from the the project_release views? This seems to be a more logically way to incorporate the dependencies.

Also, it seems like the project_overview2 view is intended to be the project_overview view. Is this correct?

This patch provides the following changes to the default view for the project module (views/project.views_default.inc):
1) Removes the project_overview_2 view. I assumed that this was a development view for project_overview.
2) Moves dependencies on the project_release module to only include them if module_exists('project_release').

Here are some notes on my decision making process for implementing the solution this way:

Started going down the path of trying to override the view in the
project_release module. Not sure if there is a good way to do this
programatically.

Calling views_get_view('project_overview') caused memory exceptions in the
default_view file for project_release.

Just trying to re-write the view in project release, but this caused recursion
error messages and the view seemed to get auto-disabled.

You forgot to attach the patch ;)

Thanks for wanting to take this on! This is one of the major things holding up an official 6.x release of this module (#509446: Please roll a release for the 6.x branch of this module.).

Probably the best approach here would be for project_release to provide a default view that can be enabled if desired, but the default one in project.module itself should just provide a way to browse projects without any release dependencies. The default one in project.module would be pretty darn simple, and I'm not too worried about duplication, since most of the complication would be in the one provided by project_release.

There might be a way to automatically override the path with the project_release-provided default view if that module is enabled, but I'm not too worried about that. We can just document this additional step (disable the project view and enable the project_release one) when installing project_release.

Also note that the existing project browsing views are *very* stale. The Views API changed a lot since they were written. They basically should just be flushed and started over from scratch (although there might be some good things to harvest from the initial effort). To that end, the view provided by project_release can now take advantage of the goodies from #539676: Expose {project_release_supported_versions} data to views -- there might also be useful new views support from #539668: Expose files attached to releases to views and #543326: Provide a views relationship from {project_release_nodes} to {node} that could help here, too.

See also #539682: Replace hard-coded release download table with a view

Here is the patch I forgot to attach to #4. I may re-roll after looking through the references in #6.

This is just a patch of views/project.views_default.inc which gets rid of all project_release dependencies. It was generated with the views_export feature.

I am holding off on patching release/views/project_release.views_default.inc because I am not entirely clear on what you are asking for in #6 dww. Am I correct to assume that you are saying you would like an additional view there that may override project/% with the related relationships and filters (that I just removed from views/project.views_default.inc)?

You mention that the views support that was added via recent issues can be taken advantage of. By saying this did you mean that they _should_ be taken advantage of in release/views/project_release.views_default.inc?

I just split out the question of what the release-aware view(s) provided by project_release should be over to #584026: Provide separate project browsing views from project_release with release-aware features to prevent this from turning into a monster issue.

All we need to do in here is rip out the currently bogus project browsing views, and provide some simple default views that work nicely on sites that only have project (and probably project_issue) installed, but not project_release.

We can make the fancy release-aware project browsing views in project_release over at #584026...

Thanks!
-Derek

I just confirmed that the patch in #8 satisfies this requirement exclusively. I will create a patch for all project_release views stuff into #584026: Provide separate project browsing views from project_release with release-aware features.

Lies. On double check, I noticed I had a dependency to enable views support if the project_release module was installed. I removed that chunk of code and re-rolled the patch.

subscribe

patch don't apply.

That's right, I just recently split the default views into separate files in project/views/default_views:
http://drupal.org/cvs?commit=293990
http://drupal.org/cvs?commit=293978