OL Learn

Dynamic rows in table

I’m creating a dynamic table by scripts. Table looks like this

<table>
   <tr id="lastpaymentInfo">
        <td colspan="2">This is your Last Payments</td>
   </tr>
   <tr  id="lastpaymentsRowToRepeat"> 
      <td>@lastpaymentDate</td>
      <td>@lastpaymentAmt</td>
   </tr>
   <tr id="currentpaymentInfo">
        <td colspan="2">This is your current Payments</td>
   </tr>
   <tr  id="currentpaymentsRowToRepeat"> 
      <td>@currentpaymentDate</td>
      <td>@currentpaymentAmt</td>
   </tr>
   <tr id="futurepaymentInfo">
        <td colspan="2">This should be your future Payments</td>
   </tr>
   <tr  id="futurepaymentsRowToRepeat"> 
      <td>@futurepaymentDate</td>
      <td>@futurepaymentAmt</td>
   </tr>
</table>

I have a script (see below) to dynamically add by cloning the tr and append to table. Sometimes the designer seemed rearranging the rows and it does not follow the same order when it was added. (eg. currentPayments rows sometimes displayed on the top) I have checked the html source and also the data-breakable attribute is no longer in same order

How I can stop the Designer to stop scrambling the rows but follows the same order when it was added?

Thanks
Romeo

script
var myTemplate = results.clone();
myTemplate.attr(“id”,“paymentDetail_0”);

var paymentLength = record.tables.payments.length;
var paymentTable = record.tables.payments;

var allIndex = 0;
var myRow;	
var foundOne = false;

myRow = query("#lastpaymentInfo");
if (lastPayment == true) {				// see control script global variable

	allIndex++;
	myRow.attr("data-breakable",allIndex);

	myRow = query("#lastpaymentsRowToRepeat");

	foundOne = false;
	for(rowIndex = 0; rowIndex < paymentLength; rowIndex++)	{		

		myRow.after(query("#lastPaymentsRowsToRepeat",myTemplate).clone());
		myRow = query("#lastPaymentRowToRepeat");
		}

		if (paymentTable[rowIndex].fields["paymentType"].toLowerCase().trim() == "last payment" && foundOne == true ) {
			if (foundOne == false)  foundOne = true;	// flag to add new cloned row for next record
			
			allIndex++;			
					
		    myRow.find("@lastpaymentDate@").text(paymentTable[rowIndex].fields["periodDate"]));
			myRow.find("@lastpaymentAmt@").text(paymentTable[rowIndex].fields["paymentAmt"]));
			myRow.attr("data-breakable",allIndex);
				
			//Make sure that the row doesn't have an id to conflict with the one that will be created by the clone
			myRow.removeAttr("id");				
		}
	} 
} else {
	
	myRow.remove();
	myRow = query("#lastPaymentRowToRepeat");
	myRow.remove();
}

myRow = query("#currentpaymentInfo");
if (currentPayment == true) {				// see control script global variable

	allIndex++;
	myRow.attr("data-breakable",allIndex);

	myRow = query("#currentpaymentsRowToRepeat");

	foundOne = false;
	for(rowIndex = 0; rowIndex < paymentLength; rowIndex++)	{		

		myRow.after(query("#currentPaymentsRowsToRepeat",myTemplate).clone());
		myRow = query("#currentPaymentRowToRepeat");
		}

		if (paymentTable[rowIndex].fields["paymentType"].toLowerCase().trim() == "current payment" && foundOne == true ) {
			if (foundOne == false)  foundOne = true;	// flag to add new cloned row for next record
			
			allIndex++;			
					
		    myRow.find("@currenttpaymentDate@").text(paymentTable[rowIndex].fields["periodDate"]));
			myRow.find("@currentpaymentAmt@").text(paymentTable[rowIndex].fields["paymentAmt"]));
			myRow.attr("data-breakable",allIndex);
				
			//Make sure that the row doesn't have an id to conflict with the one that will be created by the clone
			myRow.removeAttr("id");				
		}
	} 
} else {
	
	myRow.remove();
	myRow = query("#currentPaymentRowToRepeat");
	myRow.remove();
}

myRow = query("#futurepaymentInfo");
if (futurePayment == true) {				// see control script global variable

	allIndex++;
	myRow.attr("data-breakable",allIndex);

	myRow = query("#futurepaymentsRowToRepeat");

	foundOne = false;
	for(rowIndex = 0; rowIndex < paymentLength; rowIndex++)	{		

		myRow.after(query("#futurePaymentsRowsToRepeat",myTemplate).clone());
		myRow = query("#futurePaymentRowToRepeat");
		}

		if (paymentTable[rowIndex].fields["paymentType"].toLowerCase().trim() == "future payment" && foundOne == true ) {
			if (foundOne == false)  foundOne = true;	// flag to add new cloned row for next record
			
			allIndex++;			
					
		    myRow.find("@currenttpaymentDate@").text(paymentTable[rowIndex].fields["periodDate"]));
			myRow.find("@currentpaymentAmt@").text(paymentTable[rowIndex].fields["paymentAmt"]));
			myRow.attr("data-breakable",allIndex);
				
			//Make sure that the row doesn't have an id to conflict with the one that will be created by the clone
			myRow.removeAttr("id");				
		}
	} 
} else {
	
	myRow.remove();
	myRow = query("#futurePaymentRowToRepeat");
	myRow.remove();
}

To help you properly we would need to see the Template and reproduce the issue. I suggest you open a technical support call at 1-866-348-5863 or through our website.

Hi hamelj,

This bug happens even if you use the GUI to add a detail table to your template. I have not updated to 2019.1, so not sure if it still persists in that version. However it does in 2018.2.1. How to replicate?

  1. Add data, create detail table in mapper.
  2. Add detail table to template. Settings default, ID = table1, class empty, Detail table = detail, width = 100%, Location, after element, p. Style = table grid, Allow resizing, Hide when empty.
  3. Remove the the header row that Connect adds to the table. i.e. Field1
  4. Preview table.
  5. Back in Design mode manually add a new row above the only remaining row, thus recreating your own header row.
  6. Now the trigger. Switch to preview/design a few times. Go to the mapper and add/remove fields.
  7. Once back in the template hit preview and the header row is now below your detail table field values.

After adding the detail table to the template for the first time the table looks like this:
Field1
@f2@

After triggering the bug the table looks like this in design/preview mode:
@f2@
Field1

Regards,
S

I am sorry…I try and I try and I can’t get to reproduce the behaviour you are describing…I do use PReS Connect 2019.1.

I guess you should either upgrade to 2019.1 or execute my previous post…open a technical support ticket.

Wait…

I just reproduce something similar…but for it to happens, overflow must be trigger (more than 1 pages).

I added a <TR> before and after the one that has the data-repeat. As long as there is no overflow, they stay in their proper position.

Soon as the overflow happens, they both get before the <TR> that has the data-repeat. Not exactly what you are describing but similar. That is a known behaviour. It is not fixed in 2019.1. A request has already been placed so the overflow mechanism keeps <TR> where we add them.

As for you exact behaviour…still open a ticket…we might be able to help you into getting the result you are expecting.

Hi hamelj,

I have had this issue for years. Support helped once when I had this issue and we got it resolved. However I do not remember the solution since that was also a few years ago. My current workaround is to not remove and recreate the header row that Connect creates by default and rather just edit the column names. What I did, in my first post in this thread, is create a new mapper and template just to prove it was reproducible in Connect 2018.2.1.

Regards,
S