On Fri, Apr 9, 2010 at 10:53 AM, Pete Muir <pmuir(a)redhat.com&gt; 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?

I'm not a fan of relying on tooling -- it usually just adds another layer of barrier-to-entry IMO, if you need tools to get anything done.

I like the idea of having a #{seam} name-space. It's clear, short, and consistent if we all do it.

I don't think it's any more difficult to tell people to use #{seam.statusMessages} than it is to tell them #{org.jboss.seam.faces.statusMessages} -- OTOH, people could easily just provide a pass-through bean that would alias the utilities themselves, but... that's annoying after you've done it the first time, isn't it?

As for convention -- well -- convention is also providing shorter "contexts," like #{request}, #{conversation}, #{session}, #{facesContext}, etc... so I think you could argue either way -- granted, those are actual objects that have been abbreviated and provided in the EL, but... the same could be said for our namespace -- just an abbreviation.

Playing devil's advocate here. I'm all for making things shorter, but I also respect convention. --Lincoln On Thu, Apr 15, 2010 at 8:23 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: On 14 Apr 2010, at 19:14, Dan Allen wrote: > On Fri, Apr 9, 2010 at 10:53 AM, Pete Muir <pmuir(a)redhat.com&gt; 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. Not 100% meaningless, it makes it somewhat easier if an end-user wants to remove the short names. > > 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". I disagree. Does this mean that Java is doing something wrong by requiring import org.jboss.seam.blah.Foo; I'm pretty sure that people thought this was a major pain and that the Java language designers had made a mistake requiring qualified imports until modern IDEs generally supported automatic importing. In fact, you can see the leftover of this in a few places (people using the .* import for example). If we had tooling for this, would this change your opinion? > 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? Because it doesn't follow conventions. _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"