Comments for Menhir-effect blog

Comment on Hyves for drupal by Kasper Souren

Kasper Souren — Sat, 29 May 2010 12:36:26 +0000

I’m interested in testing and hacking along.

Comment on Expose database fields to views in a custom drupal module by MD

MD — Thu, 27 May 2010 11:27:18 +0000

Hi, i’m looking for a way to have a view sort data, but have te filter only give filtering options that have at least one positive result.
For instance: sort cars according to year, in a list that is constantly evolving (cars added, cars deleted) . There are 200 cars from different years. So instead of putting all the years from 1940 to 2010 in the filter, with a good chance a lot of years will show an empty result when filtered (ie. there is no car in the system from 1973, so 1973 should not be an option in the filter), the filter should know what years to show (only those that give a positive result).

Is what you describe in the article something that could do that? If not, any idea where i could find that info?

Comment on Moderated API contributions for drupal by Stalski

Stalski — Mon, 26 Apr 2010 22:10:45 +0000

Great,thx, I’ll take the discussion out there.

Comment on Moderated API contributions for drupal by sun

sun — Mon, 26 Apr 2010 21:28:57 +0000

API category on drupal.org:
http://drupal.org/node/113412

Comment on Moderated API contributions for drupal by Stalski

Stalski — Mon, 26 Apr 2010 20:36:03 +0000

I was not specific enough in my post as well. I saw this a bit like this: When creating a drupal contribution, we have the option to label the project as an API. The only difference would be that this type of module is moderated/managed differently (as severe as several developers together can be).
This way ready-to-go modules and even smaller api’s that don’t want to be labeled this way can still go ahead. The choice should indeed be left to the maintainer.
What does the label API do then? Time will tell. Could be a “recommendation”? It sure wouldn’t be left without maintainer that easily. Is it this what developers need to make a choice on how to proceed in their own projects, wanting to set a “default api”?

The sollution could satisfy both worlds. What i hope would happen is that some maintainers will end up labeling their module as the API to go or new api projects could be created in a collaboration of developers to merge and filter the best of several api’s.

Maybe i should have taken this discussion at drupal.org …

Comment on Moderated API contributions for drupal by sun

sun — Mon, 26 Apr 2010 19:50:54 +0000

Unlike the others, I agree with your considerations here.

We do not need yet another duplicate module that provides the same functionality as module XYZ, just because you added a configuration option for setting Foo.

Likewise, we do not need a new “List” module, that is Views, in pink.

We opened the review process for new CVS applications some time ago, so everyone is able to help in moderation of (entirely) new projects by new contributors, who actually are guilty for most duplicated projects, modules, and efforts, unfortunately. Everyone can help to review code and point applicants to existing projects in the http://drupal.org/project/issues/cvsapplications

However, the fact that we frequently need to point people to existing projects and tell them that their work totally duplicates an existing module and therefore provides zero benefits for the community, means that we failed to provide sufficient measures to allow users and developers to find existing projects on drupal.org.

Working heavily in core and contrib, my current conclusion and feeling is that we fail to apply Drupal’s community idea and Drupal’s principles to the sphere of contributions and into the minds of people that did not attend a DrupalCon yet. The principles of joining forces to build better products, collaborating in an open and friendly fashion, thinking both small and big, … are all not understood.

Comment on Expose database fields to views in a custom drupal module by Stalski

Stalski — Mon, 26 Apr 2010 12:21:40 +0000

Comment on Expose database fields to views in a custom drupal module by ac

ac — Mon, 26 Apr 2010 11:55:06 +0000

Is this for “Views” or “Views 2″?? As of late 2008 (this article date), Views 1 was still in common use. I guess I’ll just have to try the code and see if it works under Views 2 (but if there’s a problem, I won’t know if it’s my fault or if it was Views 1 code..)

Otherwise, good article. We could all use more tutorials on Views handlers.

Comment on Moderated API contributions for drupal by Stalski

Stalski — Mon, 26 Apr 2010 11:33:35 +0000

Thx for the great replies. That was my point exactly when creating heartbeat. So with your experience in mind, the best way is to let people develop freely without any moderation boundaries.
Thx again!

Comment on Moderated API contributions for drupal by merlinofchaos

merlinofchaos — Mon, 26 Apr 2010 01:53:18 +0000

As the maintainer of the largest contrib module in Drupal, I can tell you that a LOT of people moderate core Drupal and the amount of code and activity in all of contrib is at least a hundred times that. There simply aren’t enough resources to moderate all of contrib meaningfully. All that would really happen is that people would move their stuff off-site where they can work more in freedom.

Even more, Drupal itself can be community moderated because at least the moderation that happens is because Dries and the branch maintainers share a vision. Can they say that about my module? How are they supposed to know anything about Views?

And would Views ever have happened with a moderated contrib? I don’t think it would have, at least, not the way it has. Maybe I would’ve done something offsite, but I would have been so frustrated with the politics of trying to push something through moderation that I feel confident I would’ve stopped trying and gone elsewhere.