[
https://issues.apache.org/jira/browse/PDFBOX-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14316907#comment-14316907
]
John Hewson edited comment on PDFBOX-2580 at 2/11/15 8:22 PM:
--------------------------------------------------------------
Ok, well what are the main areas and what are we trying to address? Perhaps we
should open a new JIRA issue which specifies this clearly?
In 1.8 util became a dumping ground for unrelated functionality which was
usually tightly coupled to some other part of pdfbox, many of those classes now
reside elsewhere. As for PDFPrinter and PDFReader these classes don't belong in
PD because they don't represent part of a pdf file which can be manipulated,
instead they transcend the entire PD model, i.e. they depend on PD but are not
a part of it. They also have many of their own package-private helper classes
which should not be shared with PD (as PD should not depend on rendering).
Because rendering depends on PD but PD does not depend on rendering, keeping
them seperate gives us a clear separation of concerns and a well-formed package
structure without any cyclic dependencies.
What could possibly be done in the future is to move rendering and printing out
into their own module so that they are in a seperate jar, so that pdfbox core
would no longer depend on AWT - however that won't actually achieve anything
because PD (and thus core) has many dependencies on AWT beyond printing and
rendering i.e. PD is tightly coupled to AWT an that is the real problem and is
much more complex and difficult to solve.
was (Author: jahewson):
Ok, well what are the main areas and what are we trying to address? Perhaps we
should open a new JIRA issue which specifies this clearly?
In 1.8 util became a dumping ground for unrelated functionality which was
usually tightly coupled to some other part of pdfbox, many of those classes now
reside elsewhere. As for PDFPrinter and PDFReader these classes don't belong in
PD because they don't represent part of a pdf file which can be manipulated,
instead they transcend the entire PD model, i.e. they depend on PD but are not
a part of it. They also have many of their own package-private helper classes
which should not be shared with PD (as PD should not depend on rendering).
Because rendering depends on PD but PD does not depend on rendering, keeping
them seperate gives us a clear separation of concerns and a well-formed package
structure without any cyclic dependencies.
What could possibly be done in the future is to move rendering and printing out
into their own module so that they are in a seperate jar, so that PD would no
longer depend on AWT - however that won't actually achieve anything because PD
has many dependencies on AWT beyond printing and rendering i.e. PD is tightly
coupled to AWT an that is the real problem and is much more complex and
difficult to solve.
> Decouple implementation specific forms handling from interactive.form PD Model
> ------------------------------------------------------------------------------
>
> Key: PDFBOX-2580
> URL: https://issues.apache.org/jira/browse/PDFBOX-2580
> Project: PDFBox
> Issue Type: Improvement
> Components: AcroForm
> Reporter: Maruan Sahyoun
> Assignee: Maruan Sahyoun
> Fix For: 2.0.0
>
> Attachments: sonar.png
>
>
> The interactive.form PD model currently holds classes reflecting the various
> fields intermixed with appearance generation and layout handling.
> In order to separate the PD model from the service of forms filling and
> appearance generation this functionality shall be moved into a new package.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
