https://issues.apache.org/bugzilla/show_bug.cgi?id=54849
--- Comment #7 from Tim Allison <[email protected]> --- (In reply to comment #4) > (In reply to comment #2) > > Created attachment 30203 [details] > > [PATCH] POI 54849 > > > > Proposed patch is attached. In the long run, it'd be great to build out the > > controlled content/form object (on par with XWPFParagraph and XWPFTable), > > but for now, this will at least read the text within one into the > > paragraphs, tables and bodyelements lists. > > > > Any recommendations? > > I think it might be best to add a very simple body element for the > controlled content, and have the inner paragraphs+tables made available from > that. That would seem to be the most future proof way to go, as we can then > add in future logic / information on the controlled content later, without > changing the behaviour. If we do a simple parsing now and pop the text into > the regular list, then when we come to add proper support we'd risk breaking > existing code by causing the location of the text objects to move in the > body hierarchy. Agree on future-proofing. I'm trying to think of the smallest changes possible as a first step. It looks like: New classes: XWPFControlledContent implements IBodyElement XWPFControlledContentBlock implements IBody Add entries to BodyType and ElementType Add to IBody interface: getControlledContents() getControlledContentArray() I think we'll need to make changes to all classes that implement IBody's getBodyElements(). For all classes that implement IBody, we'll need to add the new methods. Does this seem like a reasonable first step? Is there a simpler option? Is it ok if I leave stubs for dynamically adding controlled content (I propose "read only" from an existing docx for this patch). -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
