I have a general design / object question that I'd love to get some different opinions about. BTW, this is a Windows / VCL app in case it matters.
I have a general design / object question that I'd love to get some different opinions about. BTW, this is a Windows / VCL app in case it matters.
I started this project off off with a bunch of related PDF form files that I need to stuff into something to manage them. So far a zip file looks to be the best container. These are form files, and I need to identify all of the fields on the forms and list them out along with some info regarding where the data comes from (some from DB fields, some from the user, some required, some with defaults, etc.). I've got a library to do deal with the PDF stuff; that's not an issue.
But I do need to keep some metadata on all of the fields in each form, and I thought an easy way to do that is to put it into an INI file. Easy peasy.
However, the more I'm thinking about it, I don't like having a separate PDF and INI. I also don't want to stuff the INI into the PDF (as an attachment). But I can stuff the PDF file into the INI file. (I'm using BigIni.pas, which is a library I came across ages ago that I've used to deal with INI files, and it includes the ability to read/write binary data to/from a stream.)
I started thinking about defining a class to wrap the INI file and give easier access to all of the data I'll be keeping in it, then it occurred to me that maybe I can set something up to treat the INI file as the persistent form of this class.
Then I started thinking about how to make a class like this persistent in general. The big question I've got is, how can I persist (load/save) a humonguous data "field" like a PDF form? The largest form file we've got so far is about 2.2 MB.
So at this point, I'm curious ... if I've got a class with instances that have some lists of field objects (between 10 and 150 or so, depending on the form), as well as a data element that contains an entire PDF file (30k .. 2+ MB), and an assortment of other more typical object properties, what's the best way to make it persistent? (That is, I want to be able to load and save instances of this class from/to the zip archive as streams, then access the data in each instance just as a normal class.)
These class instances never need to ever exist as a "file"; they can live entirely within a stream if that matters, because it's going to actually live inside of another container like a zip archive with a half-dozen or so other similar objects.
Thoughts?
I started this project off off with a bunch of related PDF form files that I need to stuff into something to manage them. So far a zip file looks to be the best container. These are form files, and I need to identify all of the fields on the forms and list them out along with some info regarding where the data comes from (some from DB fields, some from the user, some required, some with defaults, etc.). I've got a library to do deal with the PDF stuff; that's not an issue.
But I do need to keep some metadata on all of the fields in each form, and I thought an easy way to do that is to put it into an INI file. Easy peasy.
However, the more I'm thinking about it, I don't like having a separate PDF and INI. I also don't want to stuff the INI into the PDF (as an attachment). But I can stuff the PDF file into the INI file. (I'm using BigIni.pas, which is a library I came across ages ago that I've used to deal with INI files, and it includes the ability to read/write binary data to/from a stream.)
I started thinking about defining a class to wrap the INI file and give easier access to all of the data I'll be keeping in it, then it occurred to me that maybe I can set something up to treat the INI file as the persistent form of this class.
Then I started thinking about how to make a class like this persistent in general. The big question I've got is, how can I persist (load/save) a humonguous data "field" like a PDF form? The largest form file we've got so far is about 2.2 MB.
So at this point, I'm curious ... if I've got a class with instances that have some lists of field objects (between 10 and 150 or so, depending on the form), as well as a data element that contains an entire PDF file (30k .. 2+ MB), and an assortment of other more typical object properties, what's the best way to make it persistent? (That is, I want to be able to load and save instances of this class from/to the zip archive as streams, then access the data in each instance just as a normal class.)
These class instances never need to ever exist as a "file"; they can live entirely within a stream if that matters, because it's going to actually live inside of another container like a zip archive with a half-dozen or so other similar objects.
Thoughts?
I'm trying to understand this and build a picture of the end-user's interactions with your application and what you want to accomplish for the end-user. So here are some questions I have:
ReplyDelete1. Do you want to allow the end-user to fill these PDF forms and then save the form field values somewhere?
2. The metadata is needed to know from where to read (initial values) and where to write the filled form field values because you are dealing with lot of forms and/or the source/destination for the form field values is dynamic and possibly editable by the end-user? Also, maybe that you need to keep adding new forms and set them up for the filling process. Is that mainly what the metadata is for? In which case your program does the pre-filling and saving of the form field values based on the metadata? Is there any other purpose for the metadata?
Girish Patil The idea is that there are a half-dozen PDF forms that are required for something to be filed. Not always are all of them needed, but some. Currently they're being either filled-in via Adobe Acrobat Reader and printed then signed and sent; or printed first, filled-out, signed and sent.
ReplyDeleteThe nature of the activity is such that anywhere from 10% to 50% or more of the data that needs to be entered into the forms is already available in this application customers use.
So one of the customers asked if it's possible to augment the software so it can make it easier to pick forms and then fill-in (aka, "pre-populate") the necessary forms with data pulled from the database.
I realized yesterday that we don't even really need to save the forms, just the data. That's because as long as the program can get access to the forms, it can open them up and fill all of the fields from data that has been captured both from the DB and the user. Some of these forms are pretty large, so the use of JSON or INI files to contain the field values is a far more efficient way of storing the data.
Actually, it leans towards an interesting application approach: design data collection forms in Adobe Acrobat, let the users enter data into them, then save the data separately from the forms. It's not that much different than how Delphi works, only with a very different UI approach.
It appears we are thinking on the same lines and it is also the area we are currently working on at Gnostice. More and more people are requesting for these features and we are certainly interested in more scenarios. I covered this topic in one of the Embarcadero Partner Spotlight presentations. Please have a look at this video: youtube.com - Embarcadero Technology Partner Spotlight - Gnostice Information Technologies
ReplyDeleteWe are enhancing this further now.