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