[dbdoclet] Re: Constant field values revisited - appendix vs chapter?

Hi all,

an interesting thing related to this - I had a constant with the empty =
string "" as the value. Of course that ended up as a total blank in the =
constant values table... Has caused a bit of confusion, and would only =
be solved by handling the empty string as a special case (surrounding it =
with quotes).=20

Then again, it might just be a good idea to surround all string-valued =
constants with quotes. After all, that is what JavaDoc does with HTML.

--Jere

> -----Original Message-----
> From: dbdoclet-bounce@xxxxxxxxxxxxx
> [mailto:dbdoclet-bounce@xxxxxxxxxxxxx]On Behalf Of ext Clifton L.
> McLellan
> Sent: Thursday, March 17, 2005 12:26 AM
> To: dbdoclet@xxxxxxxxxxxxx
> Subject: [dbdoclet] Re: Constant field values revisited - appendix vs
> chapter?
>=20
>=20
> Hi Michael,
>=20
> If you are looking at constant field values code could you also take a
> look at escaping entities in the constant values?  For=20
> example, we have
> tools that build SQL expressions interactively and have=20
> definitions like
> the following:
>=20
>   public final static String OPER_GREATER_THAN           =3D ">";
>   public final static String OPER_GREATER_THAN_OR_EQUALS =3D ">=3D";
>   public final static String OPER_LESS_THAN              =3D "<";
>   public final static String OPER_LESS_THAN_OR_EQUALS    =3D "<=3D";
>=20
> When processed, dbdoclet creates constructs like:
>=20
>   <row>
>     <entry><para>OPER_GREATER_THAN</para></entry>
>     <entry><para>></para></entry>
>   </row>
>   <row>
>     <entry><para>OPER_GREATER_THAN_OR_EQUALS</para></entry>
>     <entry><para>>=3D</para></entry>
>   </row>
>   <row>
>     <entry><para>OPER_LESS_THAN</para></entry>
>     <entry><para><</para></entry>
>   </row>
>   <row>
>     <entry><para>OPER_LESS_THAN_OR_EQUALS</para></entry>
>     <entry><para><=3D</para></entry>
>   </row>
>=20
> which fails on OPER_LESS_THAN when it finds two consecutive left angle
> brackets. My current (simplistic) solution is to change our=20
> source code
> to
>=20
>   public final static String OPER_GREATER_THAN           =3D "&gt;";
>   public final static String OPER_GREATER_THAN_OR_EQUALS =3D =
"&gt;=3D";
>   public final static String OPER_LESS_THAN              =3D "&lt;";
>   public final static String OPER_LESS_THAN_OR_EQUALS    =3D =
"&lt;=3D";
>=20
> before processing with dbdoclet. Perhaps other people have=20
> seen the same
> problem.=20
>=20
> --
> Thanks for the great tool!
> Clifton
>=20
> Clifton L. McLellan
> Senior Software Engineer
> Predicate Logic, Inc.
> =20
>=20
> -----Original Message-----
> From: dbdoclet-bounce@xxxxxxxxxxxxx
> [mailto:dbdoclet-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Fuchs
> Sent: Wednesday, March 16, 2005 12:49 PM
> To: dbdoclet@xxxxxxxxxxxxx; Jere.Kapyaho@xxxxxxxxx
> Subject: [dbdoclet] Re: Constant field values revisited - appendix vs
> chapter?
>=20
>=20
> Hello Jere,
>=20
> I will make this configurable in the next release 0.64.
>=20
> Regards
> Michael
>=20
> Jere.Kapyaho@xxxxxxxxx schrieb:
>=20
> >Hi,
> >
> >some time ago Michael implemented the list of constant field=20
> values. =3D=20
> >Currently it is an appendix element, as that was what seemed=20
> sensible =3D
>=20
> >then. However, that caused a problem in a project where we have a =3D =

> >structure like this:
> >
> >Book
> >    Part I. Overview
> >    Part II. Reference  <-- the only part created by dbdoclet
> >       Chapter: Package X
> >       Chapter: Package Y
> >       Appendix: Constant field values
> >    An Appendix=3D20
> >    Another appendix
> >    Index
> >
> >Now what happens is that if you have one or more appendices=20
> at the book
>=20
> >=3D level, the labeling starts at 'B' since the constant=20
> values appendix=20
> >=3D already takes up the first 'A' label...=3D20
> >
> >I am thinking maybe the constant field values section would=20
> be better=20
> >as =3D a chapter instead of an appendix. What do you think?=20
> Could/should=20
> >this =3D be made configurable?
> >
> >--Jere
> >
> >--=3D20
> >Jere K=3DE4pyaho (jere U+002E kapyaho U+0040 nokia U+002E com) Senior =

> >Design Engineer, Java Platform Standardization Technology Platforms
> >Nokia Corporation
> >
> >
> >
> > =20
> >
>=20
>=20
>=20
>=20
>=20
>=20
>=20

Other related posts: