You are viewing limited content. For full access, please sign in.

Question

Question

Hidding fields with JavaScript makes them visible on Submit?

Forms Web Customizations
Updated January 11, 2019
asked on January 10, 2019

Hi,

I have tried all kinds of things, but no matter how I try to hide some fields, they show up when the form gets submitted.

$('.Submit').on('click', function () {
    $(".tip").hide();
  });
function hideobjects() {
  		var element = document.getElementById("q18");
  		element.classList.add("hidden");
	}
$("#Field18").css('display', 'none'); 
document.getElementById("q18").style.visibility = "hidden";
document.getElementById("q18").style.display= "none";

Nothing seems to hold, it will hide it within the form but once I submit it is back to visible.

This particular field is a normal, single line field. I also want to hide an HTML using class or id.

Any suggestions?

0 0

Answer

SELECTED ANSWER
replied on January 10, 2019

Welcome to the twilight zone. One thing that was not clear (to me anyways) from the javascript getting started guide, was this fact.

Any visual changes made by javascript are removed immediately after submitting, they are only there for assisting the user DURING submission.

After submission, the only thing that sticks, is any values your javascript entered into the fields. So that means Hiding, Styles, etc are GONE.

Any javascript defined in the document.ready method is run server-side when creating the archived images. This means you can style and hide things, but not based on events or criteria.

For example if you just enter this:

$document.ready(function() {
$(".tip").hide();

});

The tip class objects will be hidden in the archive image, but this obviously conflicts with code you actually want to run in the browser.

I am still trying to research this browser vs server-side javascript anomaly, but this is what I have gathered so far.

Anyways for a quick answer help, try adding this inside of your document.ready function, a secret way of running code only in the server-side environment.

  if ($('[name=IsLocked]').val() == 'True')
  {
   $(".tip").hide();
  }

 

5 0
View 2 previous replies
replied on January 10, 2019 • Show version history

Like Chad said, "runtime" changes made with JavaScript are not saved, and that is because they are not altering any of the values the form is designed to capture. For example, the styling is loaded from the form layout configuration, and the JavaScript doesn't alter that because it is 100% client-side.

I would say the most stable approach is going to be a combination of hidden fields and Field Rules.

It would help to know more about what triggers the hiding of your fields, but typically I would create a field, hide it always with Field Rules, then you can set a value in the field with JavaScript and a second Field Rule to hide your custom HTML, etc.

Because the value of a field will be saved (as long as you don't tell it to ignore the hidden field) it will keep the field hidden in subsequent user tasks.

 

I see this a lot, so I'll play devil's advocate a bit to explain why I think it is actually good that things work this way.

Consider for a moment that JavaScript changes hide a field or change the color of a field. The first problem is, how do we save that? Data can be captured via a HTML Form posts, but JavaScript execution is outside of that scope; it can alter the values of the inputs, but how do we capture an unpredictable combination of changes.

Now let's say we did find a good way, perhaps using some special ajax calls to the server. It sounds good at first because it makes things like this easier, but there's a big problem. I can open up any form, load the debugger, and execute whatever JavaScript I want.

As a result, I can make whatever changes I want to the form to hide or remove fields, change styling, alter wording, and more all from the browser interface and if a path to updating things on the server is there, it can also be abused. 

Forms will run your JavaScript server-side to give you some control, and I know from experience that figuring that out can be a bit tricky since the form elements change in the "save to repository" task, but giving client-side code access to rewrite your form is not something you really want.

1 0
replied on January 11, 2019 • Show version history

It seems like at some point we might need form design to be a two step process.

First, you design the user facing form. This version would have appropriate JavaScript and CSS so that we could provide a good user experience.

Step two would be a back-end form. Maybe you build this version with most of the same rules, or there's a checkbox to use the user facing form as-is. Some things may be important on the front  and back ends. For example, if you select option "A", we hide field "X". Or, maybe you want the repository version to explicitly show all possible fields, so there is no doubt about which fields were and weren't filled out. Whatever the rules are, as Jason indicated, we definitely want assurance that the form that goes to the repository hasn't been tampered with.

There are also various reasons why you might want to make a form that looks exactly like an existing paper form when it's stored. Layout can, and often should, be different between input and display.

We do something like this in an internal app. The users need to use data in the app to generate various forms and letters that get mailed out. I built a "Forms Lite" module that allows us to stand up forms that are combinations of fields from the database, default data, and user entered data. The front-end form definitions contain all of the rules and formatting hints that make for an easy data entry process. On submission, we take the data and merge it into the more rigid structure of the generated documents. Although, there are still some minor if-this-then-hide-that kinds of stuff going on. A side effect of the architecture, is that if somebody used the browser console to manipulate the form, the server would reject the submission because while it doesn't care about some of the rules, it definitely knows what it needs to successfully generate the end product.

Maybe these specific scenarios can adequately be handled with the current tools, or maybe there's better ways to do it. It's just starting to feel like we're bumping up against some limitations.

0 0
replied on January 11, 2019 • Show version history

I think the most important thing for me would be a "Save as PDF Preview" because it is a real nightmare trying to test that at the moment.

A great example is how the html elements change (inputs go away for example) on the back end so your CSS or JavaScript might go out the window.

Having a preview of that change would make testing infinitely easier than the current process of trial and error trying to figure out what's going on.

I will say that viewing a User Task with the "make form read-only" option selected does give you something close, but again, you can't preview that without an active task.

2 0
replied on January 11, 2019

I agree. The biggest problem right now is transparency into what is going on. There have been some good discussions in which Laserfiche folks have been gracious enough to clarify some of the inner workings, but there's not much formally documented.

As an addendum, in the "2 forms" model, the server wouldn't necessarily be aware of the existence of the HTML elements on the front-end. Although, HTML and JavaScript might still be the best choice for designing the back end forms, since it's an easily accessible stack that doesn't require special tools like Acrobat Pro.

Anyway, this is all stream-of-consciousness-rambling at this point. I don't get to go to EMPOWER this year, so I figured I'd make a nuisance of myself online instead.

2 0
replied on January 11, 2019 • Show version history

To test the live versus archive appearance of a form, I set the form to just re-create a user task every time that it's submitted (it just keeps looping through the user task), and then review the submitted version of the form (from Monitor or another screen that shows history of the form) as opposed to the live task.  That version of the submitted form can still use browser tools (like "Inspect Element") but should look very comparable to what would be archived to your repository.

Another trick I use, if I want a user action of the form to change something with the appearance, instead of triggering it via the user action, I make the user action populate a value into a hidden field (hidden via CSS).  And then my Javascript checks for that field value (checking both field value and field text) upon load and at the time of the user action.  That way, the first time, the Javascript is triggered by the user action, but on a subsequent display of the form (including the archival display) it's triggered automatically upon load.  You have to check both the field value and the field text because value isn't used in the archive version, but the text will still be there in the hidden field.

3 0

Replies

replied on January 11, 2019

Thank you all for a great discussion and helpful tips!!

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...