No announcement yet.
  • Filter
  • Time
Clear All
new posts

    12.1p Questions on Escaping HTML Tags


    A ListGrid in our application was having display issues recently. This was because “<table>” and other similar values are valid for this component in our application and were being interpreted as HTML tags. I found the escapeHTML property that provides a solution to the display issue, however I have a couple questions related to this.

    Does SmartClient have built in validation to prevent <script> tags from being evaluated if loaded in a ListGrid or submitted in a DynamicForm? In other words, must the escapeHTML property be set to true for all fields if we want to prevent <script> tags from being evaluated within grids or forms? I have done some testing in our application to see if this is the case but have not been able to execute any JavaScript using <script> tags in a ListGrid or DynamicForm. All I have been able to do is replicate and expand on the odd display behavior with <table> tags.

    Also, is there a simple way to set the escapeHTML property at the ListGrid or DataSource level so that it applies to all fields in that component? I have found a way to do it by looping through each field in a grid and using setFieldProperties in JavaScript, but I wanted to double check if that is the best approach.

    I apologize if this has been addressed in another forum post; I could not find one. Please let me know if any further information or clarification is needed. Thank you!

    SmartClient Version: v12.1p_2021-06-05/Pro Deployment (built 2021-06-05)

    For user-editable text fields, you can either set escapeHTML or add validators to disallow HTML-special characters.

    There's no DataSource-level setting for escaping because most fields aren't user-editable text - they are PK/FK fields, dates, various types of numbers, blobs, or text fields users can't edit directly. - so in a normal app you don't end up setting escapeHTML very often.

    If your app is a bit unusual - maybe there's a disproportionate number of user-edited text fields - the best way to minimize the amount of code is actually to declare a SimpleType, in which case you can capture both recurring validators (like validators that disallow HTML-special characters) or capture the escapeHTML property via SimpleType.fieldProperties.

    Finally, there's no problem with putting HTML tables into grid cells, we do it all the time. You might have had an unbalanced table, and inadvertently closed the surrounding cell, row, or table. Or, it might not be related to <table> per se: you might have put content into the cell that exceeds your configured cellHeight thus swelling the row unless you enable vertical clipping (see enforceVClipping).


      Thanks for the response! If we decide to use escapeHTML for more than just this grid, using a SimpleType definitely sounds like the way to go.

      Also, you are correct about putting HTML tables in grid cells. I believe the issue was specifically that we had <table> tags with no </table> closing tags in the data for several consecutive records. This gave it an odd nested open table appearance.