Entries Tagged '.NET' ↓
August 29th, 2007 — .NET, Code, Work
When you write a Server Control and write it well, it pays off immensely. Today, I needed to rework our Custom Defaults screen (a screen that allows each user to define defaults for our quoting screens to use each time they write a new quote). All of the fields on the Custom Defaults screen exist in the quote (duh, why would we provide something that didn’t?
).
Since everything in the quote is a server control, it was just drag and drop the controls onto the Custom Default page and it would act 100% like it does in the quote.
It could not have gone any faster, I probably only spent close to 5 minutes setting up the design and flow and 30 minutes getting the code behind functionality to work.
Thus, harness the power of Server Controls as they can be reused across numerous applications with little trouble and little programming.
August 20th, 2007 — .NET, Code, Work
Today, Aaron and I were wondering if ViewState actually works properly in .NET. For example, in .NET you have the option to disable ViewState in the web.config file, the page directive, or on each control individually. However, using any of the three methods or any combination continuously results in “__VIEWSTATE” appearing as a hidden field in the form!
The problem gets worse when you try to submit the form to another page by overriding the form’s action. This throws an “ViewState is corrupt or invalid for this page.” error. We finally got around it by hacking a JavaScript event to empty the “__VIEWSTATE” hidden field so it had nothing in it before the form actually submitted the page. But is that the only way to get rid of ViewState?
Code to cause ViewState corruption:
<script type="text/javascript">
window.onload = function()
{
document.getElementById('Form1').onsubmit = function()
{
document.getElementById('Form1').action = '/another_project/another_page.aspx';
}
}
</script>
How, we got around it:
<script type="text/javascript">
window.onload = function()
{
document.getElementById('Form1').onsubmit = function()
{
var inputFields = document.getElementsByTagName('input');
for (var i = 0; i < inputFields.length; i++)
{
if (inputFields[i].name.toUpperCase() == "__VIEWSTATE")
{
inputFields[i].value = ""; // Empty the ViewState hidden field to stop it from carrying on to the next page
break;
}
}
document.getElementById('Form1').action = '/another_project/another_page.aspx';
}
}
</script>
Anyone else have a problem like this?
August 15th, 2007 — .NET, Ajax, Code, JavaScript, PHP, Rails, Ruby
Ever have to argue Ajax versus Socket Connections? Me either. Today, I had the chance to talk about the differences, their advantages and their disadvantages.
Ajax has many advantages. You do not have to parse content/page headers, you can parse XML, you can build objects out of JSON serializations, and above all there are a lot of frameworks that are cross-browser friendly so you do not have to worry about writing the framework yourself.
A Socket Connections’ advantages are much smaller in my opinion. There is no browser limitations, which is a major advantage, keeping it browser independent. It can support any type of response content, JSON serializations, XML, HTML, strings, etc.
So what about the disadvantages? Ajax has the complications of cross-browser friendliness, but that has been removed by frameworks doing all that hard work for us. Ajax’s biggest disadvantage is probably the lack of JavaScript standards being followed by each browser. Though this is removed by using popular frameworks, it matters for the rest of your JavaScript code to setup the Ajax event.
So how about Socket Connections? Socket Connection have the complication of trying to figure out where the response data starts and where the response headers end. Secondly, they are language dependent. Not all languages support sockets and some may make it very complicated to use them though, whereas, Ajax is getting easier and easier to use.
What are your thoughts?