Closed (fixed)
Project:
Drupal.org site moderators
Component:
Other
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
30 Oct 2009 at 23:47 UTC
Updated:
6 Jan 2011 at 06:00 UTC
The new Examples module does not have a home in the taxonomy of modules. I propose a new term, surprisingly enough, "Examples" for it. The Example module is for core examples, but I think we'll have other examples down the line for important contrib modules. For example, the CTools Plugin Example module lives in CTools, which is one possible home for it, but it also could have been a contrib module which would live in the Examples category.
Thanks,
-Randy
Comments
Comment #1
dave reidHmm, I'm not sure about this. Will we really have enough example modules to justify a category, or should we create this category just because we should always be able to separate theses from other modules since they are not *true* modules.
Comment #2
rfayIMO, we need this category, and definitely need to separate this from "function" modules.
Or, perhaps, we need a "miscellaneous" category. But I'm in favor of an examples category. In general we need more examples and less talk in the Drupal world. Of course you know I feel that way :-) It would be good if more of these sprout up.
Comment #3
gregglesOn the other hand, everything is an example. When I want to do X I think of a module which does X and look to see how it does it.
If the idea is that this taxonomy would be limited to modules which "are the best possible example of how to do X" then this sounds more like the "golden contrib" idea than it does an example module and I think that's way more complex than just adding a term.
Comment #4
rfay@greggles, to an expert, everything can be an example (or a counterexample). But a module that is specifically designed to be a teaching/learning/laboratory tool is a different class of module.
The idea of this category is modules that demonstrate a specific Drupal or contrib capability and do it so that nothing gets in the way of the demonstration.
For example, yes, it's possible for people to learn about the menu system by studying pathauto. And an expert would learn a lot. But a very simple, barebones example will help a developer new to the concepts far more. And pathauto cannot do its job while trying to teach. Neither can an example do anything significant in reality if it's going to stay true to the teaching task.
Comment #5
avpadernoAs there is the project , I would guess example modules should be part of that project. In this case, there isn't the need to have a taxonomy term for example modules.
Comment #6
rfay@kiamlaluno: This conversation is actually about that project, Examples.
1. It needs a category that makes sense!
2. It's for core examples. Other types of examples will pop up. Views? Panels?
Comment #7
avpadernoIf the taxonomy term is used from just a project, then there is no need to create it.
The project is not thought to be used only for Drupal core examples, but it can be used also for examples for third-party modules.
Comment #8
rfayMy intent is that examples is for core stuff: It's all the modules that were transplanted from core documentation. But I see a place for a specialized set of examples that show how to expand views, for example.
As you know, one person can't maintain an infinite set of modules, and that's why contrib gets a bit spread out. That's good. So someone who has the energy to maintain another set of modules can start a different one with a different focus.
Comment #9
rfayI still think this is a good idea. Of course, I'm open to suggestions.
What is the correct category for the Examples project?
What is the correct category for new modules that I'm sure will come that will demonstrate contrib features? For example, it would be fantastic to have a great project demonstrating all of CCK (D6). Or a great project demonstrating Views integration.
Comment #10
avpadernoWhy should an example module for a third-party module be separated from the main module? CheckAll includes two example modules, but they are part of CheckAll as project.
Comment #11
rfayYour question is a good one, @kiamlaluno.
Putting an example into the main project is a great thing to do IF the maintainer of the project is the maintainer of the examples. But the maintainership is quite a different thing.
I wrote the CTools Plugin Examples module and got merlinofchaos to put it into CTools... But it's kind of awkward there. It shows up for everybody in the world in admin/build/modules, when only developers would be interested. But the biggest issue is, I don't maintain it at all. If it were in a project that I had some rights to, I'd probably be more active with it.
So for example, if a 3rd party wanted to get a good Views example going, it would be quite awkward to do it within the views project. It would have to be done via patches, and that's not quite the right way to actually maintain something. And do the maintainers of views need to be reviewing and committing example modules in addition to their other chores? Probably not.
So there are two reasons to put examples into their own projects:
1. Exposure to the right audience. Really, only developers should see a Views API examples module. It shouldn't be sitting there in admin/build/moduels for everybody to see. (Token STARTER is another example of this).
2. Appropriate maintainership: The maintenance of examples has a different focus and is from (probably) a different kind of maintainer. And it's great to offload stuff like this from our key modules.
Thanks for the response.
Comment #12
gregglesLet's get a list of example modules. Until there's a list of like 5-10 modules that should be included I think this doesn't make sense.
Comment #13
avpadernoAs per previous comment, I am marking this report as postponed.
Comment #14
rfayThere are now 3 pure-example projects,
I think we'll have a ctools_examples module at some point as well.
Comment #15
avpadernoI think that if some example modules that are included in existing projects (in example, the example included in CheckAll) would be split from the current project hosting them, there would be more projects using the taxonomy term.
Separating the example modules is preferable, as who installs a module for using it is probably not interested in the example module, while developers are interested in a working examples to use to create their own modules.
Comment #16
avpadernoThe taxonomy term used could be , or simply . It could be implicit that examples are for developers (or for users interested in developing their own custom modules), but making that explicit could avoid the term is misused.
Differently from the term proposed for API modules, this term is less vague, and I would like to see it added in the project taxonomy.
Comment #17
mile23Looking at the list of module categories... If there's one for 'Novelty,' then there should be one for 'Examples,' for the same reason. :-)
Comment #18
rfayThat's a pretty strong argument, @Mile23. Pretty strong. But examples count for more than novelty.
Comment #19
rfay@kiam, since you're a disinterested party, why don't you just call this one and add it :-) I don't think I should just add it myself.
-Randy
Comment #20
avpadernoI added the tag, and set it for the reported modules.
Comment #21
dave reidOk, wasn't exactly more than 5 modules, but I guess this makes sense. It's too bad we couldn't use a tag like 'Includes example' so the example module wouldn't have to come separate.
Comment #22
avpadernoI think the Examples tag could be used also from a project that includes an example module, in the same way the Content Access Control tag is used from projects where the access control is not the only implemented functionallity. The project page will report if the project contains only example modules, or it contains an example module that shows how the code of the main module can be used.
Comment #23
rfayThanks!