H T M L Structure

The web interface - HTML structure

This page describes how PS’s HTML is structured. It mainly describes which JS functions are bound to which events.

HTML step divisions

PS’s HTML is divided into a bunch of steps - each of them corresponds to a div element in HTML. Across all steps a static structure is maintained with a header having ProteoSigns logo and a help link and a footer with our publication link and some useful links such as contact feedback etc. The various steps are represented with different divs such as this:

<div class="main_div main_section" id="s1div">
	<p><strong>ProteoSign</strong> is an online service for protein <strong>differential expression (or abundance) analysis</strong> designed with the end-proteomics user in mind.</p>
	<p>Borrowing from the experience of the microarray field, ProteoSign software utilizes the well-established <a href="http://bioinf.wehi.edu.au/limma/" target="_blank"><strong>Linear Models For Microarray Data (LIMMA)</strong></a> methodology for assessing statistical significance in protein abundance differences between two or more proteome states.</p>
	<p>ProteoSign aims to fully automate the process of statistically evaluating differential expression in mass spectrometry-based bottom-up (shotgun) quantitative proteomics data by requiring <strong>minimal user interaction time</strong> and generating <strong>publication-quality data plots.</strong></p>
	<br><hr class="style-one"><br>
	<p style="color: #000000">Click <em>Start</em> to begin your analysis.</p>
	<br><br><br><br><br><br>
	<p style="color: #000000; font-size: 90%; text-align: right">We recently added <strong>new features</strong> to ProteoSign!<br>Click <a href='change_log.html' target='_blank'><u>here</u></a> to see what's new!</p>
	<div class="buttonbar">
		<button type="button" class="main" id="s1btnf">Start</button>
	</div>
</div>

that have a special id such as “s1div”. These divs are:

  • s1div: Initial description: a description of proteosign and a start button simply to proceed to the next step
  • s2div: Step 1: an “upload files” (s2btnupld) button linked to a hidden upload button (__s2btnupld) used to upload the necessary files. When the filename property of __s2btnupld changes, the uploadButtonStatusChanged(this.files); routine is executed to upload all necessary files to the server, check that they are valid, automatically define the experiment type (Labelled, isobariclabelling, or Label Free (LFQ)) and the processing program (PD or MQ) and fetch all rawfiles - MS runs the files derived from and the labels - tagged used (if any). There is also a “choose” link that executes onChooseFromTestDatasets() routine to load a test dataset and its parameters and move on to Step 2
  • s22div: Step 2: this is divided in two parts. The left one is an interactive table from jquery.dataTables that is used to select - display - filter or sort rawfiles in order to assign biological and technical numbers (coordinates) and - in LFQ datasets - conditions. The table is rawfiles_tbl_allfiles and is initialized through PS’s JavaScript ProteoSignInit routine. In the right part we have the experimental structure coordinate div that contains expstructcoord_biorep and expstructcoord_techrep text boxes used to assign bio and tech reps to the selected rawfiles by hitting the assign button which calls assignExpStructCoord(). Every time any changes are made to the raw files data table, PS checks whether there is enough and valid data to proceed to Step 3 using the set_s22btnf js function. In case the user opted for Replication Multiplexing (RM), the datatable is replaced with step2RMuseinfo, an info banner with links that: cancel replication multiplexing (onRMUndo_click) or let the user review the RM parameters (onRMreview_click). Steo 2 uses a lot of dialog boxes that will be explained below.
  • s3div: Step 3: Step 3 has a label quantitation_prog_lbl that is automatically updated depending in the processing program, telling the user if MQ or PD was used to process the data. A table of text boxes expid and exptpoint are used to get eperiment description and ID. A very important list box is conditions_list. conditions_list contains all conditions that can be compared in our experiment. In case the experiment is a labelled or isobarically labeled one the list is populated automatically with the respective tags or labels. In LFQ datasets, the user manually defines the conditions of their experiment - the same happens if the PS is in RM mode. conditions_list's selected conditions are all compared to each other and can be altered by right clicking on them and merging some of them into one. The context menu of this procedure is initialized in conditionsMergeCMenuInit executed during PS initialization and the dialog box used to merge the conditions is described below. adv_parameters_div is a container that has all advance parameteres inside. Links in this container can be used to set Quantitation filtering for pSILAC experiments, assign label swaps using the dedicated dialog box and miscellaneous parameters using another dialog box. As for Quantitation filtering, the user can check the respective checkboxes and choose the singlet label. When they hit the Submit button, postParameters routine automatically loads all the check status of the check boxes and the singlet label chosen and sends them as parameters to the server (specificcaly to upload_parameters.php script). As for the rest of the options, the dialog boxes are used to alter global JS variables and they are read and sent to upload_parameters.php from postParameters.
  • s4div: Step 4 is broken in two parts. While the analysis is in progress, the top one results_p prompts the user to wait for the results and the bootom one server_feedback displays some RSS elements - by default interesting publications concerning big data. When the analysis is completed, the prompt is changed to “Now you can inspect your results…” and server_feedback displays the main plots for all comparisons. The container is populated by postFireUpAnalysisAndWait JS routine that executes perform_analysis.php server sided. If it is completed successfully the .done respective routine is executed and all image paths contained in data.results_preview array are appended to server_feedback. In case of failure a descriptive message is displayed.
  • s5div: End - the last div cotains a download link for the zipped result folder. The step divs that were just described are all invisible except one all the time. The next and back buttons are responsible to ensure that only one is visible at a moment. This is done by the script below executed in ProteoSignInit
	var forward_buttons = getItems("button.main", /s[0-9]+btnf/);
	var backward_buttons = getItems("button.main", /s[0-9]+btnb/);

	// Bind the click event to "toggleNextClass" for each "next button"
	forward_buttons.forEach(function (btn) {
		$(btn).on("click", function () {
		
		// idsToStrings(".main_div .main_section") returns an array of all items having main_div or main_section as classnames
		// this matches all divisions in html corresponding to different steps of the process (s1div, s2div etc.)
		// in order of appeareance in HTML source
		// toggleNextClass hides the currently displayed division and shows the next one in order
		toggleNextClass(idsToStrings(".main_div .main_section"), "hidden", true, executeStage);
		
		if ($(backward_buttons[0]).hasClass("hidden")) {
            $(backward_buttons[0]).removeClass("hidden");
        }
		// Always redraw the data tables after displaying or hiding a step
		rawfiles_tbl_allfiles_DT.columns.adjust().draw();
		});
	});


	// Binds the click event to "toggleNextClass" for each "backward button" - for more info see forward_buttons.forEach above
	// In two cases pressing the back key (Step 2 and step 4) fires the "Careful Back" function to
	// prompt the user that they may lose changes if proceding
	backward_buttons.forEach(function (btn) {
	   if ($(btn).attr("id") == "s22btnb")
	   {
		   $(btn).on("click", function () {
			   carefulBackStep = 2;
			   CarefulBack();
		   });
	   }
	   else if($(btn).attr("id") == "s4btnb")
	   {
		   $(btn).on("click", function () {
			   carefulBackStep = 4;
			   CarefulBack();
		   });
	   }
	   else
	   {
		  $(btn).on("click", function () {
			 toggleNextClass(idsToStrings(".main_div .main_section").reverse(), "hidden", true, rollbackStage);
			 rawfiles_tbl_allfiles_DT.columns.adjust().draw();
		  });
	   }
	});

Notice that some of the back buttons are also bound to CarefulBack using the script above. CarefulBack is a routine that prevents losing data when hitting the back button and prompts the user to cancel the back procedure in case they are not sure for their action. see CarefulBack() in script.js for more info.

HTML dialog boxes

A dialog box in PS is opened using 4 commands as seen here:

	$(".expparamsDlg").css({"left" : ($("body").width()/2) - ($("#s2LFQConditions").width()/2)});
	$('body').append('<div id="mask"></div>');
	$("#s2LFQConditions").fadeIn(300);
	$('#mask').fadeIn(300);

these lines allign the dialog box, show it and append and display a mask exactly below the dialog box to prevent any interaction with the rest of the DOM elements. The mask id is automatically styled to be semi-opaque from style.css and its z-index ensures that it is on top of the elements but below the dialog box. Altering the id of the dialog box (#s2LFQConditions in this example) shows a different dialog box. All boxes can be closed using the command dlgFadeout() although the feedback dialog box closes with dlgFadeoutFeedback() and the message boxes with dlgFadeoutInfo(). The following dialog boxes are used to help the user interact with PS:

  • s1TestDatasets: shows the test datasets as fetched from testdatadb in a list. The OK button is bound to datasetDialogOK() that executes postTestDatasetInfo([selected_dataset]) which copies the test dataset locally on the server to the current session’s working directory and loads all its experimental parameters from testdatadb. The download button is attached to datasetDialogDownload that executes downloadTestDataset which calls download_test_data.php returning a File Transfer response to download a zipped file directly from the server
  • s2LFQConditions: this dialog is used to provide LFQ conditions to the selected rawfiles in Step 2 and is accessed by right clicking on the datatable and clicking on Assign condition. It contains to basic elements a text box and a list that is populated with all already assigned conditions. Clicking the OK button fires the ons2LFQConditionsOK_click routine that assigns the condition in the text box to the selected rawfiles or if the box is empty the selected condition in the list
  • s4UserInfo: an info dialog box with a simple div element(s4UserInfoText) to display simple HTML formatted text to the user. It is mainly used to display descriptive errors that have been returned from the R script.
  • condsadvancedDlg: a dialog box opened when the user chooses to merge 2 or more conditions. To open the box select 2 or more conditions in the conditions list in Step 3 and select Same Condition. The dialog has a text box where the condition name is typed and an OK button bound to an anonymous function under conditionsMergeCMenuInit ($("#s3AdvancedOK").on("click", function () {...}) that refreshes a global array and executes Refresh_conds_list() to display the right conditions in the conditions list
  • divLabelSwap: an array used to assign label swaps. This dialog contains two main lists that are populated with the biological nd technical replicates (LSbrep and LStrep respectively). When their value is changed onLSrepchange is executed that loads all rawfiles that are assigned to a specific brep-trep pair and populate a list (LSRawFilesList) with them. Two other list that contain all conditions are displayed (LSfirstlabel and LSsecondlabel). The user can choose two (different) conditions to define they are swapped in the previously chosen replicate. Clicking the add button fires the bound onLSAddclick function that refreshes the 2 global arrays linked to Label Swap (LabelSwapArray and LS_counters_per_Add). After completing the procedure, LSLabelSwaps list is filled with a comprehensive description of this Label Swap. The remove button is bound to onLSRemoveclick that removes the selected label swap from the label swap list by altering the 2 aforementioned arrays. It also refreshes LSLabelSwaps in the end.
  • divAdvancedOptions lets the user choose the p-value cut off and when to disqualify a protein according to how many peptides were used to quantify the protein and in how many replicates it was found. For this to happen the user can change the values of two lists (AdvParamLPep and AdvParamLBRep) that are automatically populated with 1-10 and 1-max_biorep_number and a text box with the new p value cut off (PThreshold). Hitting the Ok button fires the onADVoptionsOK_click function that changes 3 global variables in JS (Pthreshold, LeastPep and LeastBRep). These variables will be read when uploading the parameters to the server.
  • s4FeedbackPanel: a dialog box to provide feedback to PS. Its OK button fires onFeedbackPanelSendclick that uses send_feedback.php script to provide the server with the feedback and save it to a server file (Feedbacks.txt).
  • WarnCarefulBack: a dialog shown when the user tries to go back a step but there is a possibility to lose data. Called in some “Back” button clicks (as shown above) it allow the user to perform the back operation if they hit the Yes button.
  • ReplicationMultiplexingDialog: this is one of the most complicated dialog boxes and is used to perform RM operations. RM procedure is divided to 3 steps (RM1 RM2 and RM3) in order to define an experimental structure of an RM based experiment. There are 2 containers though: stepRM1, stepRM2. stepRM2 is responsible for both RM2 and RM3 steps. In RM1 the user defines how their data are represented. This happens using 3 pairs of radio buttons. For example, to choose how the biological replicates are represented we have the pair of RMbreprepresrf and RMbreprepresrtag. Hitting the next button in RM1 fires the onRMDialogNext_click routine that hides RM1, initializes and shows RM2. The stepRM2 dialog contains a data table (RMrawfilestbl) similar to the one in Step 2, filled with all the raw files of the experiment. The columns though are dynamically defined based on the options in RM1. showstepRMDialog is responsible to set the visibility of the columns of the data table. stepRM2 also contains some text boxes (stepRM2txtbrep, stepRM2txttrep, stepRM2txtcondition) that are used to assign tech reps, bioreps and conditions to the raw files. According to the options in RM1 some of these are visible and some not - something controlled from showstepRMDialog as well. The assign button fires the stepRM2Assign_click routine that refreshes a global variable (RMrawfilesdata) and the datatable RMrawfilestbl. Hitting the next button to advance to RM3 simply executes showstepRMDialog again to redefine the displayed columns in RMrawfilestbl and populate it with the tags of the experiment. Also it alters which of the aforementioned text boxes are visible. The same tools can be used to assign attributes to different tags. The assign button now controls another global variable (RMtagsdata). Hitting the next button now executes showstepRMDialog for the last time that completes the process and closes the dialog box. There are always many validity tests before advancing to a next RM step or completing the procedure. More information about exactly how JS controls the RM related information is given in the JS section.
  • VariousInfoDialog: a dialog box to display simple messages, mainly shown by the msgbox routine
  • QuestionBoxDialog: a question dialog box, it is called by var questionbox = function(caption, postYes, postNo) {...} routine that takes as arguments the dialogs captions and two functions that are executed if the yes or no button are pressed respectively