Consider making CodeList.valueOf(String) to ignore whitespaces
Description
Environment
Attachments
Activity

codehaus April 10, 2015 at 4:51 PM
CodeHaus Comment From: desruisseaux - Time: Fri, 24 Jul 2009 06:31:27 -0500
---------------------
<p>Commited a <tt>Filter</tt> inner interface with an <tt>accept(CodeList<?></tt> method as of revision 1443.
New method: <tt>CodeList.valueOf(Class, Filter)</tt>.
Deprecated method: <tt>CodeList.matches(String)</tt> since it applies arbitrary rules (ignoring case, <em>etc.</em>).</p>

codehaus April 10, 2015 at 4:51 PM
CodeHaus Comment From: desruisseaux - Time: Thu, 23 Jul 2009 11:35:21 -0500
---------------------
<p>It may be better to define a <tt>Matcher</tt> inner interface with a <tt>boolean match(CodeList code, String name)</tt> method instead.</p>

codehaus April 10, 2015 at 4:51 PM
CodeHaus Comment From: desruisseaux - Time: Sun, 31 May 2009 10:11:26 -0500
---------------------
<p>According discussion on the mailing list, the opposite proposal (keep <tt>valueOf</tt> strict by removing its case-insensitive aspect) seems to have the preference. In such case, ignoring whitespaces and case would be left on implementor side. An open question is whatever we need to provide a hook in GeoAPI or not. For example a hook could be:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
<C <span class="code-keyword">extends</span> CodeList> C valueOf(<span class="code-object">Class</span><C> type, <span class="code-object">String</span> identifier, Comparator<<span class="code-object">String</span>,<span class="code-object">String</span>> cmp);
</pre>
</div></div>
<p>i.e. compared to the current signature, a <tt>Comparator</tt> argument would be added.</p>

codehaus April 10, 2015 at 4:51 PM
CodeHaus Comment From: desruisseaux - Time: Thu, 28 May 2009 06:29:55 -0500
---------------------
<p>Attached the proposed implementation as a patch file.</p>
Details
Details
Assignee
Reporter

The method http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/util/CodeList.html#valueOf(java.lang.Class,%20java.lang.String) - CodeList.valueOf(String) first searchs for an existing CodeList matching the given string before to create a new one. The current implementation is case-insensitive, so if a user asks for a "utf8" code list while the existing one is named "UTF8", the existing code list is returned.
We propose to additionaly ignore whitespaces. So if the user asks for "UTF 8", it is recognized as well as the existing "UTF8" code list. Currently it is not. Likewise if the user asks for "document hardcopy" in PresentationForm, it will be recognized as "documentHardcopy".
Note: it would be possible to extend the proposal for ignoring the "_" character as well, so in the above example "document hardcopy" would also be recognized as the same as "DOCUMENT_HARDCOPY", which is the same code list. The current proposal is limited to whitespaces because it is less at risk of being disruptive, given that whitespaces are normally never part of identifiers.