Skip to main content

I’m looking to run batch APEX that parses my SKUID page XML for all of my SKUID pages and replaces certain object/variable names with other object/variable names (mass updating the skuid pages to convert from using one object to another object)


To do this I use APEX to query on each skuid__Page__c object and combine each skuid__Page__c object’s Layout fields into a single string for analysis / updating:


skuid__Layout__c


skuid__Layout2__c


skuid__Layout3__c


skuid__Layout4__c


skuid__Layout5__c


(note: SKUID stores the XML for their pages split between these 5 layout fields, each are 131072 character Long Text fields, and if the XML extends beyond 131071 characters it continues on to the next field to be stored … 655355 appears to be the limit for the number of characters in SKUID page XML)


When done updating my single unified string, I split the string up into 131071 character substrings and fill the Layout-Layout5 fields with them.


This seems to work great, except if one of these layout fields happens to start with a space character. If that happens, it looks as if SKUID has something that forces the layout field to be trimmed of leading spaces, and then when the XML is combined and opened by the SKUID editor it gives an invalid XML error. Testing the XML with an XML tester reveals the issue to be this trimmed space leaving XML that looks like this:


<skootable showexportbuttons="false"showsavecancel=“true”>


Where there should be a space after “false” this was trimmed on Layout5. Layout5 begins with showsavecancel. I tried even updating Layout5 to add the space in front and it was trimmed by SKUID when updated.


Why does SKUID trim the leading spaces here? Is there another way to go about this other than trying to force the string to not split at a point where there would be a space between Layout fields? Is there a better way to set these layout fields in APEX?


Thanks!

I’ve found a way to get around this, though it’s odd that I need to do it this way.


Instead of splitting at 131071 to save 131071 characters in each Layout field, if there is a space at position 131071 or 131072, I back up the split point until there is no space next to the split point. This means potentially less characters can fit into a SKUID page, but the difference is negligible and shouldn’t affect what I’m trying to do. The page seems to work with an intelligently moved back split point.


Hi @Mark_L, this is a really cool use case and I’m glad to hear you found a workaround. In order for us to investigate further, can you please provide an example of the Page XML where you’d get this error with the spaces? You can send it as a private message if you don’t want to post it publicly.


Hi Anna. Unfortunately I no longer have the particular modified page XML that was causing this to happen. There is some element of randomness involved trying to reproduce this due to needing to have XML that just so happens to split on a space character that when re-combined without that space causes invalid XML. I believe you can however try to update any SKUID page XML (using apex/soql) that has enough characters to split between the different layout fields (greater than 131071 characters) and update those layout fields with spaces to be trimmed, and then those spaces should be trimmed once the page is updated. I’m not sure how SKUID itself goes about getting around this when pages are saved and have their XML split between the layout fields with spaces; I’d imagine there is some sort of a mechanism SKUID uses to prevent saving with spaces between the fields because I haven’t seen this happen outside of trying to modify the XML of the Page object directly using SOQL / apex.


Reply