You just change com.transform.PartnerTransform, according to my
(abbreviated: com.Transform) version, You DO NOT have to touch or worry
about AdapterN.
-W
On Thu, Sep 24, 2009 at 12:37 PM, Ioannis Mavroukakis <
imavroukakis_at_gameaccount.com> wrote:
> That's correct, so since N changes, how do I know which N to set it's
> behaviour for?
>
>
>
> On 24 Sep 2009, at 11:09, Wolfgang Laun wrote:
>
> 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
>>
>>
>>
>> ______________________________________________________________________
>> 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
>
>