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

[David Geary]

Yup, understood, thanks for the clarification, Dan.

btw, it seems to me that we really don't need the jsf prefix either. After
all, it's only used in JSF applications, so I'd just prefer something like
cc:acme, which of course, ala Dan's clarification really means cc:whatever.

I suppose one could argue that we should have it because we have it in our
other namespaces, but we're not using java.sun.com, which we also have in
the other namespaces, so why not just simplify as much as possible and say
cc:whatever?


david

2009/12/11 Dan Allen <dan.j.allen at gmail.com>

> Just to clarify, the "components" directory is not required under
> resources. The developer has the option of doing:
>
> jcf:cc:acme
>
> which resolves to
>
> /resources/acme
>
> Since cc stands for composite components, some people may see the
> "components" directory as redundant (as we cited in earlier examples in the
> thread). I'm just stating a fact for clarification.
>
> -Dan
>
>
> On Fri, Dec 11, 2009 at 10:03 AM, Roger Kitain <Roger.Kitain at sun.com>wrote:
>
>> "cc" is fine since it matches the EL expression (consistency).
>> I also think "jsf" is fine especially since "jsf" is used in the core (f)
>> and html (h)
>> namespaces.
>>
>> -roger
>>
>>
>> Jim Driscoll wrote:
>>
>>>
>>>
>>> On 12/9/09 7:07 AM, Jason Lee wrote:
>>>
>>>> On Dec 9, 2009, at 5:11 AM, Pete Muir wrote:
>>>>
>>>>> Agreed, I don't think for the composite components we made the best
>>>>> choice for URI schema, IMO it should have been more like
>>>>>
>>>>> xmlns:pete="composite:components/pete"
>>>>>
>>>>> - the big difference to the original proposal is that we are still
>>>>> within the URI scheme guidelines because we use a scheme name. By
>>>>> defining our own scheme, we are then free to choose how the
>>>>> "hierarchical part" looks. Arguably we could go for a less generic
>>>>> scheme name like "faces" or "jsf":
>>>>>
>>>>> xmlns:pete="faces:composite:components/pete"
>>>>>
>>>>> which is a bit longer but more generic...
>>>>>
>>>>
>>>> I like this approach. Of the two, part of me thinks the second might be
>>>> the better choice, as it gives us a bit more flexibility to add things
>>>> under the faces scheme, thus kind of grouping things together, but
>>>> another part of me wonders if we'd ever want to do that, given the
>>>> context of the discussion (YAGNI ;). However, it's only 6 characters (or
>>>> 4 for "jsf:"), so I don't see the harm in the slightly longer proposal.
>>>>
>>>
>>>
>>> I would prefer jsf:composite:jim for components under resources/jim, and
>>> jsf:composite:comp/jim for components under resources/comp/jim.  Two
>>> characters might not seem like a lot, but why not use jsf instead of faces
>>> if it signifies the same thing to users and is shorter?  (We already use
>>> "jsf" in the Ajax library.)
>>>
>>> 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/ceecef69/attachment.html