Hi Pierre
Do you mean interact with Shared State generally or in the case you outlined?
If this is the case you outlined it is nothing to do with Shared State but with client side objects that represent the server-side controls and the way events are assigned to those objects. A simple example is when the ribbon is minimized, when you click a tab the ribbon pops-up but I need to know when you click away from the ribbon so I can hide it again. I do this by listening to events on the document object.
If you mean shared State generally, when you create a control (such as the ApplicationBar or RibbonButton) there is a server-side contol and a reduced fuctionality client-side version. The client-side version is written in JavaScript to allow you to do basic operations without doing a PostBack, an example may be setting minimized state of the application bar or the checked state of a button. In addition, some operation, such as the way hover effects work, can't be done simply with CSS, as there are 3 elements that need to change (left, centre, right) so the client object is a good way of allowing this to be implemented. When values change on the client and you do a PostBack the server would have no way of knowing that you made the change. SharedState is similar to ViewState except it allows you to change the values stored on the client via JavaScript. When you call setChecked() against a RibbonButton the checked state (true) is set against the Shared State. This is stored in a hidden field and when it arrives at the server the server can tell what was changed and 'synchronize' the values against the server control. Text boxes, and hidden fields (or controls derived from them) handle this sort of synchronization for you, but when you create your own controls you have to handle it yourself. If you have no client-side interaction then this too is not an issue. However, when you have controls that interact both on the client and server you need this type of mechanism. Telerik and other control providers use this type of mechanism in one way or another, I have just given it the name 'Shared State' and allow you to add it to controls if you so wish.
In the client-side JavaScript this is just held in an array and the get/set methods just access specific indexed items within the array. This makes it more intuitive and 'object' looking. What goes in SharedState is dictated by the server-side controls. You will notice that each control adds a set of items (the key can be used on the server to make it more readable) but again this is just a collection that can be easily written to a string than can be converted to the array when it gets to the client (the JavaScript eval methods does this for you). Shared State can be accessed and changed on the client but it cannot be created or added to.
The idea behind the client-side member is to automatically create an instance of the client-side object. You can use this simply in JavaScript by using the client member variable name, such as _myRibbonButton.setChecked(true); i.e. you do not have to create this yourself. This is not the 'norm', for example to use a client-side version of a Telerik RadTabStrip you would need to manually insert an bit of JavaScript such as
| <script type="text/javascript">var tabStrip = <%= RadTabStrip1.ClientID %>;</script> |
All I am doing is creating this for you, but more importantly it allows me to know what the client-side object will be called so that I can call methods against this object for hover effects etc.
Why do I do this differently than others? I like this idea, think it is simpler, and requires less code. More importantly they know what they are doing and I don't :-)
Hope that helps.
Thanks
Russell Mason