I'm trying to create a Rails app where our organization's users can create forms and then let our customers answer them in our website.
In short the requirements are:
Drag-and-drop form creation interface;
Conditional redirection (ex: if customer answers yes to a certain question, redirect to form x, else redirect to form y);
Client and server-side validation of fields, established by the users, whenever possible;
Associate answers with a "customer" entity (also notice the fields in these answers aren't pre-established in the model/DB);
Customization is a plus (ex: custom classes for the fields), users are tech-savvy.
So far I've been using https://github.com/kevinchappell/formBuilder to provide the actual form-building, but I've been having some problems with encoding (our forms have a lot of á, ã, à and such) and it generates an XML, which sometimes doesn't play nice when I try to render the form later; maybe if I could serialize/de-serialize it the later (or both, who knows) wouldn't be a problem anymore.
I'm also using MongoDB to store the answers and manually setting the redirections based on the answers (not cool).
So, is there a Rails/JS/dunno framework with which I could streamline all these actions (or at least some of them)?
Thanks.
The encoding issue should be solved in v1.15.0 of formBuilder https://github.com/kevinchappell/formBuilder/pull/211. I also wrote another plug-in called Formeo http://draggable.github.io/formeo/ that uses JSON and handles special characters pretty well.
Unfortunately I don't know of any package that handles the full front and back of a form building app other than the one I'm building, but it's not ready yet.
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();
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'd like to replace a parts requisition process at my workplace with a simple (and cheap to implement) electronic process, initiated using a Google Form. The problem is that I would like users to be able to enter multiple parts (along with associated info, e.g. quantities required, booking references etc.), but I want to do so without having to have multiple repeated questions.
I have researched this extensively and cannot find anything which fits the bill - my thoughts are to use Google Apps Script to create a table in the form which a user can fill-in. The closest I have found is something like this: Creating Form Elements Dynamically
The original paper form looks like the below - I would like the table to request the information as shown below in a similar format:
Thanks in advance!
EDIT! To make it clear, I'm happy to consider other solutions to run this process through an online interface - I have gone for Google Sheets/Forms in the first instance as they are already well integrated within my company and I have experience of them (setting-up triggers etc is pretty simple)
I understand the OP has probably long moved on from this problem. I however have done something along these lines in the past and thought I'd share my approach with the community.
I'll start with the premise Google forms are just good ol' plain HTML forms that users programmatically generate with their form builder. Therefore it's possible to traverse the as-built form and extract both submit location and all field names:
document.querySelectorAll('form').forEach((x) => {console.log(x.action)})```
document.querySelectorAll('[name^="entry."]').forEach((x) => {console.log(x.name + '=' + x.closest('[role="listitem"]').querySelector('[role="heading"]').innerText)})
The above snippet will give you an idea of what the components are.
All that's left after is to build a front end to your requirements with the framework of your choice (I used AngularJs at the peak of its popularity) and incorporate as much or as little UI and validations into it as you desire.
Here you've got the flexibility to either submit the whole thing as one JSON, or to parse it into individual fields and submit entries one by one, for purposes of this demo I opted for the easiest way but this thing surely's got the potential.
What is the most effective way to pass object and category ids or other system variables which shouldn't be presented to the user, from server to the browser?
Let's say I have a list of items where I can do something with each of them by javascript, for example show tooltip html or add to favorites by ajax, or display on a map. Where is it best to save that tooltip html, or database id, or geoposition?
Some options I can think of are:
some dictionary within <script></script> tag for each item,
microformats,
inline xml,
rel attributes,
css class names with specific information, e.g. class="lat-12345 uid-45678",
one <script></script> with a dictionary of html ids mapping dictionaries with system values in the template,
javascript generated from the database and included via <script src="..."></script> with a dictionary of html ids mapping dictionaries with system values in the template,
ajax requests for all cases when I need more information than just id,
event handlers with parameters within html tags, e.g. onmouseover="tooltip(this, 123, 'Hello world!')".
P.S. I prefer unobtrusive solutions and also the loading/execution time is important.
Perhaps I am missing something... why not just JSON?
How you "send" it (either in the initial page load as "javascript" or via AJAX or whatnot) is really just a trivial detail determined mostly by when the data is available. (JSON is a subset of legal JavaScript syntax.)
Then it's just a matter of the correct transformation. Of course, by pushing this to JSON/JS, you may render some non-JS clients non-interoperable, if that's a consideration for you. If such is indeed the case, why not just perform the transformation server-side using well, any number of the techniques you put at top?
You can also use arbitrary attributes in HTML (the HTML5 spec may include "data-*" which is formally legalized) -- while not technically "correct", all major web-browsers will accept unknown attributes which can be accessed through the DOM API.
I'd prefer a single AJAX call to fetch whatever data you know you need at the outset, so you can have a simple JSON object available in your script. You can, of course, supplement that with additional calls should you find you need more information.
If that's impractical, then "hardcoding" a JavaScript object in a <script>...</script> tag is the next best option. Of course, "hardcoding" is from the browser's perspective. The actual content would surely be written by server-side script from your database.
One method you can use is custom attributes. I think you refer to this as micro-formats, but I am not entirely sure if they are the same thing so I have written a description below.
Having hit the same question before, I basically use something like the following:
<div data-pid="1234">
<a href="#" class="add-to-favourites">
<img src="addToFavourites.png" />
</a>
</div>
$("a.add-to-favourites").click(function() {
$.load("/Favourites/Add.php?prodID="+$(this).parent().attr("data-pid"));
});
This should do exactly what you want to do. The reason I have put the pid in the div, not the a tag, is that you can then place all the other product information within the div with other actions the user can take, for example displaying a tooltip on mouseover using data-description, or displaying on a map using data-geo-x and data-geo-y. Of course you can name these anything you want.
Support / Acceptance
This is becoming a perfectly accepted way to do what you want to do. HTML 5 supports this for precisely the kind of thing you are trying to achieve.
So it is supported by HTML 5, but what about HTML 4?
It may make HTML 4 invalid, but the world is moving on to bigger and better things. Older browsers (IE6 and before, FF1 / 2, Opera 7 / 8 / 9) are becoming less common so it shouldnt be a problem. It wont actually break older browsers - the functionality will still work.
Important validity note
Make sure you prepend the data- onto the attribute name. This will make the attribute perfectly valid in HTML 5.
A few extra hints
In jQuery 1.5, I have heard from an answer to my question that you can simply specify attr("pid") to return the value of data-pid. If this is the case then I would be careful when naming the second part of the attribute name after the name of an actual attribute (for example, instead of data-id, use data-pid - especially if the id attribute is specified. I am not sure what effect it would have if you didn't do this, but its better to avoid the problem in the first place than have issues with the site at a later date due to this.
Hope this is what you were looking for.
ASP.NET offers a very convenient way to do this. You can simply write a JavaScript object. I am sure other templating engines offer similar ways to do this.
var person = {
Name : <%= _person.Name %>,
Age : <%= _person.Age %>
};
I would implement a Javascript singleton AppCacheManager that initializes in the document.ready event. A bit JS oop and you have a fully fledged OOP datastore.
Whenever information is needed, you load it through Ajax / RESTful Webservice and cache it in the AppCache Manager. So you have 2 caches: 1. Browser Cache, possible due to RESTful webservice URL caching, and 2: the JS Cache Manager.
You access all requests to the AppCacheManager which transparently fetches the new data or returns the cached data, so that the client doesnt need to know anything of the caching.
in short:
write a JS CacheManager
don't fetch the whole data at once but in small parts when needed and cache them
define a convenient interface for the cachemanager
Example usage:
linktext
Unobtrusiveness is a very difficult thing in JS and i'd be eager to know something about that, too.
hope that helped.