[jsr-314-open] [JSF 2.1 NEW] composite component namespace simplification

[Dan Allen]

I like Jim's suggestion here. I agree with the jsf scheme since the current
taglib namespaces use "jsf" not "faces" (e.g., http://java.sun.com/jsf/core).
So the standard seems to be to use "jsf" in URNs. I like the "cc" scheme
because we have already started down that round, so it is actually more
consistent and meaningful than "composite", which really doesn't mean
anything.

So citing Pete's example with the new syntax:

xmlns:pete="jsf:cc:components/pete"

would map to

/resources/components/pete

Am I right?

Of course, this ties into our other request to tuck these things away under
WEB-INF

/WEB-INF/resources/components/pete

Also, going back to something David said earlier about how flex maps to a
whole directory with /*, the composite components already map to a whole
directory. We don't have the concept of creating a namespace for a single
component, which really doesn't make any sense anyone.

The point I'm getting at is that we really are pretty close to getting
something that is quite elegant.

-Dan

On Fri, Dec 11, 2009 at 1:29 AM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:

> I like both of these suggestions. Less is more.
>
> > Further, in the interest of brevity, why say "composite"?  Why not match
> the
> > implicit EL object and just say "cc"?
> >
> > Thus:
> >
> > xmlns:jim="jsf:cc:jim"
> >
> > Isn't that just as clear to someone who already knows what #{cc} is?
> >
> > Concerned that it's too cryptic?  Look at the first part of that phrase.
> >  Anyone think that the XML standards guys should have called it
> xmlnamespace
> > instead of xmlns?
> >
> > Shorter is almost always better, especially for frequently typed
> > boilerplate.
> >
> > Jim
> >
>



-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20091211/4be46ee7/attachment.html