users@jaxb.java.net

Re: Issues with arbitrary transformation of boolean to String

From: Wolfgang Laun <wolfgang.laun_at_gmail.com>
Date: Thu, 24 Sep 2009 12:09:36 +0200

Foo uses some AdapterN, where N might change, but all AdapterN variants use
the Transform methods parseX and printX. Since this remains the same class
for all variants, you can set its behaviour, to do whatever is appropriate.
Setting the output values identical to the input values you achieve a no-op.
-W

On Thu, Sep 24, 2009 at 10:20 AM, Ioannis Mavroukakis <
imavroukakis_at_gameaccount.com> wrote:

> Hello :-)
>
> I suppose I could but what I want to achieve is plugability as not all use
> cases will need this transform but All of them will use Foo. Hence in the
> packages of these use cases I want to be able to redefine the adapter.. Does
> that make sense?
>
> On 23 Sep 2009, at 22:24, No 0ne <no0ne_at_no0ne.org> wrote:
>
> On Wed, 2009-09-23 at 19:53 +0100, Ioannis Mavroukakis wrote:
>>
>>> Hi Wolfgang,
>>> Thanks for that, I had gotten as far as this. The reason why 0/1
>>> cannot be handled is that the wsdl endpoint has different definitions
>>> for true/false (S and N respectively. It's how it is and I cannot
>>> change it :-).
>>> My main issue is that I want to be able to supply an XmlAdaptor per
>>> use case, defining a different Transform class.
>>>
>> Make the Transform class implement "setTrueFalseTransliteration(char
>> ouiChar, char nonChar)" and adjust the true/false characters accordingly
>> with your use case (before serializing/deserializing your XML)?
>>
>> I can see how this is done on the api but as xjc is generating and
>>> annotating the source, I cannot see how I could overide the generated
>>> Adaptor at runtime. It would be nice if I could instruct xjc to
>>> generate an adaptor with a specific name which I could then unset and
>>> set with another one.
>>>
>> Repeating the suggestion above at a more generalized level: why cant you
>> keep the name constant but change the runtime *behaviour* of your
>> transformer accordingly to your needs?
>>
>>>
>>> Y.
>>>
>> no0ne
>>
>>
>>> On 23 2009, at 18:56, Wolfgang Laun <wolfgang.laun_at_gmail.com> wrote:
>>>
>>>
>>>
>>> I think what you need is
>>>>
>>>> <jxb:bindings
>>>>
>>>> node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/xsd:attribute[@name='bar']">
>>>> <jxb:property>
>>>> <jxb:baseType>
>>>> <jxb:javaType name="java.lang.String"
>>>> parseMethod="com.Transform.parse01ToString"
>>>> printMethod="com.Transform.printStringTo01" />
>>>> </jxb:baseType>
>>>> </jxb:property>
>>>> </jxb:bindings>
>>>>
>>>> which converts "0" or "1" in the XML to whatever the com.Transform
>>>> decides:
>>>>
>>>> package com;
>>>> import java.util.*;
>>>> public class Transform {
>>>> private static String ouiChar;
>>>> private static String nonChar;
>>>> public static void setOuiNon( String oui, String non ){
>>>> ouiChar = oui;
>>>> nonChar = non;
>>>> }
>>>> public static String parse01ToString( String value ){
>>>> return value.equals( "0" ) ? nonChar : ouiChar;
>>>> }
>>>> public static String printStringTo01( String impl ){
>>>> return impl.equals( ouiChar ) ? "1" : "0";
>>>> }
>>>> }
>>>>
>>>> All you have to do, is call the static method to define the "oui" or
>>>> "non" character.
>>>>
>>>> Although I don't see why the application cannot handle the "0" or
>>>> "1". Whatever.
>>>>
>>>> -W
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Sep 23, 2009 at 6:29 PM, Ioannis Mavroukakis
>>>> <imavroukakis_at_gameaccount.com> wrote:
>>>> I should also add, that on top of that, I need to be able to
>>>> pass at runtime an XMLAdapter that will override this
>>>> functionality,
>>>> so that String 0 or 1 can be mapped to any other textual
>>>> representation :-/
>>>>
>>>>
>>>> Y.
>>>>
>>>>
>>>> On 23 Sep 2009, at 17:27, Ioannis Mavroukakis wrote:
>>>>
>>>> No the XML will be a String 0 or 1, but what I want to
>>>>> transform it to, is String S or N respectively :-)
>>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>> Yiannis
>>>>>
>>>>> On 23 Sep 2009, at 17:15, Wolfgang Laun wrote:
>>>>>
>>>>> If the XML is a single letter, then parse must convert
>>>>>> from string to boolean, print vice versa. And the
>>>>>> javaType name is java.lang.Boolean.
>>>>>>
>>>>>> -W
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 23, 2009 at 4:51 PM, Ioannis Mavroukakis
>>>>>> <imavroukakis_at_gameaccount.com> wrote:
>>>>>> Hello fellow listers,
>>>>>>
>>>>>> I've got the following conundrum I'd like some
>>>>>> help with.
>>>>>>
>>>>>> Assume this schema (shortened for brevity)
>>>>>>
>>>>>> <xs:element name="Foo">
>>>>>> <xs:complexType>
>>>>>> <xs:complexContent>
>>>>>> <xs:attribute name="bar"
>>>>>> type="xs:string"/>
>>>>>> </xs:complexContent>
>>>>>> </xs:complexType>
>>>>>> </xs:element>
>>>>>>
>>>>>> In reality, bar is a boolean attribute (stay
>>>>>> with me) which I need for business reasons to
>>>>>> convert to a single character lexical
>>>>>> equivalent of true/false in another language,
>>>>>> for transport over a WSDL call.
>>>>>>
>>>>>> I thought that I could perhaps use a custom
>>>>>> binding to do my biding and extend that for
>>>>>> different use cases hence
>>>>>>
>>>>>> <bindings
>>>>>>
>>>>>> node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/xsd:complexContent/xsd:attribute[@name='bar']">
>>>>>> <property>
>>>>>> <baseType>
>>>>>> <javaType
>>>>>> name="java.lang.String"
>>>>>>
>>>>>>
>>>>>> parseMethod="com.transform.PartnerTransform.parseBooleanToString"
>>>>>>
>>>>>>
>>>>>> printMethod="com.transform.PartnerTransform.printStringToBoolean" />
>>>>>> </baseType>
>>>>>> </property>
>>>>>> </bindings>
>>>>>>
>>>>>> However I quickly realised that my cunning plan
>>>>>> to assign another XMLAdapter while initialising
>>>>>> the marshaller for each use case was blown out
>>>>>> of the water
>>>>>> as the adapter is randomly named by xjc, and
>>>>>> touching the generated classes is a no-no.
>>>>>>
>>>>>> Therefore, the grand question here is , is there
>>>>>> some arcane way to make jaxb do that, or should
>>>>>> I be looking at a different solution?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Yiannis
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail:
>>>>>> users-unsubscribe_at_jaxb.dev.java.net
>>>>>> For additional commands, e-mail:
>>>>>> users-help_at_jaxb.dev.java.net
>>>>>>
>>>>>>
>>>>>>
>>>>>> ______________________________________________________________________
>>>>>>
>>>>>
>
> This email has been scanned by the MessageLabs Email
>>>>>> Security System.
>>>>>> For more information please visit
>>>>>> http://www.messagelabs.com/email
>>>>>> ______________________________________________________________________
>>>>>>
>>>>>
>
>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ______________________________________________________________________
>>>>
>>>
>
> This email has been scanned by the MessageLabs Email Security
>>>> System.
>>>> For more information please visit http://www.messagelabs.com/email
>>>> ______________________________________________________________________
>>>>
>>>
>
>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
>> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>