I had difficulties making HttpRequests/Response handling in Silverlight since it most of the events are asynchronous by nature. It all rooted on a task that involves data to be exported on CSV format. This is really easy (first approach) as I only have to format it accordingly using commas, but unfortunately this was not the case. SaveFileDialog must be invoked on a UI thread, meaning constructing it on non-UI event handlers will throw an exception (must be User invoked), which makes sense since we're dealing with client side here and placing files on a client side without the user's conscent is like planting something wicked on their machine.
With this, I have decided to just have Silverlight post to a server then store those data on the context of Application's Cache. With this, I don't need to worry about getting the stream and deal with the security. So, I did a quick handler hack. At first, I made a synchronous one. After I got it working, I considered a concurrent user request performance and converted it to asynchronous. I noticed slight difference here. The file received from a synchronous handler indicates the complete size of the file, while asynchronous handler don't. It doesn't affect how the request is handled, meaning if your usual query for a resource took 5 seconds, asynchronous handler can't change that. The performance benefit takes place when multiple users performs the same query. Since it doesn't have to wait for the handle to process the request and instead start on a new thread, it offers better performance.
But, I have to write HttpRequest, then another HttpRequest after the asynchronous callback fires, where I can write POST datas, then submit it again and take the response back. It was really different on what I used to do in web, but somehow I starting to find a bit of liking to it.
Things that I found useful:
Dispatcher.BeginInvoke();// Use anonymous method to invoke or set properties
getting my hands dirty on Silverlight 4
I was too busy doing silverlight 4 related works that I'm unable to blog here. And since it was a client-side application, I don't have to worry much about the control states , unlike web development , but still I prefer doing web development since I'll have some time reading those MCTS learning kit while doing some quality deliverables of work.
Anyway, I'm able to familiarize myself that controls without actual click or selectedindexchanged events are only solid on their borders. Filtering datas from DomainDataSource is quite a pain, since nested filters doesn't work with DDS... unless one can bear with a ContainedIn method with non-accurate result and the asynchronous way of loading data, I missed Dataset based manipulation, although it seems that Microsoft believed that DomainDataSource is the right direction and Datasets are history.
Another thing that gave me sleepless nights are the the SaveFileDialog objects. These things protect client side things that sometimes they are a pain to deal with. For example, if I have an asynchronous data from DB or from a Service call, and I need to save the result of the query or service call somewhere in the client PC. Showing the SaveFileDialog in non-UI related events (like button click, selected index changed, etc) will throw an exception that "Dialog must be user initiated".
I understand that Silverlight was a client-side application and if SFD won't do it like this, client PC are at big risk to malicious things, but because of this restriction, it is hard or maybe impossible to keep the saving and loading of data in sync, even with sleeping threads, on assumption that it runs on different thread..
I hope they made some fix for those issues in SL 5.0
Anyway, I'm able to familiarize myself that controls without actual click or selectedindexchanged events are only solid on their borders. Filtering datas from DomainDataSource is quite a pain, since nested filters doesn't work with DDS... unless one can bear with a ContainedIn method with non-accurate result and the asynchronous way of loading data, I missed Dataset based manipulation, although it seems that Microsoft believed that DomainDataSource is the right direction and Datasets are history.
Another thing that gave me sleepless nights are the the SaveFileDialog objects. These things protect client side things that sometimes they are a pain to deal with. For example, if I have an asynchronous data from DB or from a Service call, and I need to save the result of the query or service call somewhere in the client PC. Showing the SaveFileDialog in non-UI related events (like button click, selected index changed, etc) will throw an exception that "Dialog must be user initiated".
I understand that Silverlight was a client-side application and if SFD won't do it like this, client PC are at big risk to malicious things, but because of this restriction, it is hard or maybe impossible to keep the saving and loading of data in sync, even with sleeping threads, on assumption that it runs on different thread..
I hope they made some fix for those issues in SL 5.0
Substring function in XSLT
And they just didn't make it something like javascript... I'm never expected that XSLT has function like this, and it just helped me in one of my XML/XSL parsing task.
substring("ABCDEFG",3,3) will display CDE since XSLT doesn't refer the first element on 0 index.
Actually, I really disliked the way XSLT do in loops. you can't overwrite variables, and for-looping and performing something on a node-specific basis is really painful, you have to do it the HARD way, which makes your coding experience a bit dirty, especially if you are already attached to the OOP way of doing things...
XSLT was never meant to be a programming language anyway.. .
substring("ABCDEFG",3,3) will display CDE since XSLT doesn't refer the first element on 0 index.
Actually, I really disliked the way XSLT do in loops. you can't overwrite variables, and for-looping and performing something on a node-specific basis is really painful, you have to do it the HARD way, which makes your coding experience a bit dirty, especially if you are already attached to the OOP way of doing things...
XSLT was never meant to be a programming language anyway.. .
Subscribe to:
Posts (Atom)
