I have 5 textboxes (name, roll No, address etc) and I want that when I fill my name in first text box (name) then it should fill my all 4 fields automatically which I filled.
I got this in ASP.Net but I want to use this same in classic ASP.
Sounds like you'll need to fire off an ajax call via a onkeypress javascript function call that calls a script which queries your database and gets data for user when it finds a match.
<input type="text" id="uName" name="uName" value="" onkeypress="getUserDetails(this.value)"/>
You can then use the data and further ajax to populate the additional fields.
Related
I don't see any examples linking a form using select elements with options obtained via ajax. I am wanting to initialize a view model property via ajax in order to populate some select lists in my view and data-link the selected id from my model data. I don't need these arrays when doing an .unmap() of compiled view model because I don't want to send the large lists back to the server when updating the model. So, let's say I have data with ProjectID, ProjectDescription, ProjectTypeID, ProjectPriorityID. In my view model, I need to get via ajax a list of ProjectTypes and ProjectPriorities and use them in my view so that I can select the value from a list. I'm not sure how to achieve this without getting the lists as part of the data when doing .unmap() to send it back to the server.
If there is a property for "ProjectTypes" or "ProjectPriorites" in my view model, they always become part of the data when calling .unmap().
Thank you
There are different alternative approaches. One is to have a single model that includes both 'secondary data' - such as all the ProjectTypes - which will not change dynamically, and the 'primary data' which can get updated based on user input. In that case when you get plain JSON data back from the VM hierarchy using unmap() you can 'prune' it and send only the relevant 'primary' parts back the server.
Another approach is to keep the primary and secondary data separate - so the model is just the 'primary' data, and the secondary data is separate - for example, passed in as a helper:
// Instantiate View Models
var appVm = $.views.viewModels.MyModel.map(modelData);
var typesVm = $.views.viewModels.MyTypes.map(typeData);
$.templates("#appTemplate").link("#page", appVm, {types: typesVm});
<select data-link="typeId()"><
{^{for ~types.projectTypes()}}
<option value="{{:id()}}">{{:label()}}</option>
{{/for}}
</select>
You can also choose not to compile View Models for the secondary data, if it is basically 'static', and do:
$.templates("#appTemplate").link("#page", appVm, {types: typesData});
<select data-link="typeId()"><
{^{for ~types.projectTypes}}
<option value="{{:id}}">{{:label}}</option>
{{/for}}
</select>
Another approach is to only send back to the server any data values or array that have actually changed, for example by using a CRUD/REST web service approach server updates. In that case you would need to have code that diffs the data, or use observe or observeAll to respond to incremental changes...
I was wondering if I can get feedback about whether this is best way to design a form for an associative entity.
So I have a users and events table with attendees as the associative (table) entity. The attendee table has...
its own id (PK)
a user id (FK)
an event id (FK)
a date.
My current form handles options to mark attendance to a number of events, and the ability to remove (update) their attendance.
This is done through checkboxes. If the checkbox is checked, you are attending, if not checked, you are not attending.
My form then handles the scenario like this...
<!--
An array of hidden attendee table ids (in this case the database
has found the user previously marked attendance for 3 events):
-->
<input type="hidden" name="attendee_id[]" value="1">
<input type="hidden" name="attendee_id[]" value="2">
<input type="hidden" name="attendee_id[]" value="3">
<!-- A number of event ids for a specific date: -->
<input type="checkbox" name="attendee_checkbox[]" value="15">Event One
<input type="checkbox" name="attendee_checkbox[]" value="16">Event Two
<input type="checkbox" name="attendee_checkbox[]" value="17">Event Three
<input type="checkbox" name="attendee_checkbox[]" value="18">Event Four
When the form is submitted...
First, I have the database delete all the rows in the attendee table by id (attendee_id[]).
I then have the database insert new rows where attendee_checkbox[] post variables have returned.
So for example, the user unchecks two events, and now "Event three" value: 17 is submitted as the only event id in the attendee table.
So would you say this is an acceptable way to handle this scenario, or would you handle it differently?
Thanks.
This is not really about database design. Anyhow...
The approach you describe works, but it doesn't appear very elegant. When the user just checks or unchecks a box, you'll delete all those records and build them anew. But there is no compelling reason against this.
Still, depending on the capabilities of both your data access layer and/or GUI layer, there might be better solutions.
If you use an ORM framework like Hibernate or JPA, you might read the user with all her attendance records. You will probably have done this already to display the attendances, so it won't even mean additional effort. Now you can iterate over the collection of user.attendances programmatically, delete and insert according to the current checkbox values, and then persist the user, cascading down to the attendance.
Modern GUI frameworks like AngularJS allow to react on a single user input. In this case, you would have the framework listen to each check/uncheck event and issue a REST call to the server for exactly one addition or removal. Or, if you don't want such a call for each single change event, you might collect the issued changes (like "insert abc", "delete def"...) on the client and submit the whole bunch of them to the server, which will then exactly know what to insert and delete.
I want to send my clients in my database an e-mail with a request to fill in a Google form to research their needs for our service in the future.
Every client has an unique ID already (for example EX0258, EA1405, EZ2815). I need a way how I can add this unique number in the spreadsheet that they will fill in. Of course, I can ask them to provide them by themselves, but this can cause mistakes in the information.
What I am looking for is a unique URL for each user that provides the Google Form Spreadsheet with that unqiue user ID. I hope you understand my question and that you can help me out with it.
If you have the id ready to go from your db you can do it via Google Forms, but it seems the process cannot be automated (see https://support.google.com/docs/answer/160000?hl=en)
If you are open to a 3rd party solution, you could do this with Cloud Snippets via cloudward.com. You could just include the id as a parameter like this:
your_domain_here.com/page_name.html?unique_id=ABCD1234
The code would look something like this:
<# start form for google spreadsheet "Your Spreadsheet Name";#>
<input type="text" <# your_column_name #> value="<#[url.unique_id]#>">
<input type="text" <# your_column_name2 #>>
<# end form #>
The unique ID in the snippet above would be ABCD1234
I am using ColdFusion (Railo 3.3), and I have several forms using jQuery that can dynamically add a set of form fields (for instance, the user can tick a box to add another company owner that brings up all the relevant fields for the additional owner). All the information needs to be inserted into a database, but I don't know exactly how many fields will be submitted at any given time.
How do I process this arbitrary number of fields to insert into a DB with ColdFusion?
Thanks!
Form is a structure aka Collection.
You can just loop over the entire form structure and insert all the fields, you will probably need to exclude some like the submit button etc, but you should know the name of this.
<cfloop collection=#form# item="field">
<cfif field neq 'submit'>
.... insert into DB #form[field]#
</cfif>
</cfloop>
I have several values in a select box. Is it possible to get both the value and the text between the <option> tags when the form is submitted?
<option value="413">Highland </option>
<option value="414">Inverclyde </option>
Alternatively I suppose I have to store the names in a table or array for retrieval but would be much easier if I could just insert both in the table when the form is submitted.
As Stephen Moretti pointed out, there are at least two ways to derive the text from the value.
You could also use a list containing the value proper and the text for the value of the select. So, instead of:
<option value="23">Twenty Three</option>
use
<option value="23,TwentyThree">Twenty Three</option>
and use list*() functions on the back end.
Finally, you could use JavaScript to store the text of the selected option in a hidden field (or similar). This, in my opinion, is the least attractive option. First, it would be more work than the other options, and second because it will fail if JS is turned off on the client.
Depending on the size/type of data, I would probably either rewrite the option values, as I've described, or switch off a lookup table, as Stephen described.
If you've only got a few value/text pairs in your select, then just store the value. If you need to output the text somewhere else other than the select, just write a if/elseif/else or case block to display the text.
If you've got quite a few value/text pairs then it would be best to create a lookup table in your database with these in. You can use this to generate your select and output the text from a stored value at a later date.
How do you tell if you've got too many value/text pairs? If writing the case block to display them results in a silly amount of tedious code. ;)
Another option would be to store a struct of your value/text pairs in the session scope, then on your form action page you can use the value to easily look up your text.
The beauty of this is that it's entirely server-side and does not include an extra trip to the database.
Delete the struct from the session scope if you don't want to keep it around.