Return-Path: 
 <dev-return-108826-apmail-commons-dev-archive=commons.apache.org@commons.apache.org>
Delivered-To: apmail-commons-dev-archive@www.apache.org
Received: (qmail 79691 invoked from network); 24 Apr 2008 13:01:56 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 24 Apr 2008 13:01:56 -0000
Received: (qmail 50274 invoked by uid 500); 24 Apr 2008 13:01:56 -0000
Delivered-To: apmail-commons-dev-archive@commons.apache.org
Received: (qmail 50189 invoked by uid 500); 24 Apr 2008 13:01:56 -0000
Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@commons.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@commons.apache.org>
List-Post: <mailto:dev@commons.apache.org>
List-Id: <dev.commons.apache.org>
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Delivered-To: mailing list dev@commons.apache.org
Received: (qmail 50178 invoked by uid 99); 24 Apr 2008 13:01:56 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Apr 2008 06:01:56 -0700
X-ASF-Spam-Status: No, hits=1.2 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [194.152.182.1] (HELO mgate.ops.co.at) (194.152.182.1)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Apr 2008 13:01:12 +0000
Received: from smtp.ops.co.at (smtp.int.ops.co.at [172.27.0.4])
	by mgate.ops.co.at (OPS Mail Gateway - authorized use only - NO UCE/UBE C=AT
 L=VIE) with ESMTP id 4F15BAFE4E
	for <dev@commons.apache.org>; Thu, 24 Apr 2008 15:01:21 +0200 (CEST)
Received: by smtp.ops.co.at (Postfix, from userid 65534)
	id 890476E023F; Thu, 24 Apr 2008 15:01:19 +0200 (CEST)
Received: from [172.27.1.104] (lints2.int.ops.co.at [172.27.1.104])
	by smtp.ops.co.at (Postfix) with ESMTP id 1C4436E0234
	for <dev@commons.apache.org>; Thu, 24 Apr 2008 15:01:17 +0200 (CEST)
Message-ID: <4810849B.8070406@chello.at>
Date: Thu, 24 Apr 2008 15:01:15 +0200
From: "simon.kitching@chello.at" <simon.kitching@chello.at>
User-Agent: Thunderbird 2.0.0.0 (X11/20070418)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: How to create a Java object if the xml element is in wrong place?
References: <16850225.post@talk.nabble.com>
In-Reply-To: <16850225.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on smtp.ops.co.at
X-Spam-Level: 
X-Virus-Checked: Checked by ClamAV on apache.org
X-Old-Spam-Status: No,
 hits=-2.6 required=7.0 tests=AWL,BAYES_00,J_CHICKENPOX_47,
	J_CHICKENPOX_64,J_CHICKENPOX_74,LOCAL_SPAMWORDS,RATWR10_MESSID,
	SPG_MG_BUY autolearn=no version=2.64

Hi Robert,

Robert Lee schrieb:
> I am parsing an xml file to the digester xml rules to create objects.
> The xml file we've got does not confront to the java model correctly. The
> address and contact elements are under the person. The correct format would
> have been the address element to be inside the contact.
> Unfortunately I can not change the format of the xml but I have to find a
> way using xmlrule to overcome this problem.
> The format of the xml file is:
> <root>
>             <person>
>                         <address line1="29  Glen Street" line2="Tamara"
> postcode="XYZ123"></address>
>                         <contact telephoneno="0123456789"
> emailaddress="glen@street.com"></contact>     
>             </person>
> </root>
>
> The Java has been defined as:
> Person.java
> -----------------
> Contact contact;
> public void setContact(Contact contact) { this.contact = contact; }
> public Contact getContact() { return contact; }
>
> Contact.java
> -----------------
> Address address
> public void setAddress(Address address) { this.address = address; }
> public Address getAddress() { return address; }
>
> Address.java
> -----------------
> private String line1;
> private String line2;
> private String postcode;
> setters/getters for line1,line2 and postcode;
>
> my xml rule is:
> <pattern value="root/person">
>             <object-create-rule classname="com.xyz.Person" />
>             <set-properties-rule />
>             <set-next-rule methodname="setContact" />
> </pattern>
> <pattern value="root/person/contact">
>             <object-create-rule classname="com.xyz.Contact" />
>             <set-properties-rule />
>             <set-next-rule methodname="setAddress" />
> </pattern>
> <pattern value="root/person/address">
>            <!-- How to write my rule here -->
>             <object-create-rule classname="com.xyz.Address" />
>             <set-properties-rule />
>             <set-next-rule methodname="setAddress" />
> </pattern>
>
> If I add setAddress in Person.java then it works fine but setAddress is only
> defined in Contact.java
> How can I write my address rule so that it work?
>   

Does your input xml really have "address" elements *before* contact
elements? If so, that will be hard to handle; the data needs to be added
to a contact object that does not yet exist!

If this is just a typing error, or you can change the xml so the contact
object that is the parent of the address occurs *before* the address
then this would be easier. In this case, I would use a custom Rule class
that triggers on "root/person/address", which just fetches the needed
attributes and then calls Person.getContact to find the contact object
to add the address info to.

If the xml is really as you describe, then you will need to store the
address info somewhere until the Contact object gets created (and
somehow deal with the situation where a Person has <address> elements,
but no <contact> element. Again, it's probably easiest to just write a
custom Rule class to handle "root/person/address", which stores this
data using Digester.push(stackname, data). Then you would need another
custom rule in order to copy the data you saved earlier into the
relevant Contact object, mapped to fire on "root/person/contact" or
"root/person" (or both).

Don't be concerned about writing custom Rule classes; it is quite easy
and there is absolutely nothing wrong with doing that. The Rule classes
provided with digester are just a useful starting set, and don't cover
every case.

Regards,
Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org