Hi James,
> So a NodeComparator might be useful in the org.dom4j.util package. I'll
> add
> it to the to do list...
Fine. Comparing canonical xml documents might be usefull when you write a
small native xml-database. At this point you have to decide if a lightweight
object model is the right design choice. There are a few points that argues for
dom4j, because its powerfull, simple and well desinged. Another reason for
using canonical docs are xml signatures, but we will see if that affects
dom4j.... It's have upper prio. A Comparator would be nice in the meantime.
>
>
> > Just another question: What did you think about Java Generics?
>
> I like the look of it. I've wanted Generics for some time in Java though
> I've come to realise they are much less important than I once thought. In
> C++ it seems that generics (templates) are essential - in Smalltalk or
> Java
> its much less so.
Agreed, but Generics or Templates are better than C# Boxing. Buah. Remebers
me at VB's Variant Type..... Stroustrup points out that Generic Types
increase typesafty, but it is acutually a minor charateristic of an OO-Language as
Smalltalk and Java shown in past.
> I agree there are potential savings, reducing casts. Though for a few
> years
> now JVMs have been really fast at doing casts. I think Generics is more of
> a
> compile time 'feel good factor', allowing you to avoid casts that
> technically could fail at runtime and make your code a little simpler. I'm
> not sure how much performance is increased. For example, last time I
> looked
> the Generics implementation would often still do the casts under the
> covers
> anyway.
> Its certainly something that could be used optionally for those that want
> type safety.
Ok, But as a already mentioned above it is only a minor chracteristic.
Althoug it would provide clearer colde.
((Element)root.getElements().get(2)).getText();
is no so easy to read...
> Deriving a new DocumentFactory allows you to have more fine grained
> control
> over the flyweight policy. For example, the SchemaDocumentFactory (in
> org.dom4j.schema package) implements XML Schema Data Types by associating
> different DocumentFactory implementations with different QName instances
> in
> a schema.
Pretty cool. I will try out it as I download beta 0.4. As I have to process
a schema file it would be nice chance to see it in action :-).
You spend a lot of time to improve dom4j. That's honorable. Tell me if I can
help you.
Happy coding (Not in the sence of COBOL...)
Regards
Toby
--
Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
_______________________________________________
dom4j-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-user
