Thanks, Ralf. Now, having said that, I'd like to see this sample
scenario to be turned into a new XML HOW-TO document for the use of
polymorphism with Castor XML. Feel like helping us a bit ?

Werner

[EMAIL PROTECTED] wrote:
> That works - Thank you for walking me through this!
> Ralf Joachim writes:
>> Can you try the following change to your mapping:
>> <class name="model.ApplicationWindow">
>>     <field name="controls" type="model.GeneralControl"
>>            collection="vector">
>>         <bind-xml node="element" auto-naming="deriveByClass"/>
>>     </field>
>> </class>
>> Having said that auto-naming is only used when no name is specified at
>> bind-xml element and that its default value is deriveByName. With
>> deriveByName it uses the name of the field element that contains the
>> bind-xml element while deriveByClass should use the nameof the class
>> marshalled without package. I hope this also helps to see the xmlns to
>> disapear.
>> Regards
>> Ralf
>>
>> [EMAIL PROTECTED] schrieb:
>>> This worked...somewhat.  Order was preserved, but the resulting XML
>>> did not retain the original element tag names.
>>> Input XML
>>> <application_window id="1000">
>>>  <field id="1002" is_multiline="yes">
>>>     <pos x="100" y="120"/>
>>>     <size h="400" w="300"/>
>>>   </field>
>>>    <label id="1005">
>>>        <pos x="100" y="130"/>
>>>      <size w="30" h="10"/>
>>>      <text>This is a label</text>
>>>    </label>
>>> <application_window>
>>> Mapping
>>> <class name="model.ApplicationWindow">
>>>  <field name="controls" type="model.GeneralControl" collection="vector">
>>>         <bind-xml node="element"/>
>>>     </field>
>>> </class>
>>> <class name="model.GeneralControl">
>>> </class>
>>> <class name="model.Label"  extends="model.GeneralControl">
>>>     <field> ...field definitions
>>> </class>
>>> <class name="model.Field"  extends="model.GeneralControl">
>>>     <field> ...field definitions
>>> </class>
>>> Resulting XML file:
>>> <application_window id="1000">
>>>       <controls xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>>           id="1002" enabled="yes" visible="yes" is_editable="yes"
>>> xsi:type="field">
>>>           <pos x="100" y="120"/>
>>>           <size h="400" w="300"/>
>>>       </controls>
>>>       <controls xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>>           id="1005" enabled="yes" visible="yes" xsi:type="label">
>>>           <pos x="100" y="130"/>
>>>           <text>This is a label</text>
>>>           <size h="10" w="30"/>
>>>       </controls>
>>>   </application_window>
>>> Does this mean I must use XSLT to get the proper output?
>>> Ralf Joachim writes:
>>>> Hi Justin,
>>>> as Castor supports inheritance and all your components have a common
>>>> base class it should be possible to put them all into one
>>>> collection. You need to do:
>>>> - define a mapping of your base class, let's call it Component
>>>> - define in mapping that your Button, Label, and so on extend Component
>>>>   <class name="Button" extends="Component">
>>>> - define that your collection holds Components
>>>> Hope this helps
>>>> Ralf
>>>> [EMAIL PROTECTED] schrieb:
>>>>> If that behavior is true for collections, then is there a way to
>>>>> map different elements to the same collection - in my case, put a
>>>>> button, label, etc. into  the same vector within a containing class
>>>>> (they all inherent from the same base class)?  That would solve my
>>>>> problem. However, it does not seem that Castor supports this.
>>>>> Thank you for all the responses!
>>>>> Justin
>>>>> Werner Guttmann writes:
>>>>>> Ralf,
>>>>>> I am not 100% sure how Castor behaves in such a case. I think it
>>>>>> will depend on whether somebody is using a mapping file or working
>>>>>> off a set of generated classes. In the latter case, things will be
>>>>>> marshalled out corresponding the order in which they have been
>>>>>> defined as part of the <xsd:sequence> declaration (and as of
>>>>>> 1.1.1, a sequence order check will be performed during
>>>>>> unmarshalling).
>>>>>> In the former case, when a mapping file is used, the elements of a
>>>>>> class will me marshaled in the sequence the field mappings have
>>>>>> been defined in the mapping file, as the XMLMappingLoader uses
>>>>>> exactly this sequence to inject the field descriptors into the
>>>>>> class descriptor at runtime.
>>>>>> For collections, I think the elements will be marshalled out in
>>>>>> exactly the sequence they appear in the collection (which is the
>>>>>> one that should have been built during unmarshalling).
>>>>>> I hope this makes things a bit clearer.
>>>>>> Werner
>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>> Von: Ralf Joachim [mailto:[EMAIL PROTECTED]
>>>>>>> Gesendet: Mittwoch, 30. Mai 2007 11:28
>>>>>>> An: [email protected]
>>>>>>> Betreff: Re: [castor-user] Re: Preserving Unmarshall Sequence
>>>>>>> Hi Werner,
>>>>>>> I think it is reasonable to expect Castor to marshal objects in a
>>>>>>> collection/list in the sequence they are contained in the list
>>>>>>> and do
>>>>>>> not reorder them in any way.
>>>>>>> If this isn't possible yet, I think this should be added and be
>>>>>>> configured to be the default behaviour at least for introspection
>>>>>>> and
>>>>>>> when using mapping.
>>>>>>> Regards
>>>>>>> Ralf
>>>>>>> Werner Guttmann schrieb:
>>>>>>> > Within Castor, other than using multiple mapping files (with
>>>>>>> each of
>>>>>>> > them specifying the required sequence of fields), no.
>>>>>>> >
>>>>>>> > And with regards to abandoning Castor, I know that e.g. JAXB
>>>>>>> allows you
>>>>>>> > to define one sequence only (by the means of a JAXB
>>>>>>> annotation), and not
>>>>>>> > multiple ones.
>>>>>>> >
>>>>>>> > If I were you, I'd consider using XSLT (whether manually or
>>>>>>> within a
>>>>>>> > framework such as Cocoon) on top of Castor, to sort the
>>>>>>> original output
>>>>>>> > according to your specific needs. Castor's Marshaller supports
>>>>>>> > marshalling to SAX events, which could be directly feed into
>>>>>>> e.g. a
>>>>>>> > Cocoon pipeline or a JAXP transformer.
>>>>>>> >
>>>>>>> > Regards
>>>>>>> > Werner
>>>>>>> >
>>>>>>> > [EMAIL PROTECTED] wrote:
>>>>>>> >> The sequence could be different each time - the xml document
>>>>>>> describes
>>>>>>> a
>>>>>>> >> gui , and the order in which the elements appear in the file
>>>>>>> determines
>>>>>>> >> the tab order in the legacy system, hence the requirement to
>>>>>>> marshall
>>>>>>> >> objects in a particular sequence.
>>>>>>> >> So, in one file, the order may need to be label, button,
>>>>>>> field, field,
>>>>>>> >> but in another it could be field, button, field, button, and
>>>>>>> so on.
>>>>>>> >> Is there any solution to this? Or do I need to abandon Castor
>>>>>>> - which
>>>>>>> >> would be a shame.
>>>>>>> >>
>>>>>>> >> Werner Guttmann writes:
>>>>>>> >>> How about trying to match the sequence of your field mappings
>>>>>>> in the
>>>>>>> >>> mapping file to the expected sequence ? If you use a mapping
>>>>>>> file,
>>>>>>> >>> Castor simply marshalls fields as encountered in the mapping
>>>>>>> file.
>>>>>>> >>> Werner
>>>>>>> >>> [EMAIL PROTECTED] wrote:
>>>>>>> >>>> Can Castor preserve the sequence of elements it unmarshalls
>>>>>>> when it
>>>>>>> goes
>>>>>>> >>>> to marshall things back up?
>>>>>>> >>>> Example:
>>>>>>> >>>> XML going in..
>>>>>>> >>>> <window>
>>>>>>> >>>>  <button> Button1 </button>
>>>>>>> >>>>  <label> Label1 </label>
>>>>>>> >>>>  <button> Button2 </button>
>>>>>>> >>>> </window>
>>>>>>> >>>> XML going out
>>>>>>> >>>> <window>
>>>>>>> >>>>  <button> Button1 </button>
>>>>>>> >>>>  <button> Button2 </button>
>>>>>>> >>>>  <label> Label1 </label>
>>>>>>> >>>> </window>
>>>>>>> >>>> When being marshalled back up, Castor will group all the
>>>>>>> buttons
>>>>>>> >>>> together, labels, etc. in the order as defined by the
>>>>>>> mapping file.
>>>>>>> >>>> However, for reasons that are beyond my control, I need to
>>>>>>> be able to
>>>>>>> >>>> write out the XML file in the same order that I read it in.
>>>>>>> I tried
>>>>>>> >>>> putting all elements in a single vector, but I get an error
>>>>>>> complaining
>>>>>>> >>>> of multiple instances of the same field in the mapping file.
>>>>>>> >>>> Any suggestions?
>>>>>>> >>>> Thank you,
>>>>>>> >>>> Justin
>>>>>>> >>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> >>>> 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
>>>>>>> -- 
>>>>>>> Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
>>>>>>> Ralf Joachim
>>>>>>> Raiffeisenstraße 11
>>>>>>> 72127 Kusterdingen
>>>>>>> Germany
>>>>>>> Tel.   +49 7071 3690 52
>>>>>>> Mobil: +49 173 9630135
>>>>>>> Fax    +49 7071 3690 98
>>>>>>> Internet: www.syscon.eu
>>>>>>> E-Mail: [EMAIL PROTECTED]
>>>>>>> Sitz der Gesellschaft: D-72127 Kusterdingen
>>>>>>> Registereintrag: Amtsgericht Stuttgart, HRB 382295
>>>>>>> Geschäftsleitung: Jens Joachim, Ralf Joachim
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> 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
>>>>
>>>> -- 
>>>> Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
>>>> Ralf Joachim
>>>> Raiffeisenstraße 11
>>>> 72127 Kusterdingen
>>>> Germany
>>>> Tel.   +49 7071 3690 52
>>>> Mobil: +49 173 9630135
>>>> Fax    +49 7071 3690 98
>>>> Internet: www.syscon.eu
>>>> E-Mail: [EMAIL PROTECTED]
>>>> Sitz der Gesellschaft: D-72127 Kusterdingen
>>>> Registereintrag: Amtsgericht Stuttgart, HRB 382295
>>>> Geschäftsleitung: Jens Joachim, Ralf Joachim
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>> -- 
>> Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
>> Ralf Joachim
>> Raiffeisenstraße 11
>> 72127 Kusterdingen
>> Germany
>> Tel.   +49 7071 3690 52
>> Mobil: +49 173 9630135
>> Fax    +49 7071 3690 98
>> Internet: www.syscon.eu
>> E-Mail: [EMAIL PROTECTED]
>> Sitz der Gesellschaft: D-72127 Kusterdingen
>> Registereintrag: Amtsgericht Stuttgart, HRB 382295
>> Geschäftsleitung: Jens Joachim, Ralf Joachim
>> ---------------------------------------------------------------------
>> 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

Reply via email to