I have a google form where individuals are inputting two numbers via dropdowns: 1) Required Base Salary, 2) Total Target Compensation. Using app scripts I would like to have real time validation to insure that Total Target Comp is greater than or equal to Required Base Salary right after they make their selections. Is this even possible?
You can't interact with a Form answer until that answer is submitted. As a workaround, you could split the quizz into two forms. The first Form would include the Required Base Salary, while the second Form would ask for the Total Target Compensation based on the results of the first Form. As an alternative you could warn the user about the correct values on the question description (and send him an email warning about incorrect values after the answer is submitted). Additionally you could set up data validation rules to prevent bad values.
Related
I have a question to determine if something is possible.
I have a report where the user enters in a client number into the parameter. This parameter is not loaded with available values because the number of unique client numbers is too large. After they enter a client number, they receive a list of that client's matters. Some clients have hundreds of matters.
What I want is for the user to be able to click on a matter and have it take them to a second report, the go to feature, that shows them additional details about that one matter they clicked on. Is that something that's possible? I don't want the user to have to input a matter from a list of values on that second go-to report, so maybe it's possible to have a cascading parameter in the second one that's hidden from the user but auto-populates based on what they clicked?
I'm still trying to get cascading parameters to even work for me, but I'm not even sure where to begin researching what I want to do here. Any guidance on what to look for would he super helpful, or let me know if it's not possible.
Thanks!
Rough guidelines:
create a report that accepts the matter number as a parameter
on the textbox/cell in the original report that the users will be clicking, right click on it and select properties, set action to go to report, and then select the new report and pass the value of matter id to the new report parameter
I am currently using APEX 4.0. I would like to make a validation that would apply for multiple fields in a form. For example, I want specific fields to only accept a Y or N, and they must be uppercase letters. As of now, I have one validation for each field. Is there a way to make a single validation that would apply to all these fields?
Creating Re-Usable Form Validations in Oracle Application Express (APEX)
This solution was developed on a Apex instance hosted on Oracle OTN (apex.oracle.com). This instance is currently at version 4.2.5, but the design elements discussed within this solution should still be compatible across the versions from 4.0.0 and 4.2.5.
The way you can approach your form design is not necessarily to catch exceptions through a validation step once the form has been completed and submitted.
Instead, simply consider limiting the choices that the user can choose in their input, and control how that input is interpreted once it is submitted as changes to your data table.
Pre-Validate By Defining Restrictive Value Choices
Here is an example of the OP requirement defined as a "Shared Component" through the "Application Builder" menu. Create a named LOV (list of values) with a static definition. Here, you can define the value pairs of:
DISPLAY, which is anything user friendly you want the user to see. Even if Y or N is pretty self-explanatory, explore other options such as spelling it out (such as: YES) or combining the real value with the display (such as: Y (Yes)).
RETURN VALUE, which is where you enforce what goes into your database. In this case, the uppercase, single character values mentioned in the OP requirements would go here.
This is what that LOV definition looks like:
APEX LOV (list of values) Design Screen
Eliminate Free-form Data Form Item Display Types
Following with the initial concept of a limiting LOV, convert all your form items to use display-types which use a "List of Values" definition pointing to your "Shared Component" (or Named LOV).
Use the SAME LOV definition for questions requiring the same input rules. Now the user has no way of changing the data values outside of the OP definition, and there is some flexibility to use more instructive/descriptive display values so that they are more likely to make the right selection as well.
This is an example of how a input form with the same input data types can accomplish this task with no additional validation:
Sample APEX Form Design with Reusable Input Restriction Rules
In this example, I experimented with a few form item styles, including
The standard text-box entry field. (Problematic without coupling it with additional validation logic).
Select-list entry items worked the best. See the discussion at the end of this solution for more explanation on choosing specifics such as specifying "null field values".
Radio group selection buttons work well to as they provide a visual layout of the valid form choices without additional drilling-down or scrolling.
All three options used the same LOV definition.
Examples of Data Input Using LOV Enforced Restrictions
After experimenting with different kinds of inputs, here's a few things that may be helpful depending on the situation or the deeper requirements of this OP or other readers.
DISPLAY EXTRA VALUES should be left as set to NO. This is the reason for restricting the input possibilities in the first place.
DISPLAY NULL VALUE is best as NO if all answers require a response. If NULL is possible, there is a useful third (defaulted) value that can be used for additional user-friendliness.
Sample Data Inputs and Values from the LOV Restricted Form
Notice that the free-text entry field presents additional problems with data quality without some other form of validation or checking. The other form fields provided accurate data input reflected through the target database table.
Some Closing Comments and Points for Further Study
This solution is only a partial one with respect to protecting information stored in a database table. It is not uncommon for lots of other systems, applications, programs, api's, etc. to also have access to change or add data to this back-end data source.
What if another group of developers independently created an api for managing data in the same table? Unless they read the documentation of the OP or examined existing data sets already present, their project team may not have designed an accurate interpretation of the rules which sit at this point, only on this particular APEX application.
Depending on how vulnerable your system is, it is also good practice to apply relevant safeguards, such as schema level table constraints (such as check constraints), Not Null constraints (where applicable) and even DEFAULT values settings (established by triggers or table default values).
From the Author...
Again, it isn't all necessary to go to this detail... if the input form of the Apex application offers only two choices: "SOUP" or "SALAD", it is unlikely that "BACON-ORANGE-CHICKEN" will pop up in the table after deploying the application into users' hands.
This kind of design approach skips a server round trip worth of I/O because the user already know what is on the menu at the initial page loading event.
Although the OP request is very simple and generic (Y for YES or N for NO), it presents a useful pattern for more complex input screening procedures that can happen even before the data is submitted.
Good Luck, All!
Onward.
I have added some check boxes in my drupal form. User can select either one option or two or all the three given there. Though am able to throw a validation error that at least one of the check boxes should be selected, am not able to validate if two or three are selected or not and the values are also not getting stored in the database provided.
How to do the validation so that whatever values are selected, its getting stored in the database?
Requesting help please.
Storing the values in the database isn't typically part of the validation handler, it's usually handled by a submit handler function. The specifics of how the data should be stored depends a lot on what the data is and how it's going to be used, so you'd need to provide some more details in order to get a more concrete answer there.
In general, I'd recommend checking out the Examples for Developers project, which provides lots of working code samples that demonstrate various aspects of Drupal development, including a form example.
List of values, with multiple columns and multiple return values in Apex. It's a question i've seen around the web quite a few times, but i'm struggling with it aswell.
Coming from Oracle Forms, and now migrating forms to Apex, this is a feature i'm missing quite well. It also still baffles me a bit how enormously basic the built-in popup-lov is.
For example, right now i'm making some smaller forms, each having about 4 or 5 multirecord columns, for not much else than having 2 values linked up. Column 1: some value, used in sap for example, column 2: the id of a record in the oracle database (another table than the base table for the block). On column 2 there is an lov, with validate from list, and displays 3 columns, but also returns 3 columns. So you can choose a record from the lov, and automatically, the id will be filled in, aswell as the 'name' and 'description' for said id. Column 1 and column 2 form the base table of the block.
Now, in Apex, i'd loose this functionality by default. So for now, i've mostly coded the onchange event in javascript, and get the values with an ajax callback process. In the popup i concatenate the 3 columns. This however looks stupid (in my most humble opinion) when you want to force the user to pick a value from the lov ('Not Enterable, Show Display Value and Store Return Value'): the item will contain the concatenated value used in the lov, not just the id i'd much rather show - plus, i'll already have my other 2 fields filled in by the ajax callback.
It rather stings a bit to have to deal with this. The users are used to working with these old (headstart generated) forms, with just 2 enterable columns, one of which has an lov. Now they need to start working with this 'new tech', and even though there is some adjustment required, this area does feels a bit archaic at times!
So, i've made it work through an Ajax callback on the onchange event. So, when the value is changed through the lov, extra fields are filled up. This goes together with an after header process, after the automated row fetch, so the values are fetched when the page is loaded (or a user navigates the rows).
I've also written a custom solution, which requires me to create a page with a classic report on it with a search box. I then use this page in an iframe, and pop it up through a modal. When the user selects a record, i return the required returnvalue and a list of displayvalues. This i do through a bunch of javascript, which i've packed in a JS file, and actually requires quite little extra work to do on the pages: include the file on both, make an item with some post element text calling an 'open' procedure, and calling a select-and-close procedure on my lov page. I'm quite considering creating a small item typep plug-in, so i can more easily configure my calling item. Just a couple of buts: i've not actually used this in some forms already, i've engineered this in a testing application after getting frustrated with the standard tool. It would also require the client to maintain this javascript code + remember the config of the 2 items, let alone me writing a small plugin. So i'm hesitant to implement this.
TLDR: if you've been using Apex for a while, and maybe done some forms: how do you actually work with the popups. And if you've known forms: how did you deal with this change?
I'm still struggling - throw me a bone ;)
I haven't used it myself yet but I believe SkillBuilders Super LOV plug-in probably does what you need.
Im working on an mvc3 application that will be deployed globally and have a question about phone numbers and validation.
I want to display a textbox that allows customers to insert their phone number correctly based on the machines settings.
I know I can apply all of my regex's onto the model's PhoneNumber field.
If a user is coming from the US vs the UK there are 2 different regexs to be used.
Lets say a US based user inserts an invalid phone number how can I tell the application only to validate the phone number using the US format based on the users culture not against the entire range of regex's?
I dont want the user to be told that his/her phone number is not formatted in UK format as that means nothing to them.
Hope this makes sense.
There are a lot more than two regexes.
For the UK alone there are are getting on for 10 or more different formats for telephone numbers and that doesn't take into account the different ways people can (and do) group the digits as well.
My answer to a different question shows the different formats.
You're best approach is probably to use other data on the form to try to validate the phone number rather than analysing the number itself.