Posted by rszrama on July 2, 2010 at 10:16pm
8 followers
Jump to:
| Project: | Drupal Commerce |
| Version: | 7.x-1.x-dev |
| Component: | User experience |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
| Issue tags: | dcsprint3, low-hanging fruit |
Issue Summary
In .info files and Rules / SimpleTest definitions, there should be a single naming convention for the groups of modules in the Commerce package and in contrib. Currently we use:
Drupal Commerce
Drupal Commerce UI
This should be decided and implemented across the board.
Comments
#1
I would vote for Drupal commerce. The name is to the point and it's expected the UI modules would be under there. I did not capitalize commerce because of the Drupal capitalization standard which says "the Drupal capitalization standard: only the first letter of the first word is capitalized". See http://drupal.org/node/542202.
#2
It depends. Could you please explain in few words why other modules (Rules, Views) use both of them? Does it differenciate programmatic/gui access?
#3
Yeah, how the modules are written is different from how they're grouped. Views has both Views and Views UI in a single fieldset on the modules form, but arguably it's easier for them since there's only a single pair... but then we do have some modules that blur the line (like Cart) where it might be easier to have them next to each other.
The question then is do we support grouping for subsets of contrib like we do for Ubercart? "Drupal commerce - payment" "Drupal commerce - shipping" etc.
#4
Sorry, still not clear... What Views and Views UI do? Why there are 2 items not just one?
As for grouping, not so critical, imho. Ubercart has Extras which is pretty plain.
#5
It's exactly as you guessed - a separation of the API from the user interface. It allows for disabling the whole UI once a site is setup or in the case of Drupal Commerce providing customized UI modules during site deployments.
#6
Ah, I see. You just can not decide what would be the prefix for contrib modules.
As mfer has mentioned Drupal Commerce could be enough.
Its neither functionality nor UI issue. Sorry for interfering :)
#7
+1 for what mfer has said.
I personally like "Drupal Commerce" better than "Drupal commerce", but if the standard says so...
And I don't think we need two groups, since the user won't really think about what's the base and whats the UI, he/she just wants to enable te needed components and move on...
In any case, I can provide a patch / github fork once the decision has been made.
#8
The broader issue is should there be categories separating core modules from contrib, and if so should contrib modules be separated by type as well. I'm not sure that's entirely necessary, but Drupal core does have core / optional core packages. Maybe we just need a "Drupal Commerce" and a "Drupal Commerce Contrib" separation and that'll be enough. : ?
I'll have to think about the sentence capitalization... when it's the title of the project to have 'em both capitalized, I kinda wanna keep it that way in packages and lists. Of course, I'm pretty sure Seven capitalizes fieldset titles on that page, so it's kind of a moot point. : P
#9
Sounds okay to me. It is a good idea to separate contrib (discounts, coupons, groupons, marketplace, affiliate, etc) from core.
#10
So, it is "core" and "extras (extensions)". Extras can be done not only by contributors, but by the core developers as well. Contributed sounds like made by somedody out of DC. Thus "Drupal Commerce Contrib" sounds like an extension made by non-core developers, brought from outside. Maybe I'm wrong here, but to me sounds like that.
Regarding capitalization. Both words capitalized - Drupal Commerce. Commerce is not a description. It is a title.
Besides, it is possible that the project (I mean Drupal project itself) will prohibit that direct conjunction, because it sounds like a core module. In that case it will be just Commerce. Actually it is already like that and "Drupal" is being added just to show what CMS the module belongs to.
#11
@mertskeli according to the Drupal capitalization standard commerce should not be capitalized. Even for titles. A module can choose to ignore that if it so chooses. Or, a theme can make the first letter a capital (the solution I would prefer since it keeps to the standard and lets the designer/themer decide how to display it).
@rszrama will modules actually use the Drupal commerce contrib grouping? With the number of core commerce modules it makes sense to have a core and contrib grouping. But, how will contrib modules be guided to use it?
#12
@mfer Hmm, it's worked decently in the past for me to post an issue in a module's queue if I saw it in an odd Ubercart category. It's obviously not enforcement, but it should be good enough, especially if we can point to a section of http://www.drupalcommerce.org/development/standards.
#13
No problem, let it be according to standards.
But why "Drupal" can not be removed from the module's name? We have Views, Rules, etc., and now Commerce.
As for grouping itself - as you decide. Its an issue for developers mostly, not users.
#14
That's a good question... I tend to refer to the project as a whole as "Drupal Commerce", meaning there's core code designed to work within Drupal and the processes used are very Drupalish... i.e. it's not just a set of code but a process of building e-commerce sites that matches up with the normal Drupal method of building any type of site. In that regard, we could just name the fieldset "Commerce" and drop "Drupal"... but I'm not sure I'd make the same move in the project page... which could be confusing?
#15
@rszrama What confusion? http://drupal.org/node/206666#DRUPAL-6 - How many of them has "Drupal" in prefix? And that is logical, all of them are in "drupal.org" folder. And in modules configuration tab none of them has it in its title.
There is already a module e-Commerce. It is just "e-Commerce" - http://drupal.org/project/ecommerce
I would consider it as a good change to occupy a perfect domain name :)
meaning there's core code designed to work within Drupal
Modules for Wordpress are not expected to appear in Drupal/Projects :)
If you would like to develop a standalone pure commerce solution you could probably use the experience of Magento and develop Commerco :)
For now it is a module for Drupal. Thus imho "Commerce" wouldn't confuse anybody here. Maybe just a little regarding e-Commerce which is being called sometimes just "commerce". But it still doesn't have a stable 6.x version and less likely will rush to 7.
#16
Correct, not arguing just calling the modules themselves Commerce... but Drupal Commerce as a big picture project name (involving process, standards, and goals beyond just code) still seems pertinent - at the very least at http://www.drupalcommerce.org and ideally the project page here to match up with the website (but I'm not so attached it would have to stay).
#17
drupalcommerce.org is out of question. The same naming scheme was used for drupalecommerce.org and most others. They are non-drupal.org sites and are clearly identified.
As for the project page here at drupal.org - it's up to you. Imho, "Commerce" is sufficient. But probably you are right, and "Drupal Commerce" sounds more specific and unique. Still users will call it just "Commerce". Would be nice to ask others.
#18
My vote's for "Commerce".
#19
Hi everyone.
My vote is for "Commerce". If even three or four modules start going by "Drupal ...", we will have some clutter on the modules page.
#20
So, what's the decision?
Should we go with Commerce / Commerce extras?
I'm talking about the grouping on the modules page of course, the module page title can stay Drupal Commerce (the url is drupal.org/project/commerce anyway..)
#21
So, for module packages, I think I like "Commerce" for the core modules and "Commerce (contrib)" over "Commerce (extras)". I've seen a lot of sites organize modules using contrib vs. custom, so I think "contrib" is understood as a term. For categorization in other areas like Views or Rules, everything can probably sit under "Commerce" or under the module's namespace (i.e. Commerce Order) as necessary.
How does that sound?
#22
To me, "contrib" sounds better. Though it could mean "developed by non-DC developers" as already mentioned in #10.
As for additional possible grouping (i.e. Commerce Order) imho no problems at all.
#23
This needs to be sorted out for alpha3. Reviewing the thread, it seems we came down on just have two module packages,
Module names should not have "Commerce ______" but simply be the name of the module.
I presume Commerce module packages can feel free to use additional package names as necessary, for example,
But I'm not sure how much that should happen... setting that standard could result in no less clutter than we have now with Ubercart packages. Any thoughts on that?
#24
Ok, I've committed changes per my last comment and am making issues in related projects on d.o to use the "Commerce (contrib)" package. For now I am using "Commerce (PayPal)" for the Commerce PayPal modules, and I'll write into the standards that projects with dependencies between the various modules in the package may consider their own package name using the same format.
Commit: http://github.com/rszrama/drupalcommerce/commit/f4fbd1d6f1efffd381a1b144...
Documentation: http://www.drupalcommerce.org/development/standards#packages
#25
Automatically closed -- issue fixed for 2 weeks with no activity.
#26
I'm coming late to the party, but I think, from an UX perspective, having "contrib" in the group adds nothing. Users don't care if a module is contrib or not, they want it on a category that makes sense to them. That said, I'm more for categorizing modules for the kind of API they implement. So for now only "Commerce" and "Commerce payments" would suffice, then later we could have "Commerce shipping", "Commerce pricing", etc. I also think the parenthesis are not necessary.
I don't care much about this, and don't want to re-active this bikeshed thread, but I have an issue posted to one of my payments modules saying that my module should be on the "Commerce (contrib)" package, which I don't agree from a user point of view.