by mliaquat
18. December 2010 11:03
Example#01
HyperLink lnk = new HyperLink();
lnk.NavigateUrl = QueryStringEncrypt("~/
EditUser.aspx", "Id", 10);
Output lnk.NavigateUrl => /EditUser.aspx?gRtlKfTCOcs=
Example#02 <a href='<%# QueryStringEncrypt("~/EditUser.aspx", "Id", Eval("Id"))%>'>Edit User</a>
OutputHref => /EditUser.aspx?gRtlKfTCOcs=
Example For Decryptingint Id=Convert.ToInt32(QueryStringDecrypt("Id"));
#region Query String Encrypt / Decrypt
public string QueryStringEncrypt(string url, params object[] values)
{
if (values.Length % 2 != 0)
throw new Exception("Invalid Parameters");
string queryString = string.Empty;
for (int i = 0; i < values.Length; i += 2)
queryString += string.Format("{0}={1}&", values[0], values[1]);
if (!string.IsNullOrEmpty(queryString))
queryString = string.Format("?{0}", new SecurityManager().Encrypt(queryString.Substring(0, queryString.Length - 1)));
return ResolveUrl(url) + queryString;
}
public string QueryStringDecrypt(string paramName)
{
var queryString = ConversionHelper.ToList(new SecurityManager().Decrypt(Request.ServerVariables["QUERY_STRING"]), '&');
return (from l in queryString
where l.StartsWith(paramName + "=")
select l.Substring(l.IndexOf("=") + 1)).FirstOrDefault();
}
#endregion
by smakazmi
9. October 2010 01:46
Recently in the workplace I got into a little fun argument regarding whether we should access 'Session State' in the business layer or not. I said we should because it makes life easier. The other guy said it was a bad practice to do so. Going against a best practice ???!!! What was I thinking. Let me tell you just that. First lets put the argument in context.
The pros and cons of dragging your session in your BLL are basically as follows:
Pros:
It makes your life easier
Cons:
It makes unit testing a pain
It can't work if your BLL is hosted as a separate tier
The cons don't apply as the application under discussion is a web application that has the BLL tied to it as a direct reference. Its not a separate web service. Secondly we don't unit test our code and we don't intend on starting anytime soon. Unit testing IS a best practice but we at our company don't use it because we made an informed decision that its an overhead for us and we can do without it.
Best practice is whats best in most cases NOT all. That's where your brain should kick in.
I feel that we are forgetting that (good) programming is a creative process. Its not done based on an algorithm. You have to think pragmatically about the current best practices and if they apply to your situation. We've to make informed decisions not based on gut feeling or blindly accept a best practice.
There are no holy commandments in software development. That is what makes it exciting and we should not take the fun out of it by blindly following best practices.
by smakazmi
8. October 2010 04:12
A recent project I worked on needed to record audio from the microphone of the user and store them on server. I should mention that this was a web project and since plain vanilla HTML and JavaScript can’t handle this sort of thing it was time to do something radical. Well it was radical enough for us. See we are mainly a .NET based software house. Since .NET provides us with so much baked in functionality, we rarely face a need to go out of the .NET ecosystem. In this case however we decided to step out. We couldn’t find a practical solution to implement this use case within .NET. Silverlight 3, the current version of Microsoft’s RIA platform currently doesn’t provide webcam/mic access. Silverlight 4 has it but its final version hasn’t come out yet and even if it did have webcam/mic support we still had to consider the market penetration aspect of it.
Thus we decided to use Flash but as is widely known that Flash isn’t exactly developer friendly. To remedy this, the nice folks at Adobe provide us with something called Adobe Flex. The great thing about Flex is that it boasts an event driven programming model that most developers nowadays are used to and it runs on the existing Flash Player that has an enormous user base already.
So we decided to use Flex to get the job done. It should have been an easy task to do. Why do I say should have? Because in the end it wasn’t. I was done with the POC in a day. It worked GREAT. It recorded my voice and streamed it to Flash Media Server which then saved it on the server. All was well until we tested it on other machines. We faced a classic problem of ‘It works on my machine’. It worked fine on my dev machine but not on other machines. We tested and tweaked the code like crazy which we know now didn’t matter.
The problem we discovered eventually was that the code refused to run properly on Dell Desktop PCs. It worked fine on unbranded machines, laptops and even Dell laptops but it specifically didn’t want to run on a Dell desktop machine. Apparently an event didn’t fire when the code was running on a Dell machine. But we still don’t know why? When all else failed and we couldn’t Google anymore we resorted to a hack. Instead of listening for the event we decided to use a recurring timer.
In the end we had spent a total of FIVE man-days just on this issue. Implementing the workaround took only half an hour of that time. Sounds cheap right? But it’s what we had to do. Moral of the story is that sometimes you have to settle for a cheap hack to get things working. Being a Software Developer we should know when to compromise because in the end what matters to us and the client is that we got it working. Meanwhile I hope that the enormously talented folks over at Adobe can fix this issue and we can get rid of this workaround.
Subscribe