Hello, all.
I have a perplexing question regarding the RadDock's state properties and JSON. I'm building an application that has a custom dashboard that will allow the users to add, remove, move, and expand/collapse various .ascx controls; this string will be stored in a SQL database. As it stands right now, everything works the way it should with no issues.
Since there will be a large amount of users using the application, it was decided that we don't need to physically store every dock state property for all the docks since there are quite a few that can't be changed from a user perspective (docks will never be pinned or resized; the top and left will always be 0, etc.) so we created another table that holds the properties that are changeable (zone, title, etc.). I changed the SaveDockLayout's handler to save into both tables until I get this new method working and tested. One table is storing the whole string as per the Telerik demos, the other is taking only the state properties we're saving and inserting/updating/deleting from the database as needed. So far, this has worked perfectly.
Since we're not storing the whole string as one database field anymore, we're creating a JSON string on the fly in a stored procedure that's loading from the new table. The values that don't change are hard-coded into the procedure; the others are selected from the database per our criteria. The results are then output to a JSON-formatted string and then looped through and split as per the code examples. Docks loaded this way have all the states from the JSON string applied correctly and they render fine.
Here's the hitch. When the SaveDockLayout event fires when the docks have been loaded with the generated string instead of the stored one, the table that's storing the whole dock state is updating the properties just fine, yet the part of the subroutine that's breaking apart the states doesn't seem to recognize that anything has changed. For example, if I move a dock from zone 1 to zone 3, the whole dock state is updated correctly in the old table, yet the property going into the new table will still show zone 1. The same results occur if the title is changed, if the dock is expanded or closed, etc.
So my question is, is there a fundamental difference between storing the whole state string vs. generating one? I've done a side-by-side comparison of the JSON output of my generated string to the text of the stored string and there's no noticeable difference. Both strings are created as NVARCHAR(MAX). All the properties are paired correctly and in the same order. Each dock is surrounded by opening and closing braces, the docks are separated by a pipe delimiter, each name/value pair has quotes around each part with a colon in between the name and value, plus there's a comma separating each pair. Is there something else I'm missing that would cause the properties to be updated correctly for one procedure but not the other?
I have a perplexing question regarding the RadDock's state properties and JSON. I'm building an application that has a custom dashboard that will allow the users to add, remove, move, and expand/collapse various .ascx controls; this string will be stored in a SQL database. As it stands right now, everything works the way it should with no issues.
Since there will be a large amount of users using the application, it was decided that we don't need to physically store every dock state property for all the docks since there are quite a few that can't be changed from a user perspective (docks will never be pinned or resized; the top and left will always be 0, etc.) so we created another table that holds the properties that are changeable (zone, title, etc.). I changed the SaveDockLayout's handler to save into both tables until I get this new method working and tested. One table is storing the whole string as per the Telerik demos, the other is taking only the state properties we're saving and inserting/updating/deleting from the database as needed. So far, this has worked perfectly.
Since we're not storing the whole string as one database field anymore, we're creating a JSON string on the fly in a stored procedure that's loading from the new table. The values that don't change are hard-coded into the procedure; the others are selected from the database per our criteria. The results are then output to a JSON-formatted string and then looped through and split as per the code examples. Docks loaded this way have all the states from the JSON string applied correctly and they render fine.
Here's the hitch. When the SaveDockLayout event fires when the docks have been loaded with the generated string instead of the stored one, the table that's storing the whole dock state is updating the properties just fine, yet the part of the subroutine that's breaking apart the states doesn't seem to recognize that anything has changed. For example, if I move a dock from zone 1 to zone 3, the whole dock state is updated correctly in the old table, yet the property going into the new table will still show zone 1. The same results occur if the title is changed, if the dock is expanded or closed, etc.
So my question is, is there a fundamental difference between storing the whole state string vs. generating one? I've done a side-by-side comparison of the JSON output of my generated string to the text of the stored string and there's no noticeable difference. Both strings are created as NVARCHAR(MAX). All the properties are paired correctly and in the same order. Each dock is surrounded by opening and closing braces, the docks are separated by a pipe delimiter, each name/value pair has quotes around each part with a colon in between the name and value, plus there's a comma separating each pair. Is there something else I'm missing that would cause the properties to be updated correctly for one procedure but not the other?
1 Answer, 1 is accepted
0
Hello Jeff,
If you are using the same format for the dock state as the generated one, you should not encounter any problems. Since you are storing the dock state in separate tables, you need to ensure that all data is combined before recreating the docks on Page_Init. Also, when the state is retrieved on the SaveDockLayout event of RadDockLayout, you need to remove the information about your static docks from the full dock state and then store it in your database. I would suggest comparing the state data from the dynamic docks with the state data from a page that does not include static docks. This way you can check if you are saving the correct data for the dynamic docks.
This help article contains useful information about dynamically created RadDocks. It could help you resolve the problem with storing the correct dock state.
I am afraid that the provided information is not enough to determine what the exact problem is. If you are still having difficulties, please, provide a fully working project and step by step instructions for replicating the problem.
Kind regards,
Slav
the Telerik team
If you are using the same format for the dock state as the generated one, you should not encounter any problems. Since you are storing the dock state in separate tables, you need to ensure that all data is combined before recreating the docks on Page_Init. Also, when the state is retrieved on the SaveDockLayout event of RadDockLayout, you need to remove the information about your static docks from the full dock state and then store it in your database. I would suggest comparing the state data from the dynamic docks with the state data from a page that does not include static docks. This way you can check if you are saving the correct data for the dynamic docks.
This help article contains useful information about dynamically created RadDocks. It could help you resolve the problem with storing the correct dock state.
I am afraid that the provided information is not enough to determine what the exact problem is. If you are still having difficulties, please, provide a fully working project and step by step instructions for replicating the problem.
Kind regards,
Slav
the Telerik team
If you want to get updates on new releases, tips and tricks and sneak peeks at our product labs directly from the developers working on the RadControls for ASP.NET AJAX, subscribe to their blog feed now.