 |
|
 |
It does not work like Page.ResolveUrl would when the current page is in a subdirectory and you do not supply the subdirectory name in the call, for instance: lets assume we are currently on http://root/sub/page1.aspx and we then call:
string url = Page.ResolveUrl("page2.aspx");
then the url output would be "/sub/page2.aspx", however:
string url = WebUtil.ResolveUrl("page2.aspx");
would yield "/page2.aspx" which is understandable since it can not make the subdirectory determination from the string parameter alone.
One could argue that the developer should remember to include the subdirectory in the relativeUrl parameter when making the call, but I think for increased backwards compatibility with Page.ResolveUrl and peace of mind, that the method should at least try to figure out what the current subdirectory is in these cases when HttpContext.Current (and HttpContext.Current.Request) is available.
Robbie Couret
Senior Software Engineer
Big Easy Software, LLC
|
|
|
|
 |
|
 |
Nice approach. Well done.
|
|
|
|
 |
|
 |
Dude, you rocked my day!
|
|
|
|
 |
|
 |
Great tool to handle a specific set of issues. I'll ding you for the title "Perfect...?" but the article and code were great!
|
|
|
|
 |
|
 |
Thanks! Always happy to help!
What do you know maybe Microsoft will adopt my code in the next .Net version
-----
Daniel Cohen Gindi
danielgindi (at) gmail dot com
|
|
|
|
 |
|
 |
I stumbled on to this when I was changing a Response.Redirect to Server.Transfer call. There was no need for my code to take a trip to the browser to get to the page I wanted so I went from this
string req = ResolveUrl("~/MyPage.aspx");
Response.Redirect(req);
to this
string req = ResolveUrl("~/MyPage.aspx");
Server.Transfer(req);
and found out it didn't work too well (Boom!). You gave a great explanation of the situation and provided a well done tool to address some concerns.
Thank you.
|
|
|
|
 |
|
 |
It's always nice to know I helped another good person
-----
Daniel Cohen Gindi
danielgindi (at) gmail dot com
|
|
|
|
 |
|
 |
Take it from someone who eats, sleeps, and breathes ASP.NET; this is a wonderful solution, and I am most likely going to stick this in a helper class I use in virtually all of my projects. Thank you!
Adam Maras | Software Developer
Microsoft Certified Professional Developer
|
|
|
|
 |
|
 |
Thanks!
-----
Daniel Cohen Gindi
danielgindi (at) gmail dot com
|
|
|
|
 |
|
 |
I've run into the same problem, I like the solution, thanks!
I gave ya 4 for the code and 1 for this response to the other commenter who gave you the vote of 1:
"This is the most idiotic response I could ask for, thanks!"
I almost spit out my corn flakes after reading that response, hilarious.
|
|
|
|
 |
|
 |
Thanks bro!
Well I was right wasn't I?
-----
Daniel Cohen Gindi
danielgindi (at) gmail dot com
|
|
|
|
 |
|
 |
I think you are not fully utilizing the ASP.NET framework as it should. Rather than solving the propblem you hacked into the framework and tried to develop a solution.
Your solutions needs some more investigation not on creation of something new but correct utilization of what the framework offers.
But if you do continue to use it that is your choice, but I would recommend you add some functionality to include virtual paths, port and use the Current HttpContext and the Uri class as a start.
HttpContext includes a static member to get the Current Request where you get the URL (Uri) of current request, providing usefull information for building your url.
|
|
|
|
 |
|
 |
This is the most idiotic response I could ask for, thanks!
Sometimes there's no 'fully utilizing' .NET framework, because it does not provide what you need. Right now I'm implementing a red eye reduction algorithm, this is not a service that .NET could give me. So by implementing that I'm 'not utilizing .NET framework as it should'? Give me a break.
This is not "hacking" into .NET, this is using the available tools to create something better.
Tell me how would you use ResolveUrl of .NET when you have a QueryString in your url which includes "://"! There's no correct use of that, because it is buggy! Therefore you need to implement your own method.
The "Current Request" is available only if there is a Request. But if there is a routine called by a timer, or some other handler which works OUTSIDE the request, then using the Request won't do nothing for you.
Using the Uri class - that's just stupid. Uri class is for entirely other things, it won't do nothing for you to convert resolve urls. Besides it just does too much work for what we need.
My algorithm is much more efficient than that, and much more efficient than .NET's natural ResolveUrl, and it does not have the bugs that .NET has.
So please think before your next post.
-----
Daniel Cohen Gindi
danielgindi (at) gmail dot com
|
|
|
|
 |
|
 |
First, you did not ask for a response, this is a public site and it is expected.
Secondly, anyone that does not 'fully utilize' the .Net framework is doomed to implement poor solutions, and try to solve problems in the wrong area of their application.
Thirdly, what does a bug in the URLs you are sending to the server have to do with implmenting a red eye reduction algorithm, I think you need to provide a clearer sepration of conserns.
Fourthly, I would use ResolveURl of .Net as dictated by MSDN documentation and fix the bug in your query string generation.
The .Net framework if properly utilized by an experience Object Oriented Programer can do anything we need.
Finaly, I think you should think before you post an article entitled 'The perfect solution' you should have called it 'Alternative approach to my Bugs'.
|
|
|
|
 |
|
 |
You still just don't get it.
An experienced programmer will develop solutions for where there are problems. If .NET's ResolveUrl does not provide, then you should do it yourself. This is what I did.
MSDN or .NET are not the holy grail, they can be wrong, and they can be buggy. Microsoft have just released a patch for the whole VC++ Runtime, to recompile all software, because of a security bug. Which I've known about long ago, and made my own patches. So what are you saying, I should have just 'lived' with the bug and let it be?
My conclusion is - do whatever you like. You don't want to use my code, so don't. I did not force your hand. You have some strange ideas about .NET and about what a programmer should do or not do, those are your ideas. Thanks for sharing. But my experience is wide enough to make my own decisions, and I decided to write this code not for a reason.
Actually, I don't know why am I 'defending' myself at all. Just do what you like, use, do not use, program or not, respond or not, whatever.
-----
Daniel Cohen Gindi
danielgindi (at) gmail dot com
|
|
|
|
 |
|
 |
I absolutely cannot understand your responses.
Dot NET has some real bugs - try putting a drop down list on a web page and findout about the bugs it comes with - if there is a solution for those bugs built into the .NET framework show it.
You somehow are missing the point, and the real advantage of .NET ; DOT NET is a framework - it is customizeable so if you do not have what you need or if what is provided is insufficient - you can build on what is there. OOP, Reusability and Extensibility!
Why do you think all of these articles are on Code Project - declaring that people searched for this or that in DOT NET - there was not one , or the one provided did not have the functionality needed or had some defect prohibiting the use of such a control in a real world application and therefore they created their own.
Ever use the Calenday Control, or the drop down control .. pathetic.
Have you ever extended the functionality of what is in a .NET control - then I guess you went around to create your own poorly devised solution.
Your response shows that you do not understand OOP reusability and extensability.
Your comments to the Author were just plain uneducated.
While the site is public intelligible and educated comments are always preferred reading - yours were unhelpful to anyone.
|
|
|
|
 |
|
 |
I understand completely extensibility and re-usability. The author never reused, he hacked the framework using a reflection tool to solve an incorrect usage of something provided by the framework.
My comments to the author are educated and directed at an individuals attempts to solve a problem in a direction that I disagree with.
And I suppose your comments were helpful.
It just goes to show that everyone has two cents to share with everyone.
|
|
|
|
 |
|
 |
Hilarious!
1. The reflection tool may be called a 'hack', but it is a useful tool to learn how .NET does certain things, and to learn where are the bugs placed, so you know how to avoid them. When there's a bug - going around it or fixing it is the correct behavior.
2. Requiring a ResolveUrl outside of Request context, is never an "incorrect usage". In fact, in most of the applications which are a little more than the most basic websites, you will need a function like ResolveUrl outside the Request context.
3. Requiring a ResolveUrl which is free of bugs, or has better performance - that's good practice...
-----
Daniel Cohen Gindi
danielgindi (at) gmail dot com
|
|
|
|
 |
|
 |
I guess this is just life. There are critics out there who want to express their opinions. In this place, it does not matter if your article is great or not, you can always expect somebody giving you a vote of 1 or 2. As a matter of fact, in a lot of cases it is their sole job to give negative reviews -- they enjoy it. Normally this type of comments don't need any response from you. From a statistics point of view, you will get a rating that closely reflects the real value of your article. Negative reviews are not always bad -- they may draw more people to read your article, and find out if the statement is right or wrong. You may get more positive reviews out of it.
Don't get me wrong. I am not judging RenderEngSol's comments in this place.
By the way, I like your articles. They are very helpful. Thanks for your selfless contribution to the programming community.
|
|
|
|
 |
|
 |
As someone not involved with this article (I did not write it, nor do I know the author), I can tell you: this is a disappointing response and doesn't do justice to what the author has presented.
It is disappointing because it fails to recognize how the author did investigate what was available in the framework (read the article). The author makes clear how he came up with his solution precisely because the framework's version was problematic.
This wasn't a hack - it is a function that provides utility where the framework didn't. Your response comes off as a knee-jerk reaction that itself fails to recognize where the framework's version came up short. It sounds like YOU need some more investigation to recognize what the framework doesn't offer.
It would be nice to have one catch-all ResolveUrl function that works in all cases regardless of the url you pass it; the existing version in the framework does not. The author (unless I am mistaken, and I invite him to correct me if I am) believes that is what he is presenting here with his function. If it works in all url cases, it is a solid and useful contribution.
|
|
|
|
 |
|
 |
take my 5
-------
Arlen.N
|
|
|
|
 |
|
 |
You messed it up! You changed meaning of sentences completly!!! Please restore from the original version ASAP!
-----
Daniel Cohen Gindi
danielgindi (at) gmail dot com
|
|
|
|
 |
|
 |
Editor: Smitha Vijayan
Look at the left bottom of the article page!
|
|
|
|
 |