Not sure we can really have a general hint naming rule, it depends on
what the component is used for.
As for hint that are here only to make the component unique like
EventListener maybe the simplest is to use the canonical class name
(which is not in your list ;)).
As for the getName the name pf the method is actually wrong IMO since
it's used by observation manager as the unique identifier of the
ListenerEvent and not as a descriptive name. I would say lets use the
same for both and actually we should probably have an
AbstractEventListener which extract the return of getName from the
component hint like we do with macros to make it even easier.
On Thu, Feb 23, 2012 at 8:10 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Hi devs,
I noticed that we don't have a standard rule for naming component hints. So
far we have:
A) nestedscriptmacrovalidator -> concatenated word list
B) extension.cluster -> dot separated word list
C) CommentEventGeneratorListener -> CamelCase word list
D) legacyEventDispatcher -> camelCase with lowercase first letter
E) componentManagerBridge -> same, but getName returns the space separated
version
F) document-content-annotation-updater -> dash separated word list, but
getName returns the CamelCase version
G) register-macros-on-import -> same, but an active voice is used instead
There are probably other versions as well, I just looked at EventListener
implementations.
So, which one should we use?
Personally I'd vote for F)
Second vote: For EventListeners, should the getName() always return the same
thing as the component hint, or return a more user friendly description? If
we're returning a different thing, then we could return a space separated
description.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne