[patch] Interface for CustomXmlElements

[Richard]

Hi,

I have not written the mentioned patch yet, but today I noticed that it would be very useful to have an CustomXmlElement interface as well (http://dev.plutext.org/forums/viewtopic.php?f=6&t=617). I will try to do it exactly like the SdtElement Interface without the errors I made at this one.

As soon as I'm home I will start implementing it. Hopefully we can apply it soon...

Richard

@Jason: If you are quick enough you could give me some further thoughts on this, otherwise feel free to optimize my solution.

[Richard]

I have started to write the patch and noticed that the basis for CTCustomXml* is slightly different form Sdt*. While every Sdt class has its own SdtContent class an equivalent for CTCustomXml is missing. This looks inconsistent to me and I think it should be developed equal. So we can either add content classes for every CustomXml type or remove the sdtContent classes?!

I think it would be very hard for me to add those content classes for CTCustomXmlBlock, CTCustomXmlCell, CTCustomXmlRow and CTCustomXmlRun because I have never dealt with those XML annotations.

What do you think about it Jason?

[jason]

There are three things I may do to understand a new bit of content (eg custom xml).

One is create sample XML using Word. In this case, those classes look like they represent CustomXML surrounding a paragraph, a table cell, a table row, and a run, respectively. I'll often run the resulting docx through OpenMainDocumentAndTraverse or PartsList, to see what objects docx4j makes of it.

Two is look at the spec. You can either open the whole document in Word or as a PDF, or using the search tab above, search the documentinterop site (which is what i usually do - unless there's many pages i want to read).

Three is look at wml.xsd.

In this case, looking at wml.xsd: CT_CustomXmlRun contains EG_PContent; the Block contains EG_ContentBlockContent; the row contains EG_ContentRowContent and the cell contains EG_ContentCellContent. (Unless something is wrong, these will be represented in the JAXB objects - I haven't checked).

So each of them do have a content class; the same approach that we have taken for sdt's should work here.

hope this helps .. Jason

[Richard]

I think I understand what you mean. Those four classes are all generated from the wml.xsd and as a result are equal to the wml specification. I absolutely do not want to touch those areas of the framework.
I know what some of those elements represent, eg CTCustomXmlRun is a customXml element in a paragraph...

So far I will keep the patch as it is and wait what you think about it.

One more thing: In my opinion both the SdtElement and the new CTCustomXmlElement class need to extend the Child class, because in the way it is implemented now I can not access the parent from the interface:

Syntax: [ Download ] [ Hide ]

Syntax: [ Download ] [ Show ]

Using java Syntax Highlighting

SdtElement e = new SdtBlock();
e.getParent(); // not possible
Child c = e; // not possible, so c.getParent() does not work without a cast
 

Parsed in 0.014 seconds, using GeSHi 1.0.8.4

Am I right, that we have to change it like this:

Syntax: [ Download ] [ Hide ]

Syntax: [ Download ] [ Show ]

Using java Syntax Highlighting

public interface SdtElement extends Child { ... }
public class SdtBlock implements SdtElement { ... }
 

Parsed in 0.013 seconds, using GeSHi 1.0.8.4

Richard

[Richard]

Here is my new patch. It includes:

• update for the SdtElement interface, which now extends child
• update for SdtBlock, SdtRun, SdtRow, SdtCell, which now only extend SdtElement
• new CTCustomXmlElement interface, which is implemented by CTCustomXmlRun, CTCustomXmlBlock, CTCustomXmlCell, CTCustomXmlRow
• fix for CTCustomXmlRun, CTCustomXmlBlock, CTCustomXmlCell, CTCustomXmlRow returning null properties
• method added in CTAttr to find attribut by name

I've read the terms & conditions about providing a patch and accept them.

Richard

P.S.: I know the patch contains more than the interface mentioned in the thread title, but I find it stupid to provide three small patches with only one change.

[jason]

Hi Richard

Thanks for this; applied as http://dev.plutext.org/trac/docx4j/changeset/1437

I them made some minor modifications as http://dev.plutext.org/trac/docx4j/changeset/1438

In CTCustomXmlCell you had changed the name of an existing method, which we need to avoid where possible.

cheers .. Jason

[Richard]

Thanks.

Of course we need to keep those existing functions. I renamed this method accidently and missed to redo it properly.