Thanks for your suggestion :)
May we'll try this method if my problem really can't be resolved by mapping
file.
Question below is a little different from the original one.
Class:
============================
public class Bar {
public String name;
public ArrayList value;
public String getName(){
return name;
}
public void setName(String a){
name = a;
}
public ArrayList getValue(){
return value;
}
public void setValue(ArrayList a){
value = a;
}
}
public class Foo {
private Bar bar;
public Foo();
public getBar() {
return bar;
}
public void setBar(Bar bar) {
this.bar = bar;
}
}
===============================
mapping file:
<mapping>
<class name="Foo">
<map-to xml="Foo"/>
<field name="bar.name" type="string">
<bind-xml name="name" location="name" node="attribute"/>
</field>
<field name="bar.value" collection="arraylist" type="string">
<bind-xml name="value" location="value" node="attribute"/>
</field>
</class>
</mapping>
The input xml is:
<Foo>
<name name="aaa"/>
<value value="bbb"/>
<value value="ccc"/>
</Foo>
But the output file is:
<Foo>
<name name="aaa"/>
<value value="bbb ccc"/>
</Foo>
They are not exactly the same and we think this is not acceptable
Do you think this problem can be resolved?
Many thanks for your help
ZS
-----Original Message-----
From: Gregory Block [mailto:[EMAIL PROTECTED]
Sent: 2005年8月3日 星期三 16:30
To: [email protected]
Subject: Re: [castor-user] question about castor
On 2 Aug 2005, at 13:19, Shuai Zhang wrote:
> Thank you for your solution, it does work :)
> The purpose that I use such an ugly format is because the original
> xml is generated line by line manfully and are not well formatted.
In that case, an XSLT running ahead of the XML is a good way of
allowing yourself a set of "cleanup rules", if you chose to do so, to
clean up the incoming XML into a more normalised form; if you're
really gung-ho about making the manual->automatic process
bulletproof, consider:
Original XML Source -> JTidy to clean up broken/stupid tags -> XSL to
catch missing content and common usage issues -> Castor.
We're not yet doing this, but we're looking at doing this now for
some of our content; we're also looking at using jtidy on-the-fly at
castor load time from the DB.
On a similar vein: We like to ensure that, in the database, content
is never entity-encoded; we always want to store the proper UTF8/
UTF16 representation; however, when the content is used, we always
want to ensure that we use the entity-encoded representation. As
we're using manually created value objects, we use a nio translator
to translate the content being set on the object into UTF characters,
and on write, we normalise all hand-written entity tags into our
preferred format.
While this could all be done with FieldHandlers, I'm sure (actually,
can it? I suppose it could in XML, but will it also do so on the JDO
side?) we prefer to do it on the objects so that clients don't need
to round-trip to the database to see the correct encoding in live
previews.
Cleaning up data at load time, or ensuring that representations in
the database match, or do not match, the representations of the data
during use, are useful tools that can help you ensure that content is
stored in a normalised, predictable manner.
Running a JTidy to catch bad XML formatting, then doing an XSL to
catch (and fix) structural errors can allow you to build a simpler
mapped-representation of the content, while still getting good
performance through the system, and allow you to handle content with
a variety of errors, but from which the content is perfectly
recoverable.
Such a system, in reverse, can even update the content in a fixed
form for the next time such changes get made, ensuring a cleaner
content cycle.
Anyways, happy to see my advice was useful, and I wish you lots of
luck. :)
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
