Here is the bzipped patch and two new source files which are also needed.

The changes to the DTD are attributes: defaultSerialization (database) 
and serialization (table) (java|xml, defaults to the existing Java 
serialization - BaseObject implements java.io.Serializable); and the 
attribute xmlElement (on a column) can be used to name an XML element 
explicitly (otherwise it uses the column name, with underscores removed 
and characters following underscores capitalised, remaining case 
unchanged).

The build obviously now also includes the betwixt jar.

BaseObject now includes a couple of protected methods, 
getXMLIntrospector() and toXml(), in case you wanted to override the 
default behaviour in some way. It also provides methods to implement the 
Externalizable API, but doesn't actually declare itself to implement 
Externalizable (that is done by the generated Object). Generated Objects 
which are Externalizable also have a getElementDescriptor method which 
is used by the BaseObject to configure betwixt to generate correct XML 
for that object.

Note that the externalizing is only one-way (out) at the moment. Using 
betwixt to construct data trees from XML is left as an short exercise 
for the reader ;-)

Gareth

Attachment: toxml.patch.bz2
Description: Binary data

/*
 * Created by IntelliJ IDEA.
 * Date: Sep 6, 2002
 * Time: 8:33:17 AM
 *
 * @author gareth
 * @version $Revision$
 */

package org.apache.torque.engine.database.model;

public interface Serialization {
    String JAVA = "java";
    String XML = "xml";
}
/*
 * Created by IntelliJ IDEA.
 * Date: Sep 6, 2002
 * Time: 1:43:42 PM
 *
 * @author gareth
 * @version $Revision$
 */

package org.apache.torque.engine.database.model;

import org.apache.torque.engine.EngineException;
import org.apache.commons.lang.StringUtils;

import java.util.List;
import java.util.StringTokenizer;

public class XmlElementGenerator implements NameGenerator {
    /**
     * @param inputs a List of one element: the field name
     */
    public String generateName(List inputs)
            throws EngineException {
        String schemaName = (String) inputs.get(0);
        StringBuffer name = new StringBuffer();
        StringTokenizer tok = new StringTokenizer
            (schemaName, String.valueOf(STD_SEPARATOR_CHAR));
        while (tok.hasMoreTokens())
        {
            String namePart = (String) tok.nextElement();
            name.append(StringUtils.capitalise(namePart));
        }
        return name.toString();
    }
}


On Thursday, September 19, 2002, at 09:46  am, Matt Koranda wrote:

> I would be very interested in this, could you post some code or mail me
> direct?
>
> Thank you in advance,
> Matt
>
> ----- Original Message -----
> From: "Gareth Boden" <[EMAIL PROTECTED]>
> To: "Turbine Torque Users List" <[EMAIL PROTECTED]>
> Sent: Wednesday, September 18, 2002 12:19 PM
> Subject: Re: Is torque dying?
>
>
> Some time ago we had a little discussion about XML generation from
> Torque Objects. I've written some code to do this, using
> commons-betwixt, now. The way it works is that you add
> serialization="xml" to your <table> definitions, and the resulting
> Objects contain a toXml() method, and also implement
> java.io.Externalizable (in XML form). Most of the code is on BaseObject
> rather than generated into the separate Base Objects. FK-relationships
> are retained and you can override the interesting bits by overriding a
> method defined in the Base Object which performs the equivalent function
> of the ".betwixt" file. I haven't yet done the XML->Torque direction. No
> extra files are generated (all the betwixt config is done in code).
>
> If anyone's interested I could make the diff available and give a bit
> more information.
>
> Gareth
>
> On Tuesday, July 9, 2002, at 11:58  am, Gareth Boden wrote:
>
>>
>> On Tuesday, July 9, 2002, at 11:34  am, Age Mooy wrote:
>>
>>>> Also, I don't want to have to write additional mappings for all the
>>>> classes and I want primitive data in elements not attributes, which
>>>> would mean using a tweaked Castor XML - there didn't seem to be any
>>>> mention of this being configurable.
>>>
>>> Try http://jakarta.apache.org/commons/betwixt/
>>
>> This looks interesting. I guess I could add something to Torque to
>> automatically generate appropriate .betwixt files (or Castor XML
>> mappings) when generating the OM. I'll look some more at this later.
>>
>>> JSR57 (from memory) dealt with XML serialization and the result was
>>> added to
>>> the java.beans package in jdk 1.4. See
>>> http://java.sun.com/j2se/1.4/docs/guide/beans/changes14.html for an
>>> explanation of the new features.
>>>
>>
>> It's nice they've put that XMLEncoder in there, but it's more
>> Java-oriented in syntax and less data-oriented (void statements,
>> classnames, etc.) Also don't want to force upgrading to 1.4 just yet.
>>
>> Gareth
>>
>>
>> --
>> To unsubscribe, e-mail:   <mailto:turbine-torque-user-
>> [EMAIL PROTECTED]>
>> For additional commands, e-mail: <mailto:turbine-torque-user-
>> [EMAIL PROTECTED]>
>>
>>
> ---
> Development Team Leader, eGS, 5-7 Singer Street, London EC2A 4BQ. +44
> (0)20 7336 1440
>
> CONFIDENTIALITY: This is email is confidential and intended solely for
> the use of the individual to whom it is addressed. Any views or
> opinions presented are solely those of the author and do not necessarily
> represent those of eGovernment Solutions (UK) Ltd. If you are not the
> intended recipient, be advised that you have received this email in
> error and that any use, dissemination, forwarding, or copying of this
> email is strictly prohibited. If you have received this email in error
> please contact the sender.
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:turbine-torque-user-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:turbine-torque-user-
> [EMAIL PROTECTED]>
>
>
---
Development Team Leader, eGS, 5-7 Singer Street, London EC2A 4BQ. +44 
(0)20 7336 1440

CONFIDENTIALITY: This is email is confidential and intended solely for 
the use of the individual to whom it is addressed.� Any views or 
opinions presented are solely those of the author and do not necessarily 
represent those of eGovernment Solutions (UK) Ltd.� If you are not the 
intended recipient, be advised that you have received this email in 
error and that any use, dissemination, forwarding, or copying of this 
email is strictly prohibited.� If you have received this email in error 
please contact the sender.

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to