I have a legal application using government forms. These forms are fill in PDFs (FDF Data).
We have sets of data in JSON format stored in a database. I want to be able to take that data an insert it into the fill-in pdf. Coldfusion's cfpdfform seems to do that quite well. However Coldfusion appears to me to have some off-beat JSON formatting.
So, my request is simply, what is the best way to populate a pdf fill-in form with data in PHP or javascript?
In the alternative, our json data contains a number of objects and arrays within it. Is there any, non-tedious way of getting Coldfusion to understand its formatting without numerous cfloops within the datafile to get it into a struct?
Thanks so much.
I had a similar project spec last year. We had a 50-page legacy fillable pdf form that we wanted to bring up-to-date and integrate into a panel review workflow. I hit countless roadblocks, mostly due to end-user environments.
My ultimate solution was slightly out-of-the-box, but you may consider something similar:
I built the actual interactive form as a traditional HTML5\jQuery\CSS3 view that contained the form and methods for loading and saving form data to SQL. The business logic employed TCPDF (I think that's the lib I used - maybe FPDF of something like that) and an alternate stylesheet that re-renders the form data to classic, printable PDF.
I can't promise this is the best solution for your situation, but it nailed it for us.
You may take a look at our SetaPDF-FormFiller component (not free!). It allows you to fill in PDF forms in pure PHP.
You only need a kind of mapping logic from your json-objects to the PDF form field names. The filing process is that simple:
$writer = new SetaPDF_Core_Writer_Http('pdf-form-filled.pdf');
$document = SetaPDF_Core_Document::loadByFilename('pdf-form.pdf', $writer);
$formFiller = new SetaPDF_FormFiller($document);
$fields = $formFiller->getFields();
$fields['name']->setValue($jsonData->name);
$fields['gender']->setValue($jsonData->gender);
...
$document->save()->finish();
Related
I have a html form in a Smarty template. A select in the form is populated via AJAX. I would like to specify in the Smarty template, the format to be returned by the AJAX-call. This way I can use the same request-url for different purposes. For example if the select contains users, sometimes I might be interested in knowing the user's email address (format: "{$Option->GetName()} ({$Option->Email})"), and other times the user's organisation (format: "{$Option->GetName()} ({$Option->Organisation})").
I have a few ideas of how to achieve this:
Store the format in html/js in the template. Then the AJAX-call can send the desired return-format along with the request. Drawback: A malicious user can change the format in the request, which might be a security issue.
Pass along the entire $Option object, and do the formatting using JavaScript. Drawback: Cannot use the PHP object's methods, such as $Option->GetName().
Store the format in a separate template file, and reference to this file in html/js and send along with the AJAX request. Drawback: The reference to the template file can be changed by a malicious user, but probably no damage can be done. This approach requires extra template files, and the presentation logic will be spread over different files.
Create a Smarty plugin that automates the process of item 3. Then the presentation logic will not be separated. Drawback: The reference to the template file can be changed by a malicious user, but probably no damage can be done.
Do anyone have any other/better ideas, or any experience with doing something like this?
I don't think you need to set some format. You can create a javascript function with 3 parameters. The <select> tag identifier, the name of the key used for options value, and the key name used for options text. The function will make the ajax request. That way you can call the function with settings you need for particular situation.
Further details depend on your current code.
I ended up using option 4, and I'm very happy with the result.
If anyone come across this and need information on how I implemented it, just post a comment, and I'll try to explain.
I'm working on an internal tool using spring-mvc and thymeleaf.
A section of this tool is used to create an entity we save in the database.
This entity is quite complex; it contains many properties and relations. Some of these relations contain list and other properties.
I have 2 constraints:
Single page. No "wizard".
To only save a completed object in the database.
Now, I'm not really asking for a specific issue. I know my way around thymeleaf, spring #ModelAttribute, etc.
My question is mostly which strategy are you choosing or how to deal with really complex object creation.
Now I can see 3 ways to do it :
Rendering page with thymeleaf. Every time a new element need to be added to a list, I use Ajax to add the new element on the server and rerender the specific fragment. So doing back and forth to the server with my #ModelAttribute and only save at the end.
Rendering a basic page with thymeleaf. Using JavaScript to create html elements and instead of submitting to a #ModelAttribute, I'm serializing my form to JSON and submit this JSON to the server. (kind of client side model)
Rendering a basic page with thymeleaf. Create the html element dynamically with JavaScript when I need to add list item (being sure I'm putting proper name="" to fit with my Java form object) and submit the whole thing at the end.
I'm personally unsure between 1 or 2.
I feel dealing with complex object is much more easier using JSON than form submission. Also, the input value/field with sub object and property can be quite nasty. Having this kind of syntax
does not sound great to me...
3 can probably work but the way spring data binding is done with sub property is lacking some detail in my humble opinion (section 7.4.1 - http://docs.spring.io/spring/docs/current/spring-framework-reference/html/validation.html).
What do you think ?
Personally I use Thymeleaf's own dynamic field management to ensure clean addition of objects and fields to object.
So I will recommend option 4: Dynamic Field management by Thymeleaf.
Have a read of http://www.thymeleaf.org/doc/tutorials/2.1/thymeleafspring.html#dynamic-fields.
I use that for both single field additions as well as addition of nested forms. Does the trick no questions asked.
Hope that helps.
I have a database and I have a website front end. I have a field in my front end that is text now but I want it to support markdown. I am trying to figure out the right was to store in my database because I have various views that needs to be supported (PDF reports, web pages, excel files, etc)?
My concern is that since some of those views don't support HTML, I don't just want to have an HTML version of this field.
Should I store 2 copies (one text only and one HTML?), or should I store HTML and on the fly try to remove them HTML tags when I am rendering out to Excel for example?
I need to figure out correct format (or formats) to store in the database to be able to render both:
HTML, and
Regular text (with no markdown or HTML syntax)
Any suggestions would be appreciated as I don't want to go down the wrong path. My point is that I don't want to show any HTML tags or markdown syntax in my Excel output.
Decide like this:
Store the original data (text with markdown).
Generate the derived data (HTML and plaintext) on the fly.
Measure the performance:
If it's acceptable, you're done, woohoo!
If not, cache the derived data.
Caching can be done in many ways... you can generate the derived data immediately, and store it in the database, or you can initially store NULLs and do the generation lazily (when and if it's needed). You can even cache it outside the database.
But whatever you do, make sure the cache is never "stale" - i.e. when the original data changes, the derived data in the cache must be re-generated or at least marked as "dirty" somehow. One way to do that is via triggers.
You need to store your data in a canonical format. That is, in one true format within your database. It sounds like this format should be a text column that contains markdown. That answers the database-design part of your question.
Then, depending on what format you need to export, you should take the canonical format and convert it to the required output format. This might be just outputting the markdown text, or running it through some sort of parser to remove the markdown or convert it to HTML.
Most everyone seems to be saying to just store the data as HTML in the database and then process it to turn it into plain text. In my opinion there are some downsides to that:
You will likely need application code to strip the HTML and extract the plain text. Imagine if you did this in SQL Server. What if you want to write a stored procedure/query that has the plain text version? How do you extract plain text in SQL? It's possible with a function, but it's a lot of work.
Processing the HTML blob can be slow. I would imagine for small HTML blobs it will be very fast, but there is certainly more overhead than just reading a plain text field.
HTML parsers don't always work well/they can be complex. The idea is that your users can be very creative and insert blobs that won't work well with your parser. I know from experience that it's not always trivial to extract plain text from HTML well.
I would propose what most email providers do:
Store a rich text/HTML version and a plain text version. Two fields in the database.
As is the use case with email providers, the users might want those two fields to have different content.
You can write a UI function that lets the user enter in HTML and then transforms it via the application into a plain text version. This gives the user a nice starting point and they can massage/edit the plain text version before saving to the database.
Always store the source, in your case it is markdown.
Also store the formats that are frequently used.
Use on demand conversion/rendering for less frequent used formats.
Explanation:
Always have the source. You may need it for various purpose, e.g. the same input can be edited, audit trail, debugging etc etc.
No overhead for processor/ram if the same format is frequently requested, you are trading it with the disk storage which is cheap comparing to the formars.
Occasional overhead, see the #2
I would suggest to store it in the HTML format, since is the richest one in this case, and remove the tags when obtaining the data for other formats (such PDF, Latex or whatever). In the following question you'll find a way to remove tags easily.
Regular expression to remove HTML tags
From my point of view, storing data (original and downgraded) in two separate fields is a waste of space, but also an integrity problem, since one of the fields could be -in theory- modified without changing the second one.
Good luck!
I think that what I'd do - if storage is not an issue - would be store the canonical version, but automatically generate from it, in persisted, computed fields, whatever other versions one might need. You want the fields to be persisted because it's pointless doing the conversion every time you need the data. And you want them to be computed because you don't want them to get out of synch with the canonical version.
In essence this is using the database as a cache for the other versions, but a cache that guarantees you data integrity.
I'm trying to make pull XML or Csv data into a HTML file then I want to use math to add up the values and show the result on the page ( I'm basically trying to display invoices on a web browser)
My skill set is HTML/CSS and I understand a little JavaScript
I've managed to pull XML data into HTML using http request and style that information using xslt
Really what I'm asking is what is the best solution to my needs is it using the above method then using xquiry to add up values or would I need to learn a bit of Ajax, Json and calculate the values with JavaScript?
You really should learn AJAX in order to fetch and manipulate data instead of fetching presentation parts. That's the way everyone follows as it allows more responsive interactions with the user and a cleaner architecture in case of complex interactions.
But that doesn't mean you must abandon XML : originally AJAX was built on XML (the X in AJAX) and not JSON.
Personally I prefer JSON, and I think it will be easier to manage in the long term, but if the server side is hard to change, you can fetch the XML (look for example at jquery's ajax function), build javascript objects using it, and then change your screen using those data. If later you decide to use JSON instead of XML, you'll just have to change the "parsing" part of the client code.
"I'm trying to make pull XML or Csv data into a HTML file then I want to use math to add up the values and show the result on the page"
You can do this with either XSLT or javascript. However, with XSLT things can become pretty complicated, depending on what version you're using. XSLT 1.0 has pretty limited set of functions for aggregating results. For all XSLT, you can't reassign variables you'll have to solve many of these things with recursion. In my opinion, not really a comfortable method.
Regardless of the choice between XSLT and Javascript, I would also question the architecture that would put this kind of logic in the presentation layer in the browser. I think it would be better if the server side would perform all the calculations that are required, and limit the browser's tasks to styling the output.
I'm basically looking for the client-side equivalent of Django's ModelForm: I want to be able to specify the general schema of my data (what the fields are, which ones are required, what kinds of fields to use, etc.), and I want to be able to dynamically generate the form, itself, fill it with any initial data, validate it, and extract an object containing the validated data that I can Ajaxily submit places when the form has been filled out.
Dos this exist? Something jQuery-flavored would be preferred.
You might also check out Alpaca (http://www.alpacajs.org). It's similar in some ways to Joshfire's JSON Form library. It uses JSON Schema and features a JSON-based way of specifying your layout and additional rendering options. It also uses templates for flexibility.
You can register your own controls for different data types. It comes with a whole bunch of controls already defined for things like simple text entry all the way to Google Maps and more.
Best of all, it's open-source and based on jQuery. It's been around for the better part of two years and we've been using it with Cloud CMS at my company. (disclaimer: I'm biased + I haven't tried any of the other tools suggested, they're likely awesome as well)
http://neyric.github.com/inputex/examples/json-schema.html
This is very likely what you want. Give YUI a whirl ;)
May I also humbly suggest Metawidget? It supports a broad range of back-end definitions and UI frameworks.
Joshfire's JSON Form library does just that.
It uses the IETF standard JSON Schema format to describe your models, and it can validate your data against it using JSV.
It lets you specify the form layout, but it generates a default form if you don't.
It's based on JQuery.