Just (a/some) few things that I have learned thus far in my journey of Leap form development. A mix of lessons learned, product quirks, etc.
Previewing Changes
While majority of the changes you make can be saved and previewed, the following changes require the application to be deployed in order to test:
- Attachments
- Submit Button Actions
Also, when you close the project and then "Launch" the application from the "Manage Applications" screen, the application will not include your saved changes. You must deploy to see your changes.
(as of Leap v9.2.0.0_19)
...
- Do a submit action, call it "Save Draft" and point it to itself (as it's next stage)
This will allow the user to see the "Print" button when they re-visit the form; upon clicking it, they can print/save as PDF etc.
Pros Cons Simple / Straight-forward setup NO control over the output; cannot style the CSS (cannot include a custom print style-sheet Quick Have to write a few lines of JavaScript to tell Leap to mark fields as "Not Required" — because by rule, one can only submit the form when ALL required fields have been filled out Involves like 50 steps before the user can actually execute the Print functionality
Do custom JavaScript that traverses the form fields and captures the fields and their values... sounds easy until you actually do it
Pros Cons FULL control over the CSS of the print page Time consuming (comparatively) to implement No need for creating yet another submit button. Needs one to be proficient with not just JavaScript but also with Leap's custom JavaScript API User does not need to submit before they can make use of the Print functionality Once implemented in one place, applying logic to other stages—or even OTHER APPLICATIONS—is a piece of cake!
At the end of the day, it all boils down to:
...