I want to add multiple custom fields to the lightbox in dhtmlScheduler. I realize that this is a dup of a prior question but that answer is incomplete/incorrect.
My application correctly stores and recalls data from a MySQL database using dhtmlxDataProcessor on the client and dhtmlxConnector via PHP on the server side. I have carefully read, re-read, and parsed documentation on Custom "details" form. I've worked with the code in the 05_custom_editor.html sample.
The problem is that those examples do not work - they silently fail to store the second field, "Details", in the Description section. This is not surprising since nowhere is the field mapped to a database column.
What changes are needed so the "Details" field of the example form stored in the database and recalled with the event?
What changes are needed to support read-only data in the Details field that is populate based on the "Text" field? What I'm thinking of is a name that has an address associated with it.
How to invoke a custom windows with a form from the lightbox to populate the address?
I would prefer to be able to do this by extending the default lightbox, but that is not a requirement.
Any guidance is appreciated.
There are 3 required fields when using dhtmlScheduler. They are the first 3 in your PHP connector:
$scheduler->render_table("my_table","id","start_date,end_date,name,details,....
Your connector may use any column names as long as the order is preserved. But because it's required and used all over the place the dhtmlScheduler must refer to the name of the event. It is called "text".
The lightbox section maps description on to "text". I think that there is no
scheduler.locale.labels.section_description
for the same reason.
1) Update the PHP connector to pull in the required fields.
2) You can use sched.formSection('myfield') to get components from inside the lightbox, then you can add javascript to blur on focus.
3) Normal javascript
You can use one of the custom events alter any form items before you display the lightbox.
My dhtmlScheduler seems very vocal when it fails! What does the console say? Have you stepped through to see where it's failing?
Related
Okay I have seen script which I got from this site Adding input elements dynamically to form
I have made some slight changes to it. The objective of the script is to ask a user for an input and then supply them with number of fields. Assume the person puts in 3. I would then want to capture those three inputs as a list and export them to python. I am currently using cgi-bin and python. Those are parameters I have to work with.
How can I pull the elements from the web form using that script
Once I activate the addfileds function. I am unable to see fields in the form below it. I would like to have more than one dynamic fields.
I use suitescript user event to add tab and some field belong to that tab when open a sale order. However, whenever I save the the information in that field, I can't see the information I manually input and save when i go back to that document. It seems like I miss the step loading data for custom field. Any suggestion on how to fix that problem? Thanks!!!
The normal way to do this is to create a customized form, rather than writing SuiteScript.
Have you looked at the field APIs? I would try nlapiGetFieldValue().
You are creating a fields dynamically using script. You should be aware that the information on these fields will not be saved because you created it using a script unless you get the value of this dynamically created field and put it to an existing standard or custom field before you submit the record to capture the information. As for viewing the record you need to get the value from the standard or custom field and set that as default value of your dynamically created field.
I am not sure why you need to create the field dynamically if you can create a custom field.
I have a Java EE JSF/Primeface app with an entry form for adding/editing an entity. Let's call it Product On that form is a field to specify the Salesperson, which would really be the Salesperson's Employee Number. But most data entry users don't know the salespersons employee number off the top of their head.
I'm looking for a way to either click open a popup window where the user can put in a keyword or two, find the right B.Smith, J.Doe, etc..., click their name and have that appropriate employee number pop into the text box on the parent form.
Or somehow do this inline in the parent form where the user starts typing any keyword and ajax queries the employee database, appropriate salesperson is selected and the employee number replaces the keywords typed in the input text box.
A nicety is to have (in an non-editable state) next to the text inputbox with the employee number, the salesperson's full name corresponding to the employee number.
Or some variant of those.
I had this working in a JSP application using some hacked together javascript, but I'm having trouble porting the functionality to JSF/Primefaces and was wondering if this functionality is already available in either technology. I've been searching for a solution for a while.
One of the biggest issues if I continue to use my old javascript is knowing the the parent forms textbox id to know where to pop the value in. Using JSF form I'm getting things like j_idt28:j_idt29
You should not need to mess around with Javascript for that case, so you won't need to know the generated ids.
Since you use PrimeFaces, you may want to look into the Autocomplete component.
Besides that, you can always make use of the f:ajax tag to respond to user input and update fields according to it for example.
First time asking a question here so please be gentle... I use a set of perl script (no judging please) that are great for simple flat file database creation, updating and searching (www.ezscripting.com/csv). I have used these scripts well beyond the intended uses including being able to display data using a javascript to call the data.
What I'd like to do is have a form field that searches a specific field in the database, let's say . What I'd like to do is allow a visitor to start to type in the search field and have the OnKeyUp event handler trigger a javascript call that will pull up to 5 entries in my database.
Is there a way to have OnKeyUp in an input field tag trigger an embedded javascript each time a new letter is typed?
There's an example here
that uses AJAX to do what I think you're trying to do.
In my asp.net MVC application I am using in place editors to allow users to edit fields without having a standard form view. Unfortunately, since I am using Linq to Sql combined with my data mapping layer I cannot just update one field at a time and instead need to send all fields over at once.
So the solution I came up with was to store all my model fields into hidden fields, and provide span tags that contain the visible data (these span tags become editable due to my jquery plugin). When a user triggers a save of their edits of a field, jquery then takes their value and places it in the hidden form, and sends the whole form to the server to commit via ajax.
When the data goes into the hidden field originally (page load) and into the span tags the data is properly encoded, but upon the user changing the data in the contenteditable span field, I just run
$("#hiddenfield").val($("#spanfield").html();
Am I opening any holes this method? Obviously the server also properly encodes stuff prior to database entry.
Assuming your server is properly detecting and dealing with XSS attempts, there's no way a malicious user could submit an attack for another user. Unless someone wants to hack themselves(?), it seems secure to me.
I find this approach pretty unsavory. I guess the overall soundness of this scheme depends on what fields you're actually populating this way --
For example, if you store fields that are supposed to be set only once (at the time of record creation) and never changed, this will allow a (malicious) user to change the field values mid-stream by editing a hidden field before posting (very easy to do, for example, with Firebug).
There's no difference here than if you were providing visible input fields and having that form submitted. Simply shuffling the data into hidden fields vs. visible ones would not make a difference.