Add pdf generation capabilities to the pdfbox module#17
Add pdf generation capabilities to the pdfbox module#17gayaldassanayake wants to merge 5 commits into
Conversation
gayaldassanayake
requested review from
ThisaruGuruge and
shafreenAnfar
as code owners
| # The class that coresponds to org.apache.pdfbox.pdmodel.PDDocument. | ||
| # This is the in-memory representation of a PDF document. | ||
| public distinct class PDDocument { | ||
| private handle jObj; |
There was a problem hiding this comment.
Instead of maintaining a variable for handle instance, we can store the object as a native data from the java side
There was a problem hiding this comment.
Here, the PDDocument corresponds to the org.apache.pdfbox.pdmodel.PDDocument class coming from the apache pdfbox library. Therefore, to avoid having a handle here and to move it to Java side, we need to create a java wrapper for each pdfbox class.
Furthermore, if the purpose of not having a handle instance in the Ballerina PDDocument class is to avoid letting user pass a handle to the init method, in this case, I am accepting only ballerina types in the init method. Hence, this will not be an issue.
WDYT?
There was a problem hiding this comment.
@gayaldassanayake convention is to write a java-wrapper whenever we need to access Java objects/clients to perform a particular actions. And we usually hide the relevant Java object/client instance as the native data. IMO adding fields with non-ballerina types (like handle) inside Ballerina classes is an anti-pattern.
ayeshLK
left a comment
ayeshLK
left a comment
There was a problem hiding this comment.
Lets remove the handle usage from the Ballerina classes and hide the Java objects/clients inside native data.
I am working on this in my free time. Since there are a lot of functions to change, might take some time. For the time being, will convert this to a draft. |
3 participants
Purpose
Fixes ballerina-platform/ballerina-library#7917
Examples
Checklist