I have just started implementing search module in a project, where I have a form with fixed fields consisting of combo box, text box, radio button etc (around 200 fields in multiple tabs), and later client should be able to add extra fields too. Once user fills the fields which he wants to search, that search criteria also he should be able to save. For all these reasons, for each field I am associating metadata in the following format.
"EntityName.attributeName": attributeValue
Once the user fills the form fields to search, I will validate form data and and only non empty fields metadata I am sending to server in JSON format. Everything is fine till now. But I am facing an issues now.
Using the metadata of each field I will create a new criteria for each field. but if there are fields where one field metadata depends on other field metadata I am struck.
In the form I have few special category fields in following format : for example DOB,
FROM DATE (meta data: entity1.dob)
TO DATE (meta data: entity1.dob)
both fields belongs to same entity and same column only field name in the UI is different
Like this I have around 20 fields which asks for FROM and TO to query the range (it need not be on date, for example no of bed rooms..it can be on integer, string etc)
My query formation should be in the following way depending on user search criteria. If user entered only FROM field of number of bed rooms then I have to query using EQUAL to operator in sql and if both mentioned then MORETHANEQUAL to for FROM field and LESSTHANEQUAL to for to field. So how I can handle this special case ?
like if he entered number of fields as 4 in TO field of number of bed rooms, then I have to query for houses having number of bed rooms equal to 4. but if in FROM he entered 3 and in To if he entered 7 then I have to query for houses having greater than or equal to 3 bed rooms and less than or equal to 7 bed rooms.
Since I have same metadata for these category fields also I am unable to proceed, to achieve this, what kind of metadata I need to prepare ?
How I can generalize this process to handle all the cases ?
my technology stack: ExtJs, Eclipse Link, spring.
and what are the best practices to follow to support custom fields adding feature in Forms in enterprise applications ?
Off of the top of my head, I would create wizards for these particular cases. So for example, have a custom wizard that allows the user to define a "from" field, a "to" field, and then the comparison operator in one action. This wizard could also be responsible for adding custom properties to the generated fields that could be used by your validation routine. So based on the combo of from, to, and operator, you could create a flexible validation mechanism for ensuring that correct values are entered, ranges are correct, whatever.
You might consider this "wizard" approach for all custom fields, in fact. I could see you predefining all the possible custom field types that could be used and create classes that can be used for those. The classes could be responsible not only for the field creation, but also for providing any custom validation, pre-submit transformation, etc. This approach would make adding new custom field types incredibly simple since all you'd have to do is follow the same implementation as the others that already exist, extend an existing one, etc.
Related
I'm creating an ASP.NET web application which allows users to digitize paper forms. The user will import their own forms which will be converted into HTML with placeholders inserted to accept values from an input form.
Using the fields on this imported paper form, the website will create an input form based on what information is required. "Templates" can also be created for a specific form which allows a user to auto-fill any data that doesn't normally change with each form fill. A user can also save a form they haven't finished for completing/reviewing later.
My question is: how do I store this data? I can't really use a traditional database table because Form X could look nothing like Form Y and require completely different data. I have a SQL database to store the data in (I need this for other aspects of the site too), but I can't simply store all form data in one table or even have separate tables for each form as this will be impractical on a larger scale.
My initial thoughts were using JSON but I have absolutely no idea where to start with this. Can I put JSON data into a regular SQL database column? Can this be used to generate code to build a web form to allow a user to easily fill out their forms using any device (as per my design requirements)?
I think your problem would be very well served using a document DB like mongoDB or Arangodb. Reality nowadays is that applications can , and sometimes should, use more than one DB.
Having said that, if I had to use a relational DB, I would convert your forms into 3 tables. The first top level form would just store something like:
form name ,
form id ,
etc...
The second table would capture the form fields and would look be something like:
FormID
field Id
field name
fiel type (int, varchar, etc...)
sort no.
etc ...
The third table would capture the information entered by the user:
user id
form id
field id
value
creation date time
last modification date time
etc...
Note that by storing the fields in rows instead of columns, it does not matter that you have different types of forms.
I should mention that the above table definitions are not meant to be complete by any means, they are there to give you an idea on how to get started.
Finally, note that many relational DB allow you to store JSON nowadays directly in the DB as you suggested, but that may not be a very good option depending on which DB you are using. Here is an example of storing JSON in mysql just for your reference.
In several notes applications, instead of handling related data as separate documents, if the size of the data is small (less than the 32k limit), I'll make several multi valued fields and display it in what I call a "List Panel". It's a table where each column displays one multi-value field. Since fielda(1) goes with fieldb(1) that goes with fieldc(1) there is a concept of rows. (I did a similar thing in my auditing routine discussed here )
It is always assumed that each field has exactly the same number of elements.
All the multi-value fields are then stored on the single document. This avoids several coding conventions that made my eyes bleed like having date changed, who changed it, new value fields for each field we wanted to audit. Another thing that this kept to a minimum was having to provide multiple fields for the same thing that locked you into a limit. Taxrate1, Taxrate2, Taxrate3, etc...
In my "Listpanel" the first column is a vertical checkbox. (One for each element in my lists) This is so I can select one item to bring up and edit, or select multiple values to delete "rows" or apply some kind of mass change to them.
What would be the best way to handle this under xPages to get this functionality? I tried making a table but am having the devil of a time to get the checkboxes to line up with their corresponding data items.
Views and dojo-grids seem to assume we're using a document for each row.....
This TableWalker may provide what you want http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Tutorial-Introduction-to-XPages-Exercise-23
It was created when XPages was all very new, so it's SSJS rather than Java. But if you're comfortable wiith Java, converting it probably won't be a challenge.
You could use a repeat control to display the values and build a table using the table row tags in the repeat. You would want to calculate the id of the checkbox to be able to take an action on that selected row. The repeat var would be just one of your multi-value fields and you use the index of the repeat to get the value for that row from the other multi-value fields.
I'm trying to find the does and don'ts for implementing text fields for web pages. Some examples I can think of are
1) Consider real time limiting length of a text field versus informing users of length restrictions on submitting a page
2) Handling of special characters e.g. $!^*!( etc.
3) Special validation of text fields for specific text field types e.g. email fields, phone number fields etc.
It would be great if there was a document that covers guidelines such as these.
Type of input field
Provide the appropriate type of input field based on what is being requested. Each type of input field has its own characteristics, which users are accustomed to. For instance, use radio buttons if only one option of several is permitted, and check boxes if multiple choices are allowed.
Customizing input fields
Do not invent new types of input fields. This was common in the early days of Flash websites, and it seems to be making a comeback; I have seen some odd input fields implemented with jQuery. Simple is often the most useful. Keep input fields as close to their unaltered HTML rendering as possible.
Restricting the format of input fields
If you need to restrict the format of data inputted by users, then at least do so in a way that won’t irritate users. For example, instead of displaying MM/DD/YYYY next to a text field for a date, consider using three drop-down fields or, better yet, a calendar control.
Mandatory vs. optional fields
Clearly distinguish which input fields cannot be left blank by the user. The convention is to use an asterisk (*). Any symbol will do, as long as a legend is visible to indicate what it means (even if it’s an asterisk).
http://www.smashingmagazine.com/2011/11/08/extensive-guide-web-form-usability/
Text fields allow the user to input text. They can be single line, with or without scrolling, or multi-line, and can have an icon. Touching a text field places the cursor and automatically displays the keyboard. In addition to typing, text fields allow for a variety of other tasks, such as text selection (cut, copy, paste) and data lookup via auto-completion. See Patterns > Selection for text selection design.
The type of text field determines what kind of characters are allowed inside the field and may prompt the virtual keyboard to optimize its layout for frequently used characters. Common types for which you should optimize include number, text, email address, phone number, person’s name, username, URL, street address, credit card number, PIN, and search query.
To read more visit http://www.google.com/design/spec/components/text-fields.html
I have a scenario wherein with the following details:
I have a form that contains fields like firstname,middle name,lastname,dob,pin,address for Client 1.
Now this form has to cater more than one client . The problem statement is - different clients may require different number of fields to be displayed on front end. For eg: a 2nd client would want - Country field instead of pin, would not require address on the form.
Now when i submit the form , currently i have a constant query which takes values of - firstname,middle name,lastname,dob,pin,address and inserts it into database for Client 1. I want to develop a query in a way that it is created at runtime and inserts only the values that come from the form into the database..
I hope my problem is clear. Can anyone help?????????????
You need to think about why you are doing this.
It will get hideously complex with just person form, add in more and it will balloon big style.
Dynamically building queries isn't particularly complicated, but it's a lot of code to do it.
Just think about each field you want to add to the query and it's type. What if a property on your person record was an image of them.
Do you have a configuration of the form, is the promary key on the record an auto inc, is it a compound key, do you use defaults, are some fields not null. How are you going to bubble back referential integrity exceptions...
Do the all singing all dancing version and basically you reinvent something like the Access IDE....
Personally I'd have a Person object with a set of Person Properties, they would have name, a value and a boolean to say whether they'd been changed.
Once you have teh list of chnaged properties and beacseu you are in the Person object you know the table is persons, it's keyed by an autoinc bigint, gender is mandatory and defaults to Male...
You have a fighting chance.
Your query should use parameters
So it would be say Insert Persons(FirstName, LastName, PIN) Values(#FirstName,#LastName,#PIN)
Then you'd nip through your changed fields and add parameters with same name, type and value.
As I said you can really go to town with this one, may be it's time for a night in though.
This should mean that some fields in your table like address and pin can be empty, in that case you can do without a dynamic query. Just collect all the inputs from your form and insert them into your table. Those form fields that were left empty due to different user needs will consequently have their corresponding field in your table empty. So just list all the needed fields in your table and all the possible input from your form in your insertion query.
How to compare 2 infopath documents craeted using double data entry system for
differences ?
We have a small project contains few infopath forms. Client is using double data entry system to reduce the errors. We are maintaining entry number in infopath form to seperate each entry.
Note: I know we can compare xml data
files of 2 documents. (xml data file
has field names like field1,field2 and
so on..while on form that field1
represent some meaninngful text) But
the question is we want to compare it
Visually side by side. Any difference
should highlight the field.
The easiest way I can think of is to use a different "comparison" form (instead of trying to alter the original). The new form can have two columns - two fields for each original field. You can load the two documents to compare into datasources (even make fields at the top which prompt for which two docs to compare). One shows in the left column and another in the right. Then just use conditional formatting to highlight where the first column doesn't match the second, or even hide the fields where they are identical so only the differences are visible.
If you want to get really fancy you can even let the user specify or change the values on the form and have them save back to the originals or create another new "merged" version.