Code-completion works for me today as I simply run ant codegen and
include the build/gensrc directory in the list of source directories in
my IDE. That was one of the reasons why I changed the build to generate
the gensrc directory and why I moved the sources from src to src/java
for HEAD: To make it easier to build FOP within an IDE without the need
for running the Ant build every time, thus improving build speed a lot.
I'm indifferent whether you go forward with this or not. I personally
think it's unnecessary.
On 17.01.2004 02:05:05 Glen on bugzilla wrote:
I'd like to have them retained, but put into (1) file, actually, just added to
the Constants interface (as inner interfaces), say adding about 600 lines in
that interface for them all. (I can modify the XSLT code to accomplish that.)
We get rid of those 45 files, and they will be no longer autogenerated with
each build (but, as with the current Constants.java, we retain the XSLT to re-
generate it when we like.)
Reason why? I *think*, over the long-term, it is much more programmer-friendly
because many/most developers use IDE's with code-complete. I.E., you type in
the property value interface name, hit the ., and then you automatically see
the 5-7 values relevant for that property. This saves the programmer the
headache of looking at the spec each time for which prop values you need to
code against, or trying to recall from a huge Constants list the actual values
you need, and also making sure all the property options have been coded
against. I think it will be a nice sanity-saver for coders. If not, we can
always excise them later from Constants.java.
Thoughts on this?
Jeremias Maerki
