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

