[
https://issues.apache.org/jira/browse/PDFBOX-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14544117#comment-14544117
]
John Hewson edited comment on PDFBOX-2459 at 5/14/15 6:01 PM:
--------------------------------------------------------------
I followed the "best course of action" as mentioned above, so that
PDFieldTreeNode is now finally in line with the PDF spec. This changes
PDFieldTreeNode to PDField and PDField to PDTerminalField and increases type
safety by distinguishing between terminal and non-terminal fields in
appropriate contexts. I've also tightened up the contact around constructor
parameters, keeping them in final fields and preventing invalid manipulations.
I found several cases where constructors for _reading_ fields were being called
to create new fields, so I made the read-only constructors package private to
prevent this. Write/new field constructors remain available for each terminal
field class itself.
We still need some methods for fetching the entire field tree and manipulating
it. While writing the above code I discovered that most calls to #getFields()
in PDFBox are wrong, more often than not the caller has assumed that
getFields() returns all terminal fields in the hierarchy, however it does not,
it returns only the root fields of the hierarchy and it's the caller's
responsibility to walk that to find all fields. This is something which we
should address, because clearly even PDFBox's own committers can't use the
current API. I marked the bugs which I found with "fixme" comments, there are
several of these which you can see in the commit diff.
was (Author: jahewson):
I followed the "best course of action" as mentioned above, so that
PDFieldTreeNode is now finally in line with the PDF spec. This changes
PDFieldTreeNode to PDField and PDField to PDTerminalField and increases type
safety by distinguishing between terminal and non-terminal fields in
appropriate contexts. I've also tightened up the contact around constructor
parameters, keeping them in final fields and preventing invalid manipulations.
I found several cases where constructors for _reading_ fields were being called
to create new fields, so I made the read-only constructors package private to
prevent this. Write/new field constructors remain available for each terminal
field class itself.
We still need some methods for fetching the entire field tree and manipulating
it. While writing the above code I discovered that most calls to #getFields()
in PDFBox are wrong, more often than not the caller has assumed that
getFields() returns all terminal fields in the hierarchy, however it does not,
it returns only the root fields of the hierarchy and it's the caller's
responsibility to walk that to find all fields. This is something which we
should address, because clearly even PDFBox's own committers can't use the
current API.
> Share functionality between Page Tree and Field Tree
> ----------------------------------------------------
>
> Key: PDFBOX-2459
> URL: https://issues.apache.org/jira/browse/PDFBOX-2459
> Project: PDFBox
> Issue Type: Improvement
> Components: PDModel
> Affects Versions: 2.0.0
> Reporter: Maruan Sahyoun
> Assignee: John Hewson
> Priority: Minor
> Fix For: 2.0.0
>
>
> The PDFs page tree and AcroForms field tree share some common functionality
> e.g. resolving inheritable attributes, iterating through leafs and such which
> could be combined into a PDTree class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
