The latter part only.
~Sandeep
On 1/9/07, Stephen Winnall <[EMAIL PROTECTED]> wrote:
Does that mean you're going to have
<blah ...>
<results ...>
<listOfA>
<instanceOfA />
</listOfA>
<listOfB>
<instanceOfB />
</listOfB>
...
</results>
</blah>
or:
<blah ...>
<results ...>
<listOfA>
<instanceOfA />
</listOfA>
</results>
</blah>
<blah ...>
<results ...>
<listOfB>
<instanceOfB />
</listOfB>
</results>
</blah>
...?
Steve
On 9 Jan 2007, at 12:56, Sandeep wrote:
> Slight clarification from my side:
>
> Every xml instance looks like:
> <blah ...>
> <results ...>
> <listOfA>
> <instanceOfA />*
> </listOfA>
> </results>
> </blah>
>
> Now "listOf<?>" is there for all xml to return a list of element
> called <?>
> So, in effect by following the same xml structure you can get a list
> of Cars, Chocolates, Rivers whatever. There is no relation among the
> objects (i.e. <?>).
>
> Now, if I define a schema for A and B and run Sourcecodegenerator,
> classes like "blah" and "results" get generated multiple times!!
>
> How do I solve this, any idea, anybody?
>
> ~Sandeep
>
>
> On 1/9/07, Stephen Winnall <[EMAIL PROTECTED]> wrote:
>> Sandeep
>>
>> I'm not an expert on XML Schema as such, but I thought it had some
>> sort of inheritance so you could define a schema for the following
>> sort of structures:
>>
>> <blah ...>
>> <results ...>
>> <list>
>> <abstactInstanceOfAorBorC />*
>> </list>
>> </results>
>> </blah>
>>
>> and then specify that <instanceOfA> is-a <abstractInstanceOfAorBorC>.
>> There's an introduction to this sort of thing at http://
>> www-128.ibm.com/developerworks/library/x-flexschema .
>>
>> However, I don't know if the SourceGenerator can handle that sort of
>> thing.
>>
>> Steve
>>
>> On 9 Jan 2007, at 11:11, Sandeep wrote:
>>
>> > Thanks Steve!
>> >
>> > Let me tell you my venture into mapping.xml.
>> >
>> > This is the product I am working for: diff. modules of this product
>> > exchange information by passing raw xml over http (legacy stuff, no
>> > open standards followed). I am trying to bring in Castor for data
>> > binding:-)
>> >
>> > The xml structure for any object "A" looks somewhat like this:
>> > <?xml version='1.0' encoding='UTF-8' ?>
>> > <!DOCTYPE blah SYSTEM 'http://10.72.181.103:8088/server.dtd'>
>> > <blah version='1.0' xmlns='http://www.blah.com/xml'>
>> > <results passes="true">
>> > <A>
>> > <instanceOfA>
>> > </instanceOfA>
>> > <instanceOfA>
>> > </instanceOfA>
>> > ....
>> > </A>
>> > </results>
>> > </blah>
>> >
>> > Now this is the problem. I have to write schemas for 100s of
>> different
>> > objects like A.
>> > But then all the schemas will begin with blah and results and
>> then the
>> > actual "meat".
>> >
>> > So, I decided to go for mapping (and thanks to its location
>> attribute)
>> > like the below:
>> > <mapping>
>> > <class name="CollectionOfA" auto-complete="true">
>> > <map-to xml="blah" />
>> > <field name="listOfA" collection="arraylist"
>> type="BeanOfA" >
>> > <bind-xml name="instanceOfA"
>> location="results/A" />
>> > </field>
>> > </class>
>> > <class name="BeanOfA" auto-complete="true">
>> > .....and all the properties of A goes here
>> > </class>
>> > </mapping>
>> >
>> > Do you see any solution for defining schemas for all those beans
>> where
>> > every xml has those blah/results to begin with?
>> >
>> > ~Sandeep
>> >
>> >
>> > On 1/9/07, Stephen Winnall <[EMAIL PROTECTED]> wrote:
>> >> I think that working from an XML schema is to be preferred if you
>> >> have that option. The advantages are
>> >>
>> >> 1) you can do a good design for your XML;
>> >> 2) you can reuse any standards which might be available.
>> >>
>> >> Since data tends to hang around much longer than programs (and get
>> >> processed by more than one language), I'd spend more time
>> making sure
>> >> the data was as well organised as possible.
>> >>
>> >> Steve
>> >>
>> >> On 9 Jan 2007, at 10:33, Sandeep wrote:
>> >>
>> >> > Hi
>> >> >
>> >> > Which is better:
>> >> > 1. Define a schema for a java bean, auto-generate the source
>> >> code and
>> >> > get the validation done by castor while populating the bean from
>> >> a xml
>> >> > instance.
>> >> >
>> >> > 2. Hand code the java bean. Define a mapping file. Populate the
>> >> java
>> >> > bean from a xml instance through castor. I don't think I need to
>> >> > define a schema here (correct me, if I am wrong)
>> >> >
>> >> > Advantage for 1) is validation of data types and values can be
>> >> > performed by castor.
>> >> > Advantages for 2) are flexibility to add application specific
>> >> helper
>> >> > methods to the bean, or when you cannot touch the source for
>> the
>> >> > bean.
>> >> >
>> >> > Obviously, advantage of one is the disadvantage for the other.
>> >> >
>> >> > So, how can I get the best of both worlds? I want to hand code
>> >> my bean
>> >> > class (not use SourceCodegenerator). I want to define the schema
>> >> apart
>> >> > from the mapping so that castor can validate the xml instance
>> >> against
>> >> > the schema for both data types and some values.
>> >> >
>> >> >
>> >> > TIA
>> >> >
>> >> > ~Sandeep
>> >> >
>> >> >
>> >>
>> ---------------------------------------------------------------------
>> >> > To unsubscribe from this list please visit:
>> >> >
>> >> > http://xircles.codehaus.org/manage_email
>> >> >
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe from this list please visit:
>> >>
>> >> http://xircles.codehaus.org/manage_email
>> >>
>> >>
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe from this list please visit:
>> >
>> > http://xircles.codehaus.org/manage_email
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
