Hi, Paul,
Thanks a lot for your help!
Yes. I do the same as you for multiple
schemas - generate separate packages for each schema. And also, I run the
generator only once for each schema.
I have been trying to create a unique binding file
that can handle the duplicated elements of "row". Since, for my case, the
parsing of any schema is an automatic process, I can't create separate
binding files for each schema beforehand.
I hope the generator can allow me to use
the following kind of syntax (like XPath) to describe the matching elements
in one binding file:
(Pseudo-Code)
<cbf:elementBinding name="*/row">
- Try to
match any element who has a sub-elment of "row", or "*/*/*/row" if there are
other sub-elements in
between.
<cbf:java-class name= @name+"Row"/>
<cbf:java-class name= @name+"Row"/>
- Then the
java class name for the "row" element will be appended with its
parent's element name described as [EMAIL PROTECTED]
</cbf:elementBinding>
</cbf:elementBinding>
I'm not sure if the sourceGenerator CAN
process the kind of binding like above or not. Also, I assume that for all
other elements that are not matched with "*/row", they will be
continually processed by using a default binding other than the customized
one. Is this correct?
I can't find a doc/chapter that describes how
the XPath can work together with Castor SourceGenerator for above purpose. Would
you please point me to where I can find some examples that could help me to
build a generic binding file to handle above case?
Thanks so much!
Best Regards,
Joanna
----- Original Message -----
From: "Paul Grillo" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, July 05, 2005 2:20 PM
Subject: RE: [castor-user] How to resolve java file
name confliction when use SourceGenerator to generate java files for schema with
same-name elements?
> issue. We also have multiple schemas and we generate separate packages
> for each schema. We also have a separate binding file for each
> schema/package.
>
> If you don't generate separate packages, I assume you run the generator
> once for each schema?
>
> We simply use a naming convention - based on the name of the schema we
> look for a corresponding binding file.
>
> On windows we write a simple batch file where we pass in the schema name
> as a parameter and use that to pick up the appropriate binding file.
>
> And yes, creating the binding file once is hand done. Someone must
> determine where the duplicates are and resolve them in a binding file.
>
> I haven't tried it, but you may be able to put it all in one binding
> file assuming that you can uniquely describe the path to the duplicate
> class/element name. If not, well, separate files should work as well.
> The idea, hopefully, is you do this once. Then the script can be rerun
> when needed to recreate the code. Of course, if a schema is changed in
> the future to add more duplicate element names you'll have to edit your
> binding file(s)
>
>
> Hope this is helpful.
>
>
>
> -----Original Message-----
> From: Juan Wu [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 05, 2005 4:02 PM
> To: [email protected]
> Subject: Re: [castor-user] How to resolve java file name confliction
> when use SourceGenerator to generate java files for schema with
> same-name elements?
>
> Hi, Paul and Lastric,
>
> Thanks for your help. I can't modify the schema itself to make the
> duplication of elements disappear in the schema.
>
> I think the binding file will need to be generated for each of the
> schema
> and can only deal with a specific schema instance, do I understand it
> correctly? For my case, I need to automatically parse any kind of schema
>
> which may or may not contain duplicated elements. And the duplicated
> element' names may be different from schema to schema. Also, I can't
> generate a different binding file for each schema since this is part of
> the
> automatic parsing process.
>
> I'm not sure how this generic problem about duplicate elements can be
> resolved by just ONE generic binding file? Please advice.
>
> Thank you very much again.
>
> Best Regards,
> Joanna
>
> ----- Original Message -----
> From: "Paul Grillo" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Thursday, June 30, 2005 5:17 AM
> Subject: RE: [castor-user] How to resolve java file name confliction
> when
> use SourceGenerator to generate java files for schema with same-name
> elements?
>
>
>> You'll probably want to use a binding file when generating the java
>> source. use the -binding-file [filename] in your sourcegenerator
>> statement.
>>
>>
>>
>> The binding file indicates how you want to handle these and other
> issues.
>>
>> an example might look like the following, but I can't guarantee its
>> accuracy. essentially you are indicating that you want to create a
> class
>> called AccountPayableRow when you encounter the element you refer to.
>>
>> The only thing I'm not sure of is if you will need a mapping file when
> you
>> unmarshal at runtime. that is you may then have to indicate in a
> mapping
>> file the mapping from the xml data back. At any rate this or a
>> combination of both of these will solve your problem. We had the
> exact
>> same issue where we were not at liberty to change the XSD, and
> overcame it
>> in this way.
>>
>>
>>
>> <?xml version="1.0"?>
>>
>> <binding xmlns:cbf="http://www.castor.org/SourceGenerator/Binding"
>> defaultBindingType="element">
>>
>> <cbf:elementBinding name="/AccountPayble /row">
>>
>> <cbf:java-class name=" AccountPaybleROW"/>
>>
>> </cbf:elementBinding>
>>
>> </binding>
>>
>>
>> ________________________________________
>> From: Juan Wu [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, June 30, 2005 4:10 AM
>> To: [email protected]
>> Cc: [EMAIL PROTECTED]
>> Subject: [castor-user] How to resolve java file name confliction when
> use
>> SourceGenerator to generate java files for schema with same-name
> elements?
>>
>> Hi,
>> I try to use SourceGenerator to generate java files for the following
>> schema. It has two top level elements AccountPayble and
> PaymentMethods.
>> However, they all have a sub-element which is called the same as
> "row".
>> And, these two "row" elements contain different sub-elements.
>> The SourceGenerator will generate a java file for each of the elements
> -
>> however, I only get one "row `.java" file related with the 2nd element
>
>> (PaymentMethods), since it overwrites the "row.java" generated for the
> 1st
>> element (AccountPayble).
>> Is there a way that can let it generate two different row.java files
> that
>> won't overwrite each other in an non-interactive way (with -f option)?
>
>> Since this process doesn't run on a command window, I can't manually
> type
>> "y|n" when it asks for overwriting.
>> In another word, would it be possible to generate java files for the 2
>
>> "row" elements named like "AccountPayble_row.java" and
>> "PaymentMethods_row.java" instead of just "row.java" when there is
> such
>> element name conflict?
>> I have set "org.exolab.castor.builder.javaclassmapping=type" in the
>> castorbuilder.properties.
>> Your any suggestions or answers will be highly appreciated.
>> Thanks a lot!
>> Joanna
>> ...... part of the schema which has elements' name conflict......
>> <element maxOccurs="1" minOccurs="0" name="AccountPayble">
>> <complexType>
>> <sequence>
>> <element maxOccurs="unbounded" minOccurs="0" name="row">
>> <complexType>
>> <all>
>> <element maxOccurs="1" minOccurs="0" name="AccountType"
> type="string"/>
>> <element maxOccurs="1" minOccurs="0" name="AccountCode"
> type="string"/>
>> </all>
>> </complexType>
>> </element>
>> </sequence>
>> </complexType>
>> </element>
>> <element maxOccurs="1" minOccurs="0" name="PaymentMethods">
>> <complexType>
>> <sequence>
>> <element maxOccurs="unbounded" minOccurs="0" name="row">
>> <complexType>
>> <all>
>> <element maxOccurs="1" minOccurs="0" name="PaymentMethodCode"
>> type="string"/>
>> </all>
>> </complexType>
>> </element>
>> </sequence>
>> </complexType>
>> </element>
>>
>> -------------------------------------------------
>> If you wish to unsubscribe from this list, please
>> send an empty message to the following address:
>>
>> [EMAIL PROTECTED]
>> -------------------------------------------------
>>
>>
>>
>
>
> -------------------------------------------------
> If you wish to unsubscribe from this list, please
> send an empty message to the following address:
>
> [EMAIL PROTECTED]
> -------------------------------------------------
>
>
>
>
> -------------------------------------------------
> If you wish to unsubscribe from this list, please
> send an empty message to the following address:
>
> [EMAIL PROTECTED]
> -------------------------------------------------
>
>
>
