Good day, I've struggled with an upcoming forms project architecture, specifications are as such from the stakeholder:
Django framework,
Bootstrap5,
Floating Labels,
Multiple Users that cannot have access to each others db.
Operation Theory:
A law clerk logs in, request a form via API, the questions in the form are somehow saved and presented to a user logging in at different times. After the questions are answered by the user, the Q's and A's are submitted and saved for review before being pushed elsewhere.
Things I'm struggling with:
Should I create two(2) tables and save the questions returned from the API as field entries? Then, once the user is prepared to answer, dynamically present the questions using floating labels and then save the answers to another table?
The questions from the API call are of any length, it can be as little as 5 or as many as 130, how do I create fields at runtime with floating labels accodring to the questionaire length? Also have to match them(Q's and A's) back up for review by a third party.
Related
I'm building a graphql schema through AWS AppSync and have a question regarding schema structure. My app will show users new posts and have them either join or pass on them. I'm trying to build in a way that I will only show users new posts and not repeat or at least not repeat for a certain amount of time. It's similar to swiping on tinder, they don't show you somebody again if you've already swiped on them. Does anybody have any ideas how to structure this in my schema. Do I need to store references to all of the seen posts in the user model or should I store each swipe as its own model and how should I structure the querying? I'd appreciate any advice on this.
Thanks!
Assuming a post has a creation time, you could keep track of the last (max created time) post they've seen, then display anything after that.
But think about what happens if they've been off the app for 5 minutes, or 5 days, or 5 weeks... depending on the volume of posts you anticipate they could quickly get behind and have to wade through too many older posts.
One thought would be to show the next oldest post, based derived from the creation time of the most recent post they viewed. Unless N number of posts were created since the last time they were online (a threshold you'd have to decide). Then start with displaying the N - Xth post (where X is 5, or 500, again depending on volume) until they're all caught up.
There are lots of ways you could program it, it all depends on your use case, you may want to take "popular" posts into account for example, those might be weighted above/before the other posts in their backlog.
Hope this helped.
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'm creating a web app for my client as a part of my schools final project.
It's a web app where users fill forms (surveys) and after forms are submitted,
values are saved in the database.
There are three types of users: admins, moderators and viewers. Admin's can see the
overview of filled forms, moderators will fill these forms and they also can make edits
to them and get the overview of the forms they've filled. We haven't discussed about the rights of viewers
at this point.
I'm using CodeIgniter as a framework of my project since it comes pretty handy when it comes to database
manipulation and forms. What would be the best way to implement this kind of situation? There are apprx.
4-5 forms (surveys) each moderator will fill. After they've filled them, they only can make edits to that particular form.
So one user can fill each form only once.
I've designed that each of the forms needs one table. So if there is a form (survey) about IT equipment, I will create
a table for IT equipment. User's id number will be saved in to the last column in the table, usually called "user_ID" where I can
make queries based on users and check if user is already filled the particular form.
What about controllers and models? I've thought I could only make one model for inserting and editing the form.
However, is it pretty much the only way to create a controller or method foreach form since there are different types
of form fields to validate based on the form user is actually filling. I've already created a controller for inserting and updating
the IT equipment form and both of these methods are pretty big when it comes to the amount of code, over 200 lines per method.
So that would be a total amount of 2000 lines of code just for inserting and editing all the forms.
What'd you do and how you'd implement this if dealing with similiar kind of project?
Thanks in advance for all the ideas and point of views!
You should take a look into this:
http://cibonfire.com/
It's a really good addon for codeigniter, that allows you to data oriented development.
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.
Hi Sitepoint wizard people,
Say we have an admin application that has multiple users and various objects. What I'd like to do is control access within the object itself - that is, it will behave one way for one type of user, and another way for other users. For example...
Director Mike can override Reception user Sally's registration date. One would assume that Mike could set any date both in the past or in the future. Then we have Payroll user Steve who can also modify Sally's registration date, but only for dates in the past up until (for example) one year ago. To spice things up, then we have the HR Manager Mary who can also amend Sally's registration date, but only for dates from precisely 23rd June 2007 up until one month from now...
How can I program the access restrictions so that on the front end, the form control is restricted with a min and max date, and in the backend, the validator checks the entered date to make sure it falls between those dates? I'd obviously need to be able to tweak the min and max dates for each user type. Other objects might have different parameters - maximum amount on a discount field or days of the week for overtime, for example.
I've asked this question in different ways, but each time I get bogged down by the implementation. I'm currently developing it as a php/MySQL web-based application, but thoughts and comments from other platforms very welcome! This time I'm looking at first principles, so it doesn't matter what your background is, if you have any ideas, please let me know! What do you even call this type of access control...?
Depending of how you application is based, you could ask for credentials at the start of the application and depending on who is requiring access, you could load a different xml file containing different settings.
As for security issue, make sure that the different xml files can't be reached by the users.
Edit:
Since you are using MySQL you could do something like this.
Let's say you have a table of users that has those fields : UserId, UserName, RestrictionId.
And with a Restriction table that looks like : RestrictionId, FieldName, FieldCondition.
This way, in your php app, when a user is authenticated, you can go fetch the correct "Restrictions" on the field and apply them in your code. If it happens that you have multiple fields that require different rules then you can simply add them with the correct RestrictionId.
This DB design is far from perfect, I'm pretty sure you can do better
Since, you are already using MySql db. You can maintain the UserRole Master table details in DB itself. Load the user role data based on login, then you can easily validate the changes made by the user accordingly.