Quoting "Werner Guttmann" <[EMAIL PROTECTED]>:
(...)
Okay, before having a go at this, let's get focused a bit. There's
already a work-around for this, as documented here:
http://castor.org/reference/html/xml.code.generator.html#d0e4989
Do I understand this correctly that using this option will enable me
to do the following:
<enumBinding name="...">
<enum-def>
<enumMember>
<value>M</value>
<javaName>M</javaName>
</enumMember>
<enumMember>
<value>m</value>
<javaName>m</javaName>
</enum-def>
</enumBinding>
and resolve the clash this way? or will this still upcase the 2nd javaName?
In other words, we are aware of this problem (and have been so for a
couple of years). Let me see whether this actually satisfies you
already.
Well, maybe I should explain the way we (want to) use castor: we are
targetting a changing schema, and the schema is the ultimate source
for what's right or wrong. Ultimately we want to generate all from the
schema: the ddl, the java code for (un)serialization, schema checking,
storing and reading to/from DB. Yup, even creating the DB for us. We
will soon be in a position where manpower will be low, so we're
naturally interested in a solution that will DTRT just given the
schema. Having to groom two files instead of one is like .. uh ..
suboptimal. Another option would be to generate the binding file from
the schema with a stylesheet application, although then we're slowly
going into a direction where we won't need Castor at all anylonger. If
we have to maintain binding files, one of the selling points of castor
(at least in our perception) is lost.
Nonetheless I'll try this.
And I am aware that this might still cause issues with code
generation for Java 5.0 and higher, but here I am not 100% sure. Can you
please try this, and see where it takes you. And please do come back and
let us know about your findings.
Given my disability (I'm confident on my side of things) to get castor
built, I'll try that. Thank you very much for the hint!
I thin that your fix might actually be a valid one, but with Java 1.4
and no real enums available, there was no option available.
Would you mind if I addressed the other shots later on ? Let's first
address your problem (and solve it), and then we'll take it from there,
right ?
No prob, you're the knowledgable guy about castor, not me. I'll (try
to) play by your rules. Monday is testing time.
(...)
shot 4: You generate code that doesn't compile when ignoring the case.
(Look at the source code generators output for the example I cited --
you're getting a clash for dual 'M's.)
Yes, we know. That's why we provide you with a binding file to manually
override the naming conventions as used by the XML code generator where
things do not work automagically. And that's on intention: we do NOT
want to be a product that knows how to avoid all possible naming collisions.
Yeah but why? It would be great if it avoided all possible naming
collisions by default, even on the cost of 'non-java' or 'ugly' names.
Human intervention is error-prone. Cars usually crash because they
have a human driver...
I understand that the java naming conventions are different, and that
you like to generate code that follows the java culture. But the XML
culture is different. E.g. Look at those two elements: <starts-with> and
<starts-With>. Yes it's braindead, but they are two different elements.
Generating method names incorporating the fragment startsWith for *both*
is just wrong with regard to the XML culture (shot 5?). As you see this
applies to applying java naming conventions _in general_ to xml stuff.
Yes the output is alien and ugly and ... Go complain to the W3C. It's
them who are braindead. If you want to make conformant XML processors,
you have to be braindead, too. There's just no choice.
See my answer to shot 4. To repeat it, the answer is NO. We simply don't
want to replicate (and thus multiply) their brain-deadness into the Java
world.
IMO the java world is not free of brain-deadness either so it's pain
or suffering :) But that's MO, and not related to our process here.
Thanks for the reply.
Regards,
-Martin
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
