On Fri, Apr 9, 2010 at 10:53 AM, Pete Muir
<pmuir@redhat.com> wrote:
* Changed the requirement to be to use org.jboss.seam.* as the prefix for the bean name. We will add an extension for CDI that allows aliasing namespaces such as org.jboss.seam to a short prefix (such as seam.). Anyone fancy coding this up quickly for Weld Extensions?
I missed this one. We had a long chat about this in #seam-dev a few weeks ago and drew these conclusions.
Using long qualified bean names (i.e., @Named("com.acme.framework.module.beanName")) immediately introduces the need to shorten (or import) them in someway. The approach that was taken in Seam 2 was to qualify every name with the prefix "org.jboss.seam." and then add all of these namespaces to a list of auto-imports in jboss-seam.jar. But that defeated the whole purpose of having a qualified name since now each component had two names, the short one (e.g., "statusMessages" and the long one "org.jboss.seam.international.statusMessages"). So global imports provided by the library are meaningless.
That brings us to local imports. Since bean names are only meant to be used in the EL (which in most cases is the view), we ask, how to we import the names in the view? I posed this very question to Lincoln. I suggested:
<s:importNames namespace="org.jboss.seam.faces"/>
Understandably, he challenged me by saying (paraphrase) "you must be doing something wrong if you need that".
We came to the understanding that having a protected namespace is good, but having a namespace that you can't easily type is bad. We concluded that since we "own" the Seam name, people should be willing to accept that we can prefix our names with "seam" and that should be enough to ensure that they don't conflict with application names. In the example above, I can avoid the import by using the name:
seam.statusMessages
I think bean names should be unique across all our modules so we can avoid having to put the module name in the bean name "seam.international.statusMessages". You can always tweak the name to make it unique.
The question we need to ask, is, why not?
-Dan